[apparmor] Packaging of Profiles

[Jamie Strandboge]

On Thu, 2010-08-05 at 15:40 -0700, John Johansen wrote:
> 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.

Perhaps it is my Debian upbringing, but I don't agree with this
assessment. While I agree there could be some improvements, saying we
are doing it wrong is, IMHO, an overstatement. I should say up front
that I have implemented much of the packaging surrounding profiling in
Ubuntu, so my opinion should not be considered unbiased.

First, I think it is important to make a distinction between AppArmor
upstream and distributions. As an upstream, IME we are not stating an
opinion on how to manage profiles, abstractions, etc, but do have some
tools that can be helpful (eg, apparmor_parser is aware
of /etc/apparmor.d/force-complain). There are things we could do to
improve the situation, but I'm not sure where we are now is bad per se,
because distributions are often quite different from each other and
there have been bigger fish to fry.

As a distribution, I'll speak from the perspective of Ubuntu(/Debian)
since its packaging and problems is what I know. Background for
packaging of AppArmor profiles in Ubuntu:

 * Ubuntu uses dpkg, so files in /etc are automatically conffiles unless
specified otherwise. If a file is marked as a conffile, on upgrade of
the package shipping the conffile the user will be prompted to accept or
ignore the new version of the conffile if the existing version is
different from both the old shipped version and the new shipped version.
No matter how the user answers, some sort of backup is made (with
a .dpkg* extension), and this backup is ignored by AppArmor.
 * we ship an apparmor-profiles package which is most of the profiles
that are in the upstream profiles/apparmor.d directory.
apparmor-profiles is in Ubuntu's community supported section of the
archive (ie, 'universe') and are toggled to complain mode in the shipped
profile (ie in /etc/apparmor.d/...). Abstractions, etc are considered a
part of the apparmor package and officially supported. All of these
files are conffiles (ie, dpkg prompts to changes on upgrade)
 * for profiles that are officially supported, we ship them with the
package that ships the binary that the profile protects. Eg, our slapd
profile ships /etc/apparmor.d/usr.sbin.slapd. These tend to be in
enforcing mode, with a couple of exceptions. These profiles are also
conffiles
 * to accommodate various upgrades and transitions from
apparmor-profiles to officially supported, we have created
the /etc/apparmor.d/force-complain directory. Creating a file in this
directory with the same name as the profile shipped (either via symlink
or touch) in /etc/apparmor.d forces the profile to complain mode without
having to touch the shipped profile (ie, no prompt on upgrade). Files in
this directory are not managed by the package manager (but may be
created by maintainer scripts in the packaging) and thus users are not
prompted on upgrade when manipulating force-complain.
 * for the few aforementioned exceptions when we don't want to ship an
enforcing profile (eg, firefox), we created the /etc/apparmor.d/disable
directory that works in exactly the same way
as /etc/apparmor.d/force-complain, except the profile is simply not
loaded instead of being loaded in complain mode. Again, users are not
prompted on upgrade for files in this directory
 * we have updated /etc/apparmor.d/tunables/alias with a small
explanation and examples for when using an alias might be beneficial.
This file is a conffile.
 * we added the /etc/apparmor.d/tunables/home.d directory so packages or
admins can drop files into it to update HOMEDIRS (or HOME). Our apparmor
package allows the /etc/apparmor.d/tunables/home.d/ubuntu file to be
configured via debconf, and is therefore preseedable. The likewise-open
package will drop a file into /etc/apparmor.d/tunables/home.d to adjust
HOMEDIRS. /etc/apparmor.d/tunables/home is a
conffile, /etc/apparmor.d/tunables/home.d/ubuntu is not a conffile
and /etc/apparmor.d/tunales/home.d/!ubuntu may or may not be, depending
on if a package ships a file in this directory as a conffile  
 * recently we added the /etc/apparmor.d/local directory (which prompted
this thread), to give administrators a method to make small changes to a
shipped profile that is outside the scope of an alias, a home tunable,
complain mode or disable change. These files are not conffiles and
totally ignored by the package manager after initial creation

I think that covers everything, if at the risk if being too verbose. :)

Looking at the above it seems that in Ubuntu, we are inconsistent with
our use of apparmor-profiles and /etc/apparmor.d/force-complain. We
should probably adjust apparmor-profiles to ship an enforcing profile
with a symlink to force complain. We should also discuss (in Ubuntu) on
whether or not /etc/apparmor.d/tunables/alias should still be a
conffile.

Now I'll get to why I disagree with the assessment. The decision of
whether to make a file a conffile or not should not be taken lightly,
and the rule in Ubuntu/Debian is that if there is a reasonable default
configuration for the majority of users, then it should be a conffile.
This is a longstanding tradition in Debian, inherited by Ubuntu and
other derivatives. In Ubuntu we try to make a profile that works with
default and common configurations, at the risk of potentially being less
strict than required for the specific installation/configuration.
Therefore, we have the opportunity to ship a profile that should work
for most users, and thus our profiles are conffiles. Indeed, for the
profiles we ship in enforcing mode this has worked well (with the
possible exception of mysql, where (due to its immense popularity) some
people are putting mysql all over the place, but don't know about
aliases or AppArmor profiling in general-- this can be improved via
documentation, which I am working on). This approach will not change--
we do not want our users to have to mess with AppArmor for normal use,
otherwise people will become frustrated and disable AppArmor.

