[apparmor] Packaging of Profiles

[Kees Cook]

On Tue, Aug 10, 2010 at 11:05:39AM -0500, Jamie Strandboge wrote:
> On Tue, 2010-08-10 at 03:52 -0400, John Johansen wrote:
> > yes and no.  Having the mode as part of a profile makes it immediately
> > obvious to a user but you are right it is mixing state and policy.
> > Its a trade off and generally I will agree with you that sticking the
> > state in the profile is wrong, and its a historical decision that
> > I am willing to consider deprecating and killing.
> 
> There are pluses and minuses to the mode being in there.
> 
> > Currently we have the problem that a profile can have its state defined
> > in multiple ways.  Eg I can write enforcing in the profile and then
> > add a symlink in complain/, bleh
> > 
> > I have just never been a fan of the symlink solution, partly because
> > it is insufficient to express what is needed when a file contains
> > multiple profiles or hats.
> 
> Agreed and I would like to get rid of force-complain and disable. We can
> do this quickly if mode is moved out of the profile.

It seems like this bit of design decision could be used to help guide us
further. (Additionally, I'd agree, the available profiles should live in
/etc/apparmor.d/ not /lib or /usr/share.)

I agree, defining the state of the profile in the profile should be
deprecated. It's like putting "exit 0" at the stop of init scripts...

So, traditionally, init scripts are enabled/disabled via symlinks in the
runlevel directories. This is effectively what Apache does for modules and
sites too, which is why a similar thing was attempted in Ubuntu for
AppArmor.

I'll go ask Scott what his thoughts were for Upstart, as maybe that would
help us here, since we seem to want neither symlinks nor merged state.

-Kees

-- 
Kees Cook
Ubuntu Security Team