[apparmor] Packaging of Profiles

[John Johansen]

On 08/10/2010 12:50 AM, Jamie Strandboge wrote:
> On Mon, 2010-08-09 at 19:18 -0400, John Johansen wrote:
>>> 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.
> 
> I see we have a long road ahead of us. Your 'death to dpkg' comment
> below shows we do not see eye to eye. While the Debian/Ubuntu Policy is
> something that can be problematic for people, it is because of
> Debian/Ubuntu policy that downstream dpkg-based systems have such a
> stable base to build upon. As this is an AppArmor mailing list, I'll not
> get into this further except to say that I am generally a fan of dpkg
> and Debian/Ubuntu policy (though admit it doesn't fit well for
> everything, see below).
> 
sorry that was a joke, pushing an extreme pov to sort of make a point
(basically just because its a convention or the way it has been done
doesn't mean its right or should be continued) hence the smiley (which
really should have been a different smiley).

I am not opposed to dpkg at all but I did want to make the point that
we shouldn't only be considering dpkg in our decisions, and just
because dpkg does it, it doesn't mean its the right solution.  A little
extreme again but you get the idea, I hope

>>>  * 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.
> 
> Files can reside in /etc and not be a conffile. How you designate them
> as a conffile or not is irrelevant. dpkg based systems should always be
> FHS compliant, therefore the profiles should be in /etc.
>
right I got that.  My point being there are projects that have moved
stuff out of /etc to deal with this /lib/udev/rules.d/ ...
Generally I think profiles and configuration belong in /etc/ not
in /lib/ but I am amenable to moving them.

>>> 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 find this disappointing. Distributions have package managers. Package
> managers handle conffiles according to distribution policy. Distribution
> policy is based on years of experience of working with different
> applications and scenarios and most importantly providing a consistent
> interface with the OS. Engineers design rulesets and package them for
> distributions according to distribution policy. If the policy has to be
> adjusted all the time, then the engineers should not make the profile a
> conffile and simply deal with it in another way.
>
yes and no, package managers are good at some things, not so good at
others and often distro come up with rules and solutions that are
less than ideal to deal with them.  I'm not saying the package manager
shouldn't be used, in fact I am trying to find a solution that I
think works with the package manager.  My problem is I don't think the
current solution works well.

> The local/ solution is intended primarily for adding rules. It is not a
> method radically alter policy. The implementation is also a very
> traditional way to deal with this sort of issue in Debian/Ubuntu. People
> from rpm-based distros often hate this sort of thing, so this
Maybe, I certainly don't hold to because its a traditional way to deal
with it should be the way to go.

> conversation is not surprising. IIRC there was pushback for support of
> force-complain. and disable/. I also said in the weekly meeting that
> this should perhaps be a distribution specific change, but was told it
> would be good upstream.
> 
and it is.  While I dislike the mechanism it has value, and solves
a real problem, that exists now.  Sure I look at it as a bandaid
solution but that doesn't mean it doesn't have merit or isn't applicable
to more than just debian.

> You even state local/ works well for rule additions. I mentioned in
> another thread that someone *could* add a deny rule if they felt they
> wanted to, but if you look at my response there, in this thread and in
> the actual implementation in Ubuntu, deny rules are not encouraged as a
> method to adjust the profile and only examples of adding access are
> provided. Perhaps the README file could be more clear on this point.
> 
Yep you did and yes local/ works for additions.  I'm not sure I would
say well as I don't like it affect on profiles, and yet I am willing
to accept home.d/ more readily.

One of differences between local/ and home.d/ is semantics of their use.  
home.d/ is meant to allow dropping in multiple different values from
multiple different sources and the directory accommodates that well.
With local/ you just have a single file to single file type situation
so it doesn't have the same type of affect or trade off.

>>> 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.
> 
> Sorry, no. We disagree. :) This is one of the foundations of Debian and
> Ubuntu, of which I am a part of. Files in /etc with reasonable defaults
> for the majority of users are conffiles, and we have a package manager
> that handles that well. I think perhaps why we don't see eye to eye is
well we will have to disagree here then.

> that you see the shipped policy as something that is not meeting many
> people's needs, therefore we need a tool to address the many users who
> are adjusting their rulesets. I don't see it this way (see more below).
I don't know how many it is.  I just know it is some and that we could
provide a better experience to them without affecting the experience
of the many.

I also worry because the number of people affected will grow as we ship
more profiles.  What I don't want is people just turning off AppArmor
because it causes problems for them, I would far rather that we make
tweaking as pleasant an experience as possible.

> I am not saying that it handles AppArmor perfectly, and recognize
> deficiencies, which is what I have been working to help solve in Ubuntu
> for a while.
> 
yes and thanks it is appreciated