Most of the packaging described above in Ubuntu has been centered around
tweaking the default policy to work in a non-default environment. With
the addition of the local/ directory, an admin should have everything
required to finetune AppArmor for her environment, and have those
changes survive an upgrade without having to be prompted (excepting
possibly alias, which we may address). If too many people are affected
by a too strict or too lenient policy, then IMHO this is a policy bug in
the profile, and not a deficiency in AppArmor's merge capabilities.

Where I see there is friction or a perceived problem is when an
administrator wants a significantly different version of the profile, as
with Seth's example. Some already discussed ideas:
 * while the local/ directory can be of some help, it is not really
intended for this purpose
 * an admin could disable the shipped profile via the disable/
mechanism, and use another profile to confine the binary. This is a bit
wonky IMO and probably doesn't work too well with the existing userspace
tools
 * I proposed at our last Ubuntu Developer Summit (UDS) that the profile
not be shipped with the package that ships the binary to be confined,
but instead in a different package. This would allow an administrator to
have the default confinement on install, but with the opportunity to
remove said package if it is not the desired policy. It was
(contentiously) decided that Ubuntu would not implement this
 * have a tool perform some sort of automatic merge. I fear an automated
merge because the profile may trend down to more permissive without
administrator interaction
 * have a tool perform some sort of automated with prompt/manual 3 way
merge. This sounds nice, but IMO is not a huge improvement over package
managers themselves (see below).

As an administrator and someone interested in security, I personally
want to know when my MAC policy is changing. Trusting the distribution
with MAC policy is in the nature of using a distribution with a MAC, and
moving from an unmodified policy to a new policy without prompting is an
acceptable trade-off for ease of upgrades (security-conscious people can
always audit these changes manually). Therefore the current status of
prompting when non-distribution changes are encountered seems very
intuitive and appropriate to me.

If a user makes a change to the policy, that user should not be
surprised to see the prompt on upgrade. On the other hand, if a user did
not make a change to the policy, but is prompted via a merge tool on
whether to merge the new policy or do something else, this could be
confusing for the average user. Introducing a new tool that could
potentially pop up in front of all of Ubuntu's users on upgrades when
most of those users don't have (or want) the necessary information to
make a good decision is not something I am excited about.

> 
> 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.
> 
This is essentially tweaked package manager logic but in a way that
bypasses what users expect. Also, I interpreted 'matching' in the above
as 'matching a binary'. Of course, with a package manager, 'matching'
means 'matching the file name'. In current practice, these are
synonymous, or close enough for this discussion. So, current package
manager behavior with the profile as a conffile is (with dpkg[1]):

For each profile being installed/updated
  if an existing file exists in /etc/apparmor.d/ then
    if upgrade or reinstall from non-purge
      if old shipped and new shipped are the same
        keep current policy, whether it is different or not
      elif profile is different from either old shipped or new shipped
        prompt user on changes and load resulting policy
      else
        put new policy in place
    else
      prompt user on changes and load resulting policy
  else
    if upgrade
      # profile removed by user
      prompt user on changes and (potentially) load new policy
    else
      put new policy in place

AIUI, the important differences between the two algorithms is (please
correct me if I am wrong):
 * when reference policy doesn't exist there is an additional prompt
 * with new algorithm we unconditionally merge reference policy
and /etc/apparmor.d, whereas with dpkg we handle the policy very
carefully

Practically speaking, the new algorithm solves the small changes problem
nicely, but this is already solved in Ubuntu. The new algorithm does not
address the large profile changes in a positive manner-- in fact, it
merges the unwanted changes in the reference profile with those
in /etc/apparmor.d without prompting, so the policy trends down to more
permissive without a prompt. Perhaps you intend this to become a failed
merge? Regardless, administrators of dpkg-based systems will likely be
surprised by this. I know I would. If we must rely on a 3-way merge
tool, then we are prompted appropriately, but gain little over the 2-way
we have with the package manager. Perhaps I've missed something... if so
please enlighten me. :)

> 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.
> 
This is probably not an Ubuntu/Debian compatible change, since more and
more systems use revision control for /etc (eg etckeeper), and then you
end up with a Vcs in a Vcs. Not to mention, while git is used often in
some circles, it is not in others.

So, in summary, I think a merge tool is interesting, but that at least
in Ubuntu, not something that is high priority. Our userspace has many
issues that if were fixed would impact more users than a new merge tool
would. If a merge tool existed, we could potentially use it as an option
when being prompted, but it is hard for me to see us migrating entirely
away from conffiles and relying on a merge tool alone.

[1]http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ap-pkg-conffiles.html#sE.1
-- 
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/20100809/253873bf/attachment.pgp