[apparmor] dynamic profiles

[Jamie Strandboge]

On Wed, 2010-08-04 at 18:10 -0700, John Johansen wrote:
> On 08/04/2010 12:56 PM, Kees Cook wrote:
> > We have a situation where "/etc/init.d/apparmor reload" will remove all
> > profiles that are not listed in /etc/apparmor.d/ but this causes a problem
> > for profiles that are dynamically generated (for example, libvirt's
> > profiles).
> > 
> > I'm not sure the best way to deal with this, though I would note that at
> > least in libvirt's case, the profile name does not start with a leading
> > "/", so it could be possible to just have apparmor leave profiles like that
> > in place.
> > 
> > Thoughts?
> > 
> Hrmm no I would rather not just leave profiles without a leading '/' in place.
> 
> Instead I would rather tag the profiles that need to be left alone.  I can
> think of a few possible ways.

First off, I think that a developer programming to AppArmor should not
really have to worry about this and that as long as we provide a
standard method of marking profiles as dynamic (and documenting it),
then that is the best option.

> 1. Userspace
> Have a set location for dynamic profile eg. /etc/apparmor/dynamic/
> 
> that way the tools can pick up what profiles should be dynamic.  The problem
> with this method is that the parser is going to have to parse the profiles
> to get the names.
> 
From a developer POV, this is easy to understand and straightforward. It
shouldn't be too terribly difficult to make the parser understand this,
and we can do it in pieces if needed (eg, just handle the libvirt case
and do the others as they come).

> 2. Userspace
> Have special userspace file that lists dynamic profiles.  When a dynamic
> profile is loaded its name is added to the file (or some variation of
> this, we could have multiple files).  Problems with this are the file becomes
> a potential contention point in the future, and keeping this list up to
> date is problematic.  Eg. what if a dynamic profile is removed and a profile
> of the same name that isn't dynamic is added.
> 
I don't really like this because it seems like it would be easy for the
developer programming with AppArmor to get it wrong.

> 3. userspace + kernel
> Add a new profile flag, that indicates the profile is dynamic and report it
> as part of the profile list.
> 
> This way the initscripts could screen out the dynamic profiles.
>
> I also think generally it would be appropriate to tag dynamic profiles as
> autoremove when unused.  Basically the profile gets added to the list, but
> once a task attaches to it, it becomes eligible for automatic removal
> once its last reference is put.  This isn't available currently as it had
> a bug and was removed as part of upstreaming, but I would like to reintroduce
> it (null- profiles will use it).
> 
This seems ok too, but means that userspace applications (like libvirt)
are now dependent on a particular kernel version. This isn't the most
horrible thing in the world, but not as easy on developers. Also, in the
case of libvirt, it already handles the removal of the profile, but I
recognize that autoremoval is potentially desirable.

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