[apparmor] Understanding log messages (when prof != comm)

[John Johansen]

On 05/09/2016 09:25 PM, apparmor at raf.org wrote:
> Hi,
> 
> debian-8, apparmor-2.9.0
> 
> I need to modify my apparmor profiles for postfix and
> I'm having trouble understanding what the log messages
> are trying to tell me and I can't find any documentation
> explaining the meaning of the contents of the log messages.
> It's probably assumed to be obvious. :-)
> 
As you have already noted the name of a profile does not have
to be the same as that of the comm.

Instead apparmor have 2 concepts that are offended combined
for convenience.
* The profile name - which is the "handle" that a profile can
  be referenced by, and is reported when logging.
* The attachment - which is the rule governing how a profile
  can be attached to an executable.

Profiles must have a unique name but they don't have to have
an attachment, it is possible to have both.

The generic rule for expressing these is

  profile <name> <attachment> { ... }

if the <name> begins with a / then the profile keyword can be
dropped and the <name> and also becomes the attachment.

  ie.
     profile /bin/foo  /bin/foo  {...}
  can be specified by doing
     /bin/foo { ... }


If a profile does NOT have an attachment specified it can only
be attached to an executable via an exec rule that specifies
the profile target explicitly or via the change_profile and
change_hat apis which allows an application to self direct
some changes (change_profile rules are needed in this case).

  eg.
    /bin/bash Px -> special_profile,

would specify that the special_profile is to be used instead
of regular profile attachment.

AppArmor profiles fully control and direct what transitions
should be used via their exec rules which are specified with
an x + some modifiers.  The modifiers are

  P or p - specify a profile transition. P causes some
           environment variables to be scrubbed while p
           does not.

  C or c - specify a child profile transition. These are
           basically the same as P and p except that
           searching the "global" profile set, they only
           search the set of children profiles defined
           as part of the main profile.

  U or u - transition to the "unconfined" profile, with
           capitalization again indicating whether environment
           variables should be scrubbed.

  i      - inherit the current profile

  ->     - specify a profile name explicitly

These modifiers can be combined is some ways. Eg.

  Pix - to indicate transition to the matching profile and if
        there isn't one fallback to the current profile.

How all this plays together is a little complicated especially
because there are potentially two regular expressions involved,
one in the file rule and one in the attachment specification of
the profile. But the basics is that the rule in the profile is
applied first, and then the attachments are compared to find
the best profile.

Eg. Say we have an application confined by a profile with the rule
  /bin/bash Px -> foo,

Then bash launch from that application will always be confined by
the profile foo.  However bash launched from unconfined or another
application confined by a different profile could very well be
confined by a different profile, or even no profile (well actually
the unconfined profile but most people don't think of it like that).

Say another profile on a different application has the rule
  /bin/bash Px,

when that application tries to launch bash, apparmor finds the
rule that says /bin/bash should do a Px transition.  AppArmor
then compares the executable name "/bin/bash" against the
current set of loaded profiles to see if any of them match
(this is where the attachment comes in), and if any of them
do the apparmor chooses the one that is the best match
(roughly defined as the longest left exact match).

I have mentioned that the unconfined state is basically a special
profile that doesn't do any enforcement, but for exec rules
it basically does

  /** pix,


> There is a separate profile for each postfix executable.
> 
okay

> The profile /etc/apparmor.d/usr.lib.postfix.master contains:
> 
>   /usr/lib/postfix/smtp Px,
> 
> The profile /etc/apparmor.d/usr.lib.postfix.smtp contains:
> 
>   /{var/spool/postfix/,}active/[0-9A-F]* rwk,
> 
ah, another potential point of confusion. The name of the file
containing the profile is arbitrary. It is just there to help
humans find the various profiles. The file can even contain
multiple profiles.

You could have a single postfix file which contained the
profiles
  profile /usr/lib/postfix/smp { }
  profile /usr/lib/postfix/foobar { }
  ...

now with that said back to the rule and the log message

> I'm seeing apparmor log messages that contain:
> 
>   prof="/usr/lib/postfix/master"
>   op="file_lock"
>   name="/var/spool/postfix/active/01FBB1FA73"
>   comm="smtp"
>   req="k"
>   denied="k"
> 
> This makes me think that the profile for master needs to have
> a rule added like the above rule for smtp but the comm="smtp"
> makes me think that this log message is about smtp, not master,
> but smtp already has this rule.
> 
> What am I not understanding here? Why is the profile for master
> being mentioned in the log message rather than the profile for smtp?
> Is it master or smtp that is trying to lock the file in question?
> Which profile needs a new rule? Does the master profile needs the
> same rule as the smtp profile, or is the rule in the smtp profile
> incorrect?

the rule form the /etc/apparmor.d/usr.lib.postfix.smtp
profile should allow that denial, however from the
prof= entry we can see that the application is NOT
being confined by the /etc/apparmor.d/usr.lib.postfix.smtp
profile it is being confined by the 
  /usr/lib/postfix/master profile.

and the comm is smtp

So why would this happen? First up I am assuming you don't
have any custom attachments defined for those profiles.

The first thing that comes to my mind is that the smtp
program was not run from /usr/lib/postfix/smtp which would
mean the Px rule was not applied.

Other potential reasons would be postfix is using change_onexec
to override the rule. This is unlikely as I am unaware of any
such modification to postfix, and the postfix/master profile
would also need the correct change_profile rules.

Another possibility is that smtp was run via something that
is confined by a different profile. Eg from the terminal I
can do

  aa-exec -p /usr/lib/postfix/master -- smtp ...

and it will run under the postfix/master profile

you need to check where the smtp profile is in the filesystem
to make sure the attachment is correct. And you should check
the parent pid and comm/confinement (ps -Z for the profile
information), to ensure it is being started by the postfix/master
profile.

Oh and you didn't mention what the attachment/profile name
of the /etc/apparmor.d/usr.lib.postfix.smtp profile actually
is. Check there as well to make sure it is correct


> 
> Thanks for any help.
> 
> cheers,
> raf
> 
>