>>> 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.
> 
> If the profile needs significant tuning for most people, then the
> profile either needs to not be in enforcing mode or adjusted. A merge
right, but the point being if we ship a profile in complain mode then
we are basically saying we know this is something more people are going
to tweak.  I would like to make that experience better.

> tool will not help the initial user experience of 'AppArmor is in my
> way', which is the issue with mysql. You focused on the mysql issue, but
> for all the other profiles we do ship in enforcing mode, this works
> well. I contend it also works well with mysql, but some education would
> be beneficial.
> 
hrmmm, no the right set of tools would help, but that is a separate
issue.  Education definitely helps too.  However I see this as trying
to provide a better experience once a user has chosen to make changes,
which means they have been educated to some degree.  Being user friendly
is going to require all of the above and more.

ie.
* recognizing what is going to work for most people (enforcement choice)
* tools to make it as easy for the user as possible to change that
  choice.
* Copious amounts of documentation, written at just the right level
  so multiple times at different levels with different detail levels
  for different audiences in mind.
* tools to inform the user (thank you for the notifier).
* tools to help modify the policy
* tools to help maintain that policy and basically as much as possible
  stay out of the users way.

>>> 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.
> 
> I do not agree. This is not 'breakage'. One, there shouldn't that many
> people affected if the policy is good enough and two, the user will get
> prompted on upgrade, yes, but upgrades happen seldom for regular users.
> At worst, this is very occasionally inconvenient. As a conffile, users
> are presented with all the information required to make an informed
> decision, especially when considering that they changed the policy in
And here we have to disagree again.

> the first place. Could this be better? Sure. Should we focus on this
> now?
> 
sigh, maybe, maybe not.  I recognize there are a lot of pressing issues
this one just bubbled to the surface because of local/ and some of
Seth's comments.  At the very least it bares discussing at this point
which is what we are doing.

>>   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.
> 
> The use of local/ is optional. It is done in a fashion that is similar
> to abstractions (which is already familiar) and I disagree that it makes
> the profiles significantly harder to understand. I've stated that its
> intent is for small access changes, not large changes of policy. In
> other words, I am not recommending that a user use a local/ file to add
> 20 deny rules to a shipped profile, but maybe they can use it to allow
> write access to /var/www/foo, and not be bothered with the change on
> upgrade. Users are able to change the shipped policy if they desire.
> 
Well I wouldn't say significantly either, but it does not some degree
and it codifies the practice, and then users start abusing it.  It
makes it so package manager updates that change permissions are
caught by the admin.  Yes if the user cares they can do things to
ensure the package managers prompts for a choice at this point,
but I would like to offer a richer set of options.

>>
>>> 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.
> 
> If it is indeed small, then adding a little access here, or a deny there
> via a local/ file works fine and solves this problem. Yes, the profile
> is not optimized for size or for the particular environment-- if an
> admin wants that, then the admin can change shipped policy and file a
> bug. If they actually modified the shipped profile then they will have
> the occasional prompt. I really don't see this as the end of the world,
> especially when there are more important things to be done as an
> upstream.
> 
Yes, I'll agree.  But at the same time I have seen these fixes and
accommodations accumulating for years and I am getting more wary of them.

>>>  * 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.
> 
> It is not exactly the same-- the user specifically chose to use local/
> to add some access. Since you implied the merge tool would create an
Did the user choose to use it?  Or was it done automatically by a
tool?

