[apparmor] Packaging of Profiles

[Steve Beattie]

On Tue, Aug 10, 2010 at 08:32:51AM +0000, Seth Arnold wrote:
> Try this experiment: take an older firefox install, and modify
> the profile to forbid all Ux access. Remove all the text-editor
> business. Remove the mail and terminal business. Confine flash. (60÷
> of why firefox needs a profile in the first place.) Then upgrade
> firefox through three or four versions, trying to keep things tight
> while still integrating changes for e.g. Openjdk and sun jre.
>
> You'll probably get tired of reading a ~sixty-line diff to find the
> one change in the profile. And you'll probably want a three-way merge
> to show you only what changed in the most recent upgrade, not where
> the profile differs from your existing profile.

There are really two somewhat related issues here that make this
painful:

  1) the inability to get a 3-way diff to see what your local changes
     are relative to the old version and what's changed in this
     specific distribution provided updated configuration, and to add in
     the distribution's changes.

  2) the tools used to provide differences have no semantic knowledge
     of policy and thus only display line-oriented differences,
     which is barely tolerable for imperative programming languages,
     but is woefully inadequate for declarative languages. Popping
     up a dialog on upgrade merely because you ordered your fix
     differently than the distribution provider is appalling.

Note that these issues are by no means specific to apparmor (I
get asked on every single grub update about /etc/default/grub);
ucf exists in part to try to improve the situation in the debian
universe. However, as apparmor upstream, this is is where we have an
opportunity to help distributions cope by writing more intelligent
versions of tools.

(If anyone is reading and thinks writing tools to solve the above two
issues would be fun but isn't enough of a challenge, a third thing to
undertake would be a policy lint-style tool that would inform you of
duplicated rules, rules that are entirely subsumed by the regex of
another rule, etc.)

> Hence, storing profiles in /usr/lib, copying them over when a user
> wants one, and 3-way merging with them. Much nicer. New porcelain over
> git for apparmor.d also seems like a much nicer profile repository
> implementation, it could be leveraged for distro updates too, but I
> 100÷ agree on VCS-in-VCS hell avoidance.

I strongly dislike the idea of using a VCS here, as I expect it to
conflict poorly with existing VCS solutions like etckeeper as well
as managed configurations a la puppet, cfengine, and bcfg2.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20100810/141d2e3d/attachment.pgp