[apparmor] Packaging of Profiles

[John Johansen]

On 08/09/2010 03:55 PM, Jamie Strandboge wrote:
> 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.
> 
Well no not wrong but maybe overstating the issue.

> 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.
> 
sure, I am trying to think long term here I realize that this is in
someways a small step and that is one of the reason's it has sat on
the backburner for years.  I want to have a real solution to this
solution instead of piling on hack and bandaid after hack and bandaid
as we have been doing.

> 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
and this has lead to several files being moved out of /etc/ when this
is where they really belong.

> 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.
yes, but this prompting shouldn't always happen, and is a less than
optimal user experience.

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

Yep, but again this prompting shouldn't happen some times.

>  * 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
And this solution is exactly an example of why we are doing it wrong.
The very need to create the force-complain/ and disable/ directories
is problematic it separates the policy state, making it more difficult
to deal with policy.

The existence of these directories is because they were a pragmatic
solution to a very real problem.  It works but is less than ideal.

>  * 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
again more examples of coming up with pragmatic solutions to the
underlying problem.  Well that is overstating it as I think this solution
would be useful even if conffile problem was solved.

> 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
> 
And I think this solution is absolutely vile, and should be eradicated.
It doesn't deal well any kind of modification beyond adding rules.
Relying on deny rules to do subtraction in this case is dangerous and
makes policy a lot harder to understand.

I didn't fight this as I see it a short term practical solution to
a real problem, that we can solve any other way in the time frame
presented.  But the more I think about it the more I wished I had
opposed it.  Going down this route is a policy nightmare.

> I think that covers everything, if at the risk if being too verbose. :)
> 
not at all, I appreciate you being thorough.

> 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.
> 
Gak NO, NO, NO, NO, NO, NO, NO, NO!
did I mention no?  I see this as going in the absolutely wrong direction.

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

> 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.
sorry this is wrong, or least is incomplete.

> 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.
Yes and there is nothing wrong with this, as people who need to deviate
will.

> 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
ah, another example of where this breaks.  The more profiles we ship
the more we will break and the more tuning that is needed.

> aliases or AppArmor profiling in general-- this can be improved via
> documentation, which I am working on). This approach will not change--
yes thanks for that its much needed and appreciated
> we do not want our users to have to mess with AppArmor for normal use,
> otherwise people will become frustrated and disable AppArmor.
> 
agreed, most people should have to care or even see it, this isn't
what I want to change or the problem I am trying to solve.  The problem
I am targeting is specifically the user who does modify policy.  I
don't want the users who do modify AppArmor to get frustrated.  I want
modifying policy to be as easy, and friendly as it can possibly be.

> 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.
> 
sorry practical experience has already shown this not to be true.  There
is breakage happening and as soon as the user touches policy then there
are problems.  Splitting things out into local/ is a bandaid, that
in some ways makes the problem worse.  It makes profiles harder to
understand, and it only deals with a limited set of cases.  It forces
the use of deny rules in situations that they are not the best solution,
increasing the size of policy and hiding them in local/ so that they
are not immediately obvious.

> 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:
Its not necessarily significantly different, in fact it can be small
changes in just one profile.  Just small changes that don't fit
with the current solutions.

>  * while the local/ directory can be of some help, it is not really
> intended for this purpose
agreed.  My problem with local/ is doesn't solve any of the problems
well.

>  * 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
Yikes, please don't ever suggest that to a user, that is a train wreck
waiting to happen.

>  * 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
hrmmm, I think this is another example of the problem.  And that is
one of the reasons it was rejected.  Having the policy be part of the
package is correct, the split packaging solution is another attempt
at bandaging over the problem.

>  * 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
Ah I fear that too, and I wouldn't have the tool do that without the
administrator configuring it to do so.  But this is exactly what
having local/ does (yet another reason to hate this solution) except it 
doesn't do it as well as a merge tool would.

So the history here is that Crispin wanted a two way merge tool that
always expanded permissions, potentially discarding local changes to
reduce permissions.  Crispin wanted this as its better to do that than
to break the user, simplicity, simplicity, simplicity.  The three way
merge allows the option of  preserving all local changes, and that is
what makes it desirable.

What I want is merge tool that is configurable on what types of changes
it would merge automatically.  No changes, no permission changes,
non expanding changes, all.

What I would do automatically (by default) is have the tool merge changes 
that don't expand permissions.  Changes to the profiles mode (complain, 
enforce, ..), movement of rules, local changes that work out to be the
same as what is in the new version of the profile.  Many changes fall
into this class, little accesses that tripped up the user on the reference
policy and then they get modified later.  This is one of the reasons
it needs to be a semantic diff instead of a plain three way diff.

Changes that result in changing the permission set either need to prompt,
set up a backup, an rpm.new (or equiv .dpkg* file), and no matter
what it does it needs to inform the admin that there where changes
made or that there are changes that need to be considered.

>  * 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).
> 
Well yes it is, but there we will have to disagree

> As an administrator and someone interested in security, I personally
> want to know when my MAC policy is changing. Trusting the distribution
agreed, but local/ makes this worse not better

> 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.
> 
oh I hope you'll agree we don't disagree here.

> 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
Agreed, unless they have configured the system not to do this.

> 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.
> 
Uhmm this should never pop up in those cases.  It should be exactly
like we have now if there are no local changes.  The only time there
should be prompting is when there are local changes.

>>
>> 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
How so I see as trying to get closer to what the user expects.  Perhaps
not a packager who is familiar with what broken packaging conventions
have enforced.

> as 'matching a binary'. Of course, with a package manager, 'matching'
> means 'matching the file name'. In current practice, these are
yes and that isn't always right!  Sorry package managers just haven't
been setup to handle some situations well.

> 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
only if the user has provided a policy already.  I may have messed up
the logic above, but a prompt should only be needed if local differences
exist, which is no different than the current package manager behavior.

>  * with new algorithm we unconditionally merge reference policy
> and /etc/apparmor.d, whereas with dpkg we handle the policy very
> carefully
> 
No, not unconditionally, configurably.  Sorry I wasn't clear about that
in my first email.

> Practically speaking, the new algorithm solves the small changes problem
> nicely, but this is already solved in Ubuntu. The new algorithm does not
No it isn't, what we have is a bandaid that given the opportunity I
would now NAK, as I have become more and more convinced of how wrong
it is.

Not only does it only solve part of the small change problem, it introduces
expanding permissions, and makes policy harder to understand.

> 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
Again no, I realize this misunderstanding is my fault as I didn't explain
this well (partly because I thought it was obvious).  I was shooting
at explaining what I see as a solution to the problem, not the minutia
of handling prompt vs. auto merge vs. store diff for later (which is
another thing that I propose handles well).

> 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
death to dpkg! :)  I am looking at a solution that applies beyond dpkg,
and will work with dpkg.  I really don't think users will be surprised
as it comes very close to dpkg and yet gives the improvements that
I think users would expect.

> 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. :)
> 
I hope I have.

>> A failed merge should not replace the current user profile but dump the merged
>> file with conflicts so that the user can evaluate it.
>>
Yes that is an option, the question is what to consider a failed merge.

>> 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.
> 
Well its a neat idea but not one I consider practical at least for
most people.  It is something that would be neat to support and I
through it in explicitly because Seth brought up using git to do policy
management.

> So, in summary, I think a merge tool is interesting, but that at least
yes

> in Ubuntu, not something that is high priority. Our userspace has many
I'll have to disagree, its priority has increased with each bandaid
put in to support packaging.

> 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.
> 
well I hope I a have changed your mind so

> [1]http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ap-pkg-conffiles.html#sE.1
>