[apparmor] Extending the policy language to support stacking

John Johansen john.johansen at canonical.com
Wed Dec 14 12:33:48 UTC 2011


With us finally moving towards supporting multiple profiles on a task, its
time extensions to the policy language.

Minimally there needs to be a control on whether stacking is allowed, and ideally
it should even allow specifying what profiles can be used.  For this we should
probably follow a similar syntax as change_profile uses.

  change_profile -> <profile>,

However I think we should avoid the use of ->, as its not doing a transition so
much as adding a profile on top of the current one.

So I am proposing

  stack_profile <profile>,


  Eg.
    stack_profile /foo/bar,

    stack_profile **,    #any profile


Beyond controlling the stacking api it would be nice to be able to allow profile
transitions to specify stacking.  Something along the lines of

  /foo/bar px,

  /foo/bar px + ^foo,

where px would indicate the transition for the current profile and + ^foo is
adding a local profile foo to the stack.  I am unsure this syntax is sufficient
in the above proposal I am using the ^ to provide a similar effect as cx.  But
the name is currently explicit and doesn't allow search off of the matched
executable name.

  /** px + ^foo,

would choose the best loaded profile that matches the executable name for the px
transition, and use the local profile foo for the stack, but there is no equivalent
way to say use the best matching local profile.

Supporting the dynamic case well is important, otherwise the policy extension is
really just a new way to express static policy composition.

  /foo/bar ix + ^foo,

is just a way to say compose these two profiles, which if known at compile time
can be done statically.

But
  /** px + ^foo,

is dependent on the executable (if doing a total policy compile and load even this
could be analyzed statically but would result in an explosion of profiles  as it
would need to statically compose all profiles that could be used when matched by /**).

I do think supporting a dynamic choice for the stacked profile is important, especially
when stacking a child namespace where you want the child namespace to start in the
appropriate profile based on the executable name.



More information about the AppArmor mailing list