[apparmor] Packaging of Profiles

[Marc Deslauriers]

On Mon, 2010-08-09 at 21:22 -0700, Kees Cook wrote:
> 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?

I agree this is the _first_ step that needs to be done in this
discussion.

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

agreed

> - upgrades need to involve admins in profile changes

This is where I don't agree.

Most packages that ship config files _rarely_ (if ever) modify the
config files once the distro is released. Administrators who modify the
config files can be reasonably assured that the large majority of
upgrades won't be interrupted in the middle with a dialog asking them to
merge the differences. The difference with AppArmor, is updates will
often have updated config files, as new rules are added when profile
restrictions have caused regressions.

While a power user who modified an AppArmor profile would probably like
to see the dialog pop up so he can merge in the new stuff, an admin that
is trying to customize an AppArmor profile for a large number of users
most certainly will not.

In rpm packaging, there is a way to mark a config file so that new
versions never replace the old ones, and are simply thrown in the same
directory with a ".rpmnew" extension. This may be the way to go. If a
config file was modified, we may _never_ want to replace it, or bother
the administrator with a manual intervention process. Presumably, the
local profile has been tuned, and doesn't hit the regression that the
package update is trying to correct. If so, the admin can simply update
his modified profile with a large scale deployment tool, such as Puppet
or Cfengine.

Marc.