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

[apparmor at raf.org]

(Apologies for the incorrect In-Reply-To: header, I had to get this from
the archive (either I didn't receive it or I deleted it by accident) so
I'm actually replying to my original post)

On Tue May 10 06:29:34 UTC 2016, john.johansen at canonical.com wrote:
> 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 often 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 { }
>   ...

Sorry I didn't mention it before but the debian package that contains
these postfix profiles each contain a single profile with no "profile"
keyword and so the attachment defaults to the profile name which is
indicated by the name of the file (with slashes instead of fullstops/periods).
I haven't changed that structure. I have only added a few rules where
needed. Other profiles in that debian have multiple profiles per file
but not the postfix ones.

> now with that said back to the rule and the log message
> 
> > I'm seeing apparmor log messages that contain:
> > 
> >   profile="/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 from the /etc/apparmor.d/usr.lib.postfix.smtp
> profile should allow that denial, however from the
> profile= 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.

That's correct.

> 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.

I don't understand how that is possible. Since the master profile
is in effect, master must have started smtp and it wouldn't start
any smtp other than /usr/lib/postfix/smtp and, even if it tried,
there is no rule to allow it to do so. It can only start the
binaries that apparmor allows it to.

And /usr/lib/postfix/smtp is the only executable named smtp
on the host.

> 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.

And I certainly didn't make any such modification. :-)

> 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

I'd remember if I had done that. :-)

> you need to check where the smtp profile is in the filesystem
> to make sure the attachment is correct.

The smtp profile is in /etc/apparmor.d/usr.lib.postfix.smtp
and the profile name and attachment are both "/usr/lib/postfix/smtp".

> 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.

pstree tells me that the smtp processes were all started by master.
I would have thought that the profile field in the log message also
indicates this (barring manual use of aa-exec of course).

> 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

The attachment and profile name are both "/usr/lib/postfix/smtp".

Here are all of the postfix-related profiles/attachments and
the exec rules that they contain:

  /usr/lib/postfix/anvil
    /usr/lib/postfix/anvil rmix,

  /usr/lib/postfix/bounce
    /usr/lib/postfix/bounce rmix,

  /usr/lib/postfix/cleanup
    /usr/lib/postfix/cleanup rmix,

  /usr/lib/postfix/discard
    /usr/lib/postfix/discard rmix,

  /usr/lib/postfix/error
    /usr/lib/postfix/error rmix,

  /usr/lib/postfix/flush
    /usr/lib/postfix/flush rmix,

  /usr/lib/postfix/lmtp
    /usr/lib/postfix/lmtp rmix,

  /usr/lib/postfix/local
    /usr/bin/procmail             Px,
    /usr/lib/mailman/mail/mailman Px,
    /var/mailman/mail/wrapper     Px,
    /usr/bin/mlmmj-recieve        Px,
    /usr/lib/postfix/local        rmix,
    /bin/bash                     mixr,
    /bin/date                     mixr,

  /usr/lib/postfix/master
    /usr/lib/postfix/anvil           Px,
    /usr/lib/postfix/bounce          Px,
    /usr/lib/postfix/cleanup         Px,
    /usr/lib/postfix/flush           Px,
    /usr/lib/postfix/local           Px,
    /usr/lib/postfix/master          rmix,
    /usr/lib/postfix/nqmgr           Px,
    /usr/lib/postfix/proxymap        Px,
    /usr/lib/postfix/pickup          Px,
    /usr/lib/postfix/pipe            Px,
    /usr/lib/postfix/qmgr            Px,
    /usr/lib/postfix/scache          Px,
    /usr/lib/postfix/showq           Px,
    /usr/lib/postfix/smtp            Px,
    /usr/lib/postfix/smtpd           Px,
    /usr/lib/postfix/tlsmgr          Px,
    /usr/lib/postfix/trivial-rewrite Px,
    /usr/lib/postfix/error           Px,

  /usr/lib/postfix/nqmgr
    /usr/lib/postfix/nqmgr rmix,

  /usr/lib/postfix/oqmgr
    /usr/lib/postfix/oqmgr rmix,

  /usr/lib/postfix/pickup
    /usr/lib/postfix/pickup rmix,

  /usr/lib/postfix/pipe
    /usr/lib/postfix/pipe rmix,

  /usr/lib/postfix/proxymap
    /usr/lib/postfix/proxymap rmix,

  /usr/lib/postfix/qmgr
    /usr/lib/postfix/qmgr rmix,

  /usr/lib/postfix/qmqpd
    /usr/lib/postfix/qmqpd rmix,

  /usr/lib/postfix/scache
    /usr/lib/postfix/scache rmix,

  /usr/lib/postfix/showq
    /usr/lib/postfix/showq rmix,

  /usr/lib/postfix/smtp
    /usr/lib/postfix/smtp rmix,

  /usr/lib/postfix/smtpd
    /usr/lib/postfix/smtpd rmix,
    /usr/sbin/postdrop rPx,

  /usr/lib/postfix/spawn
    /usr/lib/postfix/spawn rmix,

  /usr/lib/postfix/tlsmgr
    /usr/lib/postfix/tlsmgr rmix,

  /usr/lib/postfix/trivial-rewrite
    /usr/lib/postfix/trivial-rewrite rmix,

  /usr/lib/postfix/verify
    /usr/lib/postfix/verify rmix,

  /usr/lib/postfix/virtual
    /usr/lib/postfix/virtual rmix,

So the only profiles that allow smtp to be executed are
master and smtp itself.

Thanks for all of your explanations. It was quite a heroic effort.
But I'm still at a loss to explain this log message or what to do
about it. :-(

cheers,
raf