[apparmor] expanding exec syntax

John Johansen john.johansen at canonical.com
Fri Nov 9 16:29:26 UTC 2012


So currently we don't have a good way to express sibling transitions nor any way to express the upcoming stacking.

Sibling transitions:
Sibling transitions are transitions to profiles at the same level in the hierarchy. px serves this purpose for profiles at the root of a namespaces but there is not a convenient way to express such transitions between children profiles.

That is

profile outer {


   profile child1 {

   }

   profile child2 {

   }
}

The "outer" profile can use cx to transition to either child1 or child2, but there is no convenient way for child1 to specify that it wants to transition to child2.  As long as named transitions are used child1 can use px to transition to child2 by using the fully qualified profile name

  /foo px -> outer//child2,

However this is problematic as the hierarchy gets deeper and does not work for profiles that are matched off of executable name, ie.
   /bin/* cx,


For sibling transitions we could add a new exec qualifier, likely sx which would allow all the combinations that px and cx currently have. ie. expressed as a regex

  /foo [sS](i|u|)x (-> <profile>)?,



Stacking:

stacking is going to allow a task to be confined by multiple profiles. It will be possible to express the stacking set using the full qualified profile name, where //& separates profiles in a stack

  /foo px -> /foo//&bar,

however this has some of the same problems of using the full qualified name for sibling transitions. I propose extending the current syntax to us & to indicate stacking.


   /foo ix & /bar,  # inherit current profile and stack
   /foo px & /bar,  # transition to /foo and stack /bar resulting in /foo//&/bar
   /bin/* px & /bar,   # transition to best match profile and stack /bar

if the stacked profile should needs a different qualifier than used by the base the base transition we can allow a second qualifier eg.

   /foo ix & cx /bar,


Beyond domain transitions stacking requires picking up additional domain controls for change_profile, change_hat and the new stack apis.  The top profile in a stack often will want to ignore these transition requests but not deny them so that a lower level of the stack can respond to them.  For domain transitions this is done via ix, for the api I propose extending the current syntax to support the ignore qualifier, that can be used in place of deny and allow.

  ignore change_profile,
  ignore change_hat,
  ignore stack_profile,

for rules that don't support ignore, its use will result in a semantic error during the profile compile.



More information about the AppArmor mailing list