[apparmor] Packaging of Profiles

[John Johansen]

So the current addition of /etc/apparmor.d/local and Seth's comments pushed
me over the edge, so the next topic to hit is packaging of profiles.

Basically we are doing it wrong.  Packages currently are installing directly
into /etc/apparmor.d/ and then they own the files.  So that local changes
result in a packaging conflict.

What we should be doing is installing the "reference" profiles into another
location /etc/apparmor/reference?  These files can be owned by the package
and then these profiles are merged/copied with the profiles in /etc/apparmor.d/
which are not owned by the package manager (conf files in .deb)

Basically what an update consists of is.
For each profile being installed updated
  if a matching profile exists in /etc/apparmor.d/ then
    if a matching profile exists in reference profiles
      # update
      do profile merge
    else
      # addition of new profile when user profile exists
      add to reference profiles
      warn user of conflict
  else
    if a matching profile exists in reference profiles
      # profile was removed by user
      update reference profile
      warn user of new update of removed profile
    else
      # new profile
      add profile to reference set and /etc/apparmor.d/


Ideally the profile merge be done by a dedicated tool that understands apparmor
profiles and can take into account changes in profile structure, rule reordering,
includes, pattern matching and permissions.  However lacking that tool a 3 way
diff text merge would be better than nothing.

A failed merge should not replace the current user profile but dump the merged
file with conflicts so that the user can evaluate it.

If a profile repository built on top of a revision tracking (git) tool is in use.
Then packaging could own the base, and do a rebase on updates (pop the users
changes, update the base, replay user changes on top).  The merge could be
done per change isolating merge conflicts.

While the revision model is nice I don't think it should be the default way
packaging is done as it expects users to be able to use such a tool, and
it also expects such a revision tool to be installed by default.