[apparmor] Packaging of Profiles

[John Johansen]

On 08/10/2010 12:22 AM, Kees Cook wrote:
> tl;dr, j/k.
> 
> Can I agree with both sides of this discussion? :)
hehe, yes but you might not want to stand in the middle when we are
throwing things :)

> 
> 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.
> 
yes, though I have never liked sticking non library stuff in /lib/

> 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
> 
yes out lining criteria would help pull me back from my quest for the
perfect

> 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 agree that they should be used where appropriate

> 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.
> 
agreed, home.d/ has slightly different semantics that make it more
palatable.

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

> 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.
> 
do I have to?  I want to sleep at night :) (sorry there just doesn't exist
a smiley that properly covers the irony in that statement)

> 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
ah, and here I was hoping to codify one of the great standards that
never gets used because no one has the time to implement it

> 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
shoot, out voted by the pragmatists, what is a dreamer to do

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