[apparmor] dynamic profiles

[John Johansen]

On 08/04/2010 07:40 PM, Jamie Strandboge wrote:
> On Wed, 2010-08-04 at 12:56 -0700, 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.
> 
> Right, this is due to how libvirt uses change_profile() and an excellent
> observation. AFAIK, libvirt is the only application doing dynamic
> profiles in this manner, so simply not reloading these seems to be a
> good first step.
> 
hrmmm, it may be a temporary crutch that is worth doing but it will definitely
need to be replaced.

> OTOH, typical (non-dynamic) transitions like 'px', child profiles and
> change_hat() should not be affected by this change (they get reloaded
named transitions can break.  ie. px ->

> just fine). I guess it is imaginable that a dynamic profile could
> transition to a profile name that starts with '/', but until we are
that isn't such a problem as if the profile isn't there the transition
will fail.  If there is a replacement profile it will get used.  Its
the case of a none dynamic profile transitioning to a none dynamic
profile with a name that doesn't begin with a '/' that is problematic.

> faced with an application that actually does this, I'm not sure we
> should be overly concerned with it. We might simply mention in developer
> documentation how AppArmor handles dynamic profiles (both with and
> without a leading '/'), so people can make an informed decision when
> developing them.
> 
but not having a leading '/' does not mean its dynamic.  It is merely
a profile that doesn't automatically attach to an unconfined task.
This means that it is only available through change_profile, named
transitions or inheritance.

I will give you that currently libvirt is the only user of the feature,
in the reference profile set, but I have created and seen profiles
that don't.

For the moment I think it is a safe short term solution to not do auto
removal of profiles that do not begin with a '/'.  This in the worst
case will leave profiles loaded that where removed from the profiles
directory, but since they don't auto attach this should be safe.

I just don't want profiles not beginning with '/' to be documented as
dynamic profiles.