[apparmor] [PATCH V2] apparmor: Add support for audit rule filtering
Matthew Garrett
mjg59 at google.com
Wed May 9 22:13:55 UTC 2018
On Wed, May 2, 2018 at 11:03 PM John Johansen <john.johansen at canonical.com>
wrote:
> On 04/16/2018 11:23 AM, Matthew Garrett wrote:
> > This patch adds support to Apparmor for integrating with audit rule
> > filtering. Right now it only handles SUBJ_ROLE, interpreting it as a
> > single component of a label. This is sufficient to get Apparmor working
> > with IMA's appraisal rules without any modifications on the IMA side.
> >
> > Signed-off-by: Matthew Garrett <mjg59 at google.com>
> Sorry getting to this took so long. There is an issue and I would like
> some clarification on the semantic you desire.
Sure!
> 1. The comparison could potential fail if apparmor policy namespaces
> are in use.
> With the current state of audit rules I think we need to make the
> assumption they are associated to the root policy namespace. But I'd
> like to start thinking about what to do in the face of namespacing.
Mm, true.
> 2. Do you ever want to be able to setup an audit rule based off of
> more than a single profile in a stack. That is trigger based
> on A//&B and not just A or just B
Ah, good point. For my specific case a single profile is sufficient, but I
can imagine cases where a stack might be relevant.
> I have included a patch that uses label_parse. It fixes 1, assuming
> audit rules are associated to the root policy ns.
> Allows for 2, where a rule could have A//&B
> and keeps the current subset semantic. So say the secid resolves to
> the label stack A//&B//&C
> Then an audit rule specifying a label of
> A would match
> B would match
> C would match
> D would not
> A//&B would match as a subset
> A//&C would match as a subset
> B//&C would match as a subset
> A//&B//&C would match
> A//&D would not match, because while A does D is also specified and
does not
I think that sounds like a decent behaviour. I'll test this ASAP.
More information about the AppArmor
mailing list