> optimized policy, this could conceivably create a policy that looks
> foreign to the user and create confusion. "Ok, I added access
> to /srv/exports. I upgraded and the profile changed. I see it now
> has /srv/**. I guess that works ok... I wonder what happened to my
> change?" This could make tracking changes more difficult to audit as the
Yes this could be a problem and in general such tool needs to strive
to keep original rules where possible.  I am not looking for it
to provide an optimized policy but I am striving to not make it
worse.

> entire policy needs to be looked at rather than knowing "these are my
> rules and these are my distro's rules". Finally, with enough
> modification, optimization and flattening, the /etc/apparmor.d/ policy
> will become significantly divergent from the reference policy,
> potentially leading to confusion. 
> 
you could do that.  I really don't want to.  You really do want to
keep the structure of the original profiles where possible.  I'll
agree with you that there is the potential to diverge and it is
a problem.

>> 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.
>>
> Thank you, this is a much clearer explanation, and as an upstream I see
> this as valuable. TBH, while it makes it easier to read, I have always
\o/
> felt that having the profile mode specified in the profile itself is not
> correct because it is mixing the ruleset with how its applied on the
> system, which makes the necessity for a merge tool or packaging tricks a
> requirement when it doesn't have to be. Perhaps it would be better to
> separate profile mode from rulesets. That would eliminate several
> issues. As it is now and considering that a package manager can handle
yes and no.  Having the mode as part of a profile makes it immediately
obvious to a user but you are right it is mixing state and policy.
Its a trade off and generally I will agree with you that sticking the
state in the profile is wrong, and its a historical decision that
I am willing to consider deprecating and killing.

Currently we have the problem that a profile can have its state defined
in multiple ways.  Eg I can write enforcing in the profile and then
add a symlink in complain/, bleh

I have just never been a fan of the symlink solution, partly because
it is insufficient to express what is needed when a file contains
multiple profiles or hats.

> most of these cases already (while perhaps imperfectly in some
> circumstances), I still feel it is more important to focus on other
> areas, such as getting the user space tools in better shape.
> 
yes, with a caveat or two I can agree

>>> 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.
>>
> Maybe, and I did say I was not unbiased. That said, dpkg-based systems
> provide an expected behavior for administrators and deviating from that
> behavior at the distribution level needs to be very carefully
> considered.
> 
Agreed.

>>> 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.
>>
> Well, I can rip it out of upstream easily. I always thought it more of a
> Ubuntuism that the tools should support but not necessarily throw in the
> face of all AppArmor downstreams. I don't want to turn AppArmor into a
> specialized Ubuntu-only MAC. Far from it. That said, I do want it to
> work well with Ubuntu/Debian conventions and policy.
> 
Hrmmm and here is where pragmatism steps in.  I really dislike local/
but, it is a solution to a problem that is implementable now, and as
much as I dislike it (which is probably an over reaction) I don't
necessarily see this as a point where upstream and Ubuntu/Debian should
diverge.

This is a real problem for rpm based systems as well and I can offer
any better immediate solution (as much as I would like too).

> I feel like I kinda stepped into a long-standing argument, and while I
oh boy, you missed out on some epic packaging/merge tool debates/arguments.

> can be a perfectionist at times, I am also pragmatic. I don't have a lot
> of time to strive for perfection when something is good enough. The
> implementation we have in Ubuntu is not a simple or easy as it could be
> and would benefit from a merge tool, but it does work now with
> longstanding conventions that Debian/Ubuntu administrators understand
> and are comfortable with.
> 
yeah

> Bottom line, my perspective is this:
> 
> 1. I strongly believe that if a distribution ships a profile, they
> should stand behind it and make it work without modification for most
> people. If a profile can't be designed in this manner, then it should
> certainly not be shipped as a conffile. This minimizes prompts on
> upgrade
I can't fully agree on this point but maybe that is just the failed
packager in me.

> 2. package managers know how to deal with things like conffiles. There
> are other tools available to work with package managers for dealing with
> non-conffiles (like ucf). These have been around a long time, are well
> understood, and do what they do well.
well I'll disagree.  I think there are a whole set of problems that
package managers have never dealt with well, but merely evolved solutions
that kind of work.  But lets not go there :)

> 3. people really don't upgrade that often and IMO it is not unreasonable
> for someone to be expected to be infrequently prompted when they opted
> into policy changes. Spun right, you could say this encourages people to
> review policy changes, which is good
Uhmm, many people potentially "upgrade" all the time.  Every stable
update is a potential policy "upgrade" point.  Thankfully we don't
change policy often.

I agree that reviewing policy changes is good, even necessary for a
good admin.  But I do want to make that process as simple and
infrequent as possible.

> 4. while no package manager is optimized for AppArmor profiles
> (particularly due to mode being with rules), using one along with the
> distribution OS policy and techniques gets us most of the way there
Hrmm maybe???

> 5. there is a lot of work that needs to be done in other areas. Out of
> necessity Ubuntu and presumably other distributions have methods to
> handle profile modes and small changes to shipped policy. Characterizing
> these methods as vile, bandaids, broken, etc is simply overstated
> because they basically do the job.
I am known for overstating, but vile and broken certainly look that
way but I think bandaid is appropriate.  For example just look at
the profile mode subset of the debate.  There are two ways to set
a profile mode, and they can conflict.  The one method mixes policy
and state (bad), and the other method is (in my opinion) less clear
and can't set the state if individual subprofiles (hats or otherwise).

We haven't dealt with the problem directly.  Realistically a single
solution should be chosen (whether one of the above or something
else completely) and the other solutions should be deprecated and
removed.  Sorry sometimes cruft like this really gets to me.

> 6. we don't have a merge tool now. Developing, testing and integrating a
> tool like this will take a *long* time to get right in a distribution.
> While a merge tool could be useful, I strongly feel this energy should
> be directed to other areas of the project.
> 
Agreed.