[apparmor] profile naming and attachment

[John Johansen]

= Profile naming =
Profiles that use pattern matching in there names are not the most intuitive to
work with, especially when when the pattern matching needs to be escaped.


  eg. for firefox When listing profiles or looking at aa-status you get
    /usr/lib/firefox-3.6.12/firefox-*bin

  which isn't too bad but could conceivably get much worse.

I would like to extend to extend the syntax slightly to allow for a name to be
specified separate of the profile attachment.  The syntax extension would be of
the form
  profile [name] attachment [flags] { }

so the name would be optional and only available when using the profile keyword,
which is currently used to specify profile that don't have an attachment
specification.  If a name was not specified the attachment specification would
be used for the name as it currently is.  For our firefox example this would be

   profile firefox /usr/lib/firefox-3.6.12/firefox-*bin { }


Named profiles would interact with exec rules mostly the same as a profile
does currently.  The attachment specification will be used by unconfined,
px, pix, and pux transitions.  That is

   /usr/lib/firefox-3.6.12/firefox-** Px,

would match to the firefox profile as it does to the
/usr/lib/firefox-3.6.12/firefox-*bin profile currently,

Named transitions would however use the short name
  so instead of doing

    /usr/lib/firefox-3.6.12/firefox-** Px -> /usr/lib/firefox-3.6.12/firefox-\*bin,

  the rule would be
    /usr/lib/firefox-3.6.12/firefox-** Px -> firefox


The kernel actually already supports this behavior, this only requires an
update to the parser and the user space tools.



= multiple attachment specification for profiles =
This one has been discussed in the past and I don't believe it is needed
anymore.  The idea was to allow a profile to have multiple names.  So it
could attach to multiple programs.

ie.  /bin/foo /usr/bin/foo {  }

however it then introduced the problem of what to do with replacements and
removals.  Was the first name the handle that would be used to replace and
remove the profile, or would the profile be removed on a per name bases.
What if the profile was split in user space and reloaded etc ...

With profiles names now allowing pattern matching I believe we have a better
solution.  We retain single name behavior and the multiple attachment is
handled by the pattern matching.
  /{bin/foo,usr/bin/foo} { }

combined with the first proposal of allowing profile names separate of the
attachment and we get a nice clean profile name to work with and multiple
attachment

  profile foo /{bin/foo,usr/bin/foo} { }



= conditional profile attachment =
The final idea I want to raise is making conditional rules available to profile
attachment.  This one is a little further off and needs some more thought.

Currently we have the single conditional of file ownership
ie.
   owner /foo/bar r,

and soon it will expand to allow things more like
   owner=(jj smb)  /foo/bar r,



I think it is worth making this functionality available to profile attachment
as well.
   eg.
     profile confined_user user=guest /bin/bash { }

Thus only attaching the profile for specific users, etc.

this could some what replace pam_apparmor but I am not sure at this time
that we would want to or what would be the best uses for this functionality.
Eg. using pam with the proposed change_onexec extension would allow updating
    what users get the confinement without having to reload policy

Basically the ability will be present in the enforcement engine its just
a matter of where/when we choose to expose it.  Also just because we
choose to expose it doesn't mean we have to use it in a given situation.