[apparmor] Packaging of Profiles

[Kees Cook]

tl;dr, j/k.

Can I agree with both sides of this discussion? :)

So, I would agree that the profile packaging is a bit wonky for AppArmor
due to the Debian conffile package management behavior. Just to point out
another common Debianism, one "solution" is to move these things that
aren't exactly conffiles into /lib. For example, /lib/udev/rules.d/

Now, in the case of udev, it basically loads rules and gives precedence to
stuff in /etc/udev/rules.d over /lib/udev/rules.d. I don't think the
solution is to do the same with AppArmor, but it's an interesting
consideration.

I'm wondering if it might help us to outline the specific criteria we
need to meet, so we can measure potential solutions against it?

- packages need to be able to add to tunables (e.g. @{HOMEDIRS})
- packages need to be able to ship a disabled profile
- packages need to be able to ship a complain profile
- packages need to be able to ship an enforcing profile
- admins need to be able to change profiles
- upgrades need to involve admins in profile changes

While I agree that we're starting to grow an uncomfortably large set
of special directories in /etc/apparmor.d/, I think it's important that
we attempt to leverage the "*.d"-style tricks for supporting packages
that are adding profiles or changing tunables.

I have no concerns about how home.d/ is implemented. This looks clean to me
and is, I think, totally right. It's an uncommon tunable to change, but
it's very important to make it configurable in a packaging-friendly way.

That leaves "handling local changes" (which is not strictly a packaging
issue -- it's local changes), and "declaring the state of a profile" which
is one of 3 states: non-existing, complain, enforce.

The latter reminds me of the "is this service enabled?" question for
packages that install /etc/init.d (or /etc/init) files. Under non-Debian
distros, this is entirely handled by the runtime config editor that
manipulates /etc/rcN.d symlinks, etc. Debian's solution here has never
really worked, IMO, and in the end a set of hacks using non-standard
variables in /etc/default/ for /etc/init.d are used, and the upstart
solution is not yet in place, and faces a similar problem. The state of a
profile needs to be captured somewhere.

As for managing local changes, I've never really minded doing the 3-way
merges that dpkg presented me with. I think the addition of /local/ makes
sense based on how Debian manages conf files. Take a look at /etc/apache2
and the bits there. conf.d/ for package-installed snippets, and a set of
{mods,sites}-{available,enabled} where the -available are all virthosts
and -enabled are symlinks managed by local tools.

Culturally, these kinds of things are how Debian manages weird/complex
configurations. If it's too weird for upstream, I have no problem carrying
a delta. That said, it would be nice to come up with an upstream-sanctioned
way to do local profile modification if not just directly in the profile.

Since we don't _have_ a merging tool, I would push back on anything that
depending on such a thing. If using /local/ is going too far, and stuff
should be copied from /lib/apparmor/profiles/ into /etc/apparmor.d/
as needed, we need a merge mechanism, so I'm going to push back. :P
The difference from the Apache example is that no packages actually
ship virthost files in /etc/apache2/sites-available, so they don't run
into this.

-Kees

-- 
Kees Cook
Ubuntu Security Team