[apparmor] Packaging of Profiles

[Jamie Strandboge]

On Mon, 2010-08-09 at 21:22 -0700, Kees Cook wrote:
> tl;dr, j/k.
> 
> Can I agree with both sides of this discussion? :)
> 
Hehe. TBH, I don't think that John and I disagree on a lot other than
priority and POV on the state of the world.

> 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/
> 
So there are 4 choices:
1. conffile where the package manager manages it
2. config file where the package manager stays out of the way and we 
   use some other tool
3. putting stuff in /lib or /usr/share
4. putting stuff in /lib or /usr/share as a sort of template/base 
   profile which stuff in /etc pulls from

1,2 and 4 state that we recognize these are configuration files, let's
come up with some way to manage them. 3 says we know best and the admin
shouldn't mess with them. I think 3 we can rule out entirely. 2 and 4
aren't really much different from each other if we consider John's
reference policy implementation. 2 requires a tool of some sort like a
merge tool or ucf and 1 is what we've done in the absence of said tool.

I feel pretty strongly that what an admin uses to configure AppArmor and
its policy should be in /etc. Whether we copy from /usr/share
(traditional 'config file' approach) or use a merge tool doesn't really
matter to me. In Ubuntu I'm not too interested in transitioning away
from conffiles to config files with ucf or similar only to move to a new
merge tool down the line.

> 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?
> 
This is an excellent idea.

> - packages need to be able to add to tunables (e.g. @{HOMEDIRS})
yes

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

> - admins need to be able to change profiles
yes, though this is maybe too general. Specifically, they need to be
able to:
- modify policy
- modify mode (disable, complain, enforce)
- modify alias
- modify HOME tunables

> - upgrades need to involve admins in profile changes
yes and no. Only policy changes must be considered and I do think that
some override mechanism is good to have where an admin/power user can
say "I always want to allow access to /var/www/foo". We have local/
today, a merge tool would also help. Mode could maybe be prompted on
upgrades, but this may be a distribution choice.

> 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, somewhere outside of the policy. A naive approach is to have
aa-enforce, aa-complain and a new aa-disable that sets the state
somewhere outside of the profile and apparmor_parser that will not set
these but honor them (with an option to force load, etc).

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

Me too, but not necessarily at the expense of other more pressing work.


-- 
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/20100810/3ff441db/attachment.pgp