[apparmor] profile naming and attachment

[Jamie Strandboge]

On Wed, 2010-11-17 at 17:19 -0800, John Johansen wrote:
> = Profile naming =
> ...
> 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 { }

Assuming that current behavior is still supported, I like this idea.


> = multiple attachment specification for profiles =
> ...
> 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} { }

If already doing 'Profile naming', this makes a lot of sense.


> = 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.
> ...
> 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

While this would enable us to support non-pam systems, this seems much
less of a priority since we have pam_apparmor. Since pam_apparmor works
well for this sort of thing already, having a solid user case beyond 'it
is a way to replace pam' would be worthwhile. In other words, since
there is so much to do right now, IMHO we need to demonstrably prove we
need the new feature before devoting resources to it.

> 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.

Right, but perhaps because I am not imaginative enough, this seems more
like TIMTOWTDI and added complexity rather than something that is really
needed. Granted, I do see supporting non-pam systems as a worthy goal,
but not high priority atm. I'd love to be proven wrong, as conditional
profile attachment looks interesting....

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20101118/6ea4e68e/attachment.pgp