aa-enforce/aa-complain don't change mode/flags in subprofiles

[raf]

The tools aa-enforce and aa-complain in the debian8 apparmor-utils package
only change the mode/flags of the top-level profile in the file given on the
command line.

If the file being modified contains a profile with subprofiles, then the
flags for the subprofiles do not change and, when running apparmor_status,
the subprofiles show as having a different mode to their parent profile.

For example, /usr/share/doc/apparmor-profiles/extras/usr.sbin.sshd from the
apparmor-profiles package has a profile for /usr/sbin/sshd and hat subprofiles
named ^EXEC, ^PRIVSEP, ^PRIVSEP_MONITOR and ^AUTHENTICATED.

After running aa-complain, only the main profile has "flags=(complain)" at the top
of its definition. The hat subprofiles do not have this flag added. That would be OK
if they inherited the flags from the parent profile but, as apparmor_status shows,
the profile for /usr/bin/sshd will be in complain mode but the subprofiles
will be shown as still being in enforce mode.

If I want all of sshd's profiles to have the same flags, I have to edit the profile
manually and reload it with apparmor_parser -r.

I also tested this with a file containing multiple, non-nested profiles (usr.bin.evince
from debian's apparmor-profiles-extra package) which contains the following profiles:

   /usr/bin/evince (1st profile)
   /usr/bin/evince//sanitized_helper (subprofile of 1st profile)
   /usr/bin/evince-previewer (2nd profile)
   /usr/bin/evince-previewer//sanitized_helper (subprofile of 2nd profile)
   /usr/bin/evince-thumbnailer (3rd profile)
   /usr/bin/evince-thumbnailer//sanitized_helper (subprofile of 3rd profile)

And the flags of all of the top-level profiles were changed but the flags of the subprofiles
were all left unchanged.

I don't know if the same problem applies to non-hat subprofiles but it probably does.

The manpage for aa-enforce and aa-complain actually state that the command line
argument is an executable rather than executable-or-profile so perhaps this is an
undocumented use of these programs rather than a bug exactly. However, I assumed
that I could supply the name of a file containing a profile and it mostly worked except
when subprofiles are involved. Since the behaviour surprised me, I classify it as a bug.

Even if this isn't classified as a bug, something is wrong. Either the manpages for
aa-complain and aa-enforce need to be changed to state that the command line
argument can also be the name of a file containing a profile (with a caveat that
subprofiles are ignored), or the tools themselves should stop accepting the names
of files containing profiles on the command line so that users don't assume that all
profiles in the file will be affected but my preferred outcome would be that the use of
profile filenames on the command line become documented and that subprofiles be
included in the process.

I don't know if this is a security vulnerability (so I'm not checking that box) but it might
be in the sense that it is easy for someone to think that they have changed the mode
of a policy from complain to enforce when, in reality, they have only done part of it.
Of course, they should check the modes with apparmor_status anyway and so should
discover this but they might not and, as a result, be left in a left secure situation than
they think.

[Christian Boltz (cboltz)]

This is fixed in 2.10 and the to-be-released 2.9.3 for hats, and also for subprofiles _if you call "aa-complain /etc/apparmor.d/usr.bin.profilename".

If you use "aa-complain /usr/bin/somebinary", flags of subprofiles won't be changed (that's something I still need to fix). This also affects creating child profiles with aa-genprof, which will currently stay in complain mode.