Instead of setting SFS_MOUNTPOINT in is_apparmor_loaded() (which is
called in most cases) and in is_container_with_internal_policy() (which
covers/fixes the remaining cases), set it globally.
This also fixes a bug in is_container_with_internal_policy() (introduced
in f10e72a14f6b0c4ed3588904feac024790ef7311) where the variable
definition tried to use the no longer existing $MODULE variable and
therefore got a wrong path for $SFS_MOUNTPOINT.
Besides this bug, there's a minor behaviour change / improvement if
securityfs isn't mounted - "file not found" error messages will now
contain the full/correct path ;-)
This change/cleanup is a follow-up of
https://gitlab.com/apparmor/apparmor/merge_requests/363 and some IRC
discussions 2019-04-16.
is_container_with_internal_policy() is called independently of
apparmor_*() in the systemd unit and potentially other consumers of
rc.apparmor.functions. When the unit and rc.apparmor.functions functions
were rewritten, they were written so that SFS_MOUNTPOINT was only set in
is_apparmor_loaded(), but this is only called in apparmor_start(),
remove_profiles(), apparmor_kill(), apparmor_restart(), apparmor_try_restart()
and apparmor_status() and not is_container_with_internal_policy().
While it is clear that is_container_with_internal_policy() is meant to
be called before apparmor_start(), is is unclear why SFS_MOUNTPOINT is
only defined in is_apparmor_loaded(). There are several ways to fix
this:
1. update is_container_with_internal_policy() to call is_apparmor_loaded()
2. identify the callers of is_container_with_internal_policy() and have
them call is_apparmor_loaded()
3. reorganize the code to remove duplicate calls and assignments
4. define SFS_MOUNTPOINT along with SECURITYFS and MODULE, at the top
level
5. also define SFS_MOUNTPOINT in is_container_with_internal_policy()
'1' would result in redundant calls in many common cases since the
systemd unit would call is_apparmor_loaded() both in
is_container_with_internal_policy() and prior to other calls.
'2' would like break consumers of rc.apparmor.funcions, like
Debian/Ubuntu's profile-load.
'3' is perhaps ok, but requires more effort and is regression-prone.
'4' seems the simplest, most correct fix
'5' is what this patch implements, which is as simple as '4' but tries
to maintain the original author's intent of when to set SFS_MOUNTPOINT.
PR: https://gitlab.com/apparmor/apparmor/merge_requests/363
Signed-off-by: Jamie Strandboge <jamie@strandboge.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
I slightly ;-) doubt we'll change the module name.
PR: https://gitlab.com/apparmor/apparmor/merge_requests/354
Signed-off-by: Christian Boltz <apparmor@cboltz.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Note that $PARSER_OPTS has to stay without quotes because it can
sometimes be empty, and would (if quoted) be interpreted as empty
filename by apparmor_parser
Extend the subshell so that the actual (possibly non-zero) value of
$retval gets returned. Before, the changed value was lost at "done"
(= leaving the subshell), and the initial $retval=0 was returned.
(found with shellcheck)
Commit 0d5ab43d592245d011b2614e6e20fc7cb851c53c removed support for loading
modules and introduced a caller, in apparmor_start(), that passes no argument to
is_apparmor_present(), which breaks that function when /bin/sh → /bin/dash.
Passing a module name as argument does not make sense since we dropped support
for the long obsolete "subdomain" module, so let's simplify
is_apparmor_present() and adjust its callers accordingly.
Bug-Debian: https://bugs.debian.org/917874
Since 04eb2fe3, __parse_profiles_dir can only return 0 or 1, so $STATUS can only
be 0 or 1, so trying to reset this variable to 0 when its value is 2 can only
cause confusion.
aa-eventd and its initscripts have been moved to deprecated/ in 2014 and
didn't get any serious updates for several more years, so it's most
probably useless and/or broken nowadays.
This also means we don't need to keep the AA_EV_BIN and AA_EV_PIDFILE
variables in rc.apparmor.functions anymore.
The apparmor kernel "module" has not been a loadable module for more
than a decade, it must be built into the kernel and due configuration
requirements it will never go back to being a loadable module.
Remove the long unfunctioning load_module support from the init script.
PR: https://gitlab.com/apparmor/apparmor/merge_requests/257
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: seth.arnold@canonical.com
Imported from the Debian/Ubuntu packaging. We need this function so that
Debian/Ubuntu can switch to using this shell library instead of their own code.
CVE-2017-6507
https://launchpad.net/bugs/1668892
The common AppArmor 'restart' code used by some init scripts, upstart
jobs, and/or systemd units contained functionality that is no longer
appropriate to retain. Any profiles not found /etc/apparmor.d/ were
assumed to be obsolete and were unloaded. That behavior became
problematic now that there's a growing number of projects that maintain
their own internal set of AppArmor profiles outside of /etc/apparmor.d/.
It resulted in the AppArmor 'restart' code leaving some important
processes running unconfined. A couple examples are profiles managed by
LXD and Docker.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
When executing apparmor_status from rc functions and utils are not installed, this message is received:
AppArmor is enabled,
Install the apparmor-utils package to receive more detailed
status information here (or examine directly).
Signed-off-by: John Johansen <john.johansen@canonical.com>
rc.apparmor.suse), I noticed that "rcapparmor restart" is
totally silent.
The attached patch prints a message in __apparmor_restart().
It also replaces the hardcoded "return 0" with $?. I'm quite sure this
won't catch all errors, but it's still better than the hardcoded success
message.
Acked-by: John Johansen <john.johansen@canonical.com>
by converting the comm(1) usage on temporary files to an embedded
awk script. On both Ubuntu and OpenSUSE, a version of awk (mawk in
Ubuntu, gawk in OpenSUSE) is either a direct or indirect dependency
on the minimal or base package set, and the original reporter also
mentioned that an awk-based solution would be palatable in a way that
converting to bash, or using perl or python here would not be.
In the embedded awk script, I've tried to avoid gawk or mawk specific
behaviors or extensions; e.g. this is the reason for the call to sort
on the output of the awk script, rather than using gawk's asort(). But
please let me know if you see anything that shouldn't be portable
across awk implementations.
An additional issue that is fixed in both scripts is handling child
profiles (e.g. hats) during reload. If child profiles are filtered
out (via grep -v '//') of the list to consider, then on reloading
a profile where a child profile has been removed or renamed, that
child profile will continue to stick around. However, if the profile
containing child profiles is removed entirely, if the initscript
attempts to unload the child profiles after the parent is removed,
this will fail because they were unloaded when the parent was unloaded.
Thus I removed any filtering of child profiles out, but do a post-awk
reverse sort which guarantees that any child profiles will be removed
before their parent is. I also added the LC_COLLATE=C (based on the
Ubuntu version) to the sort call to ensure a consistent sort order.
To restate, the problem with the existing code is that it creates
temporary files in $TMPDIR (by default /tmp) and if that partition
is full, problems with the reload action ensue. Alternate solutions
include switching the initscript to use bash and its <$() extension
or setting TMPDIR to /dev/shm/. The former is unpalatable to some
(particularly for an initscript), and for the latter, /dev/shm is
only guaranteed to exist on GNU libc based systems (glibc apparently
expects /dev/shm to exist for its POSIX shared memory implementation;
see shm_overview(7)). So to me, awk (sans GNU extensions) looks to
be the least bad option here.
Bug: https://launchpad.net/bugs/775785
This patch fixes the init scripts helper functions file to
filter out the hat/child process separator as currently used
by the parser, '//' rather than what used to be used, the '^'
symbol. This fixes bugs where profiles that covered regexs (e.g.
'/usr/lib/firefox-4.0.1/firefox{,*[^s][^h]}') and thus were being
improperly filtered away and unloaded when reloading apparmor policy.
reload. For now just special-case libvirt's profiles. If more applications
use dynamic profiles, this should be generalized in some way to flag profiles
as dynamic. (LP: #702774)
reload. For now just special-case libvirt's profiles. If more applications
use dynamic profiles, this should be generalized in some way to flag profiles
as dynamic.
"SubDomain" in some way. This leaves only "subdomain.conf" and the
function names internally.
Additionally, I added a "make check" rule to the utils/Makefile to do a
simple "perl -c" sanity check just for good measure.
