[apparmor] Packaging of Profiles

[Jamie Strandboge]

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

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

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

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

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.

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

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

> > 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
the first place. Could this be better? Sure. Should we focus on this
now?

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

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

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

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

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

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

I feel like I kinda stepped into a long-standing argument, and while I
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.

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

-- 
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/7f8ad68b/attachment-0001.pgp