On Wed, May 2, 2018 at 11:03 PM John Johansen <[email protected]> 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 <[email protected]> > 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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
