[apparmor] Packaging of Profiles

[Jamie Strandboge]

On Tue, 2010-08-10 at 03:52 -0400, John Johansen wrote:
> On 08/10/2010 12:50 AM, Jamie Strandboge wrote:
> > On Mon, 2010-08-09 at 19:18 -0400, John Johansen wrote:
> > I see we have a long road ahead of us. Your 'death to dpkg' comment 
> 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).
> 
Believe it or not, I took it as such. :) But based on other comments in
the thread, I felt I needed to say something.

> 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

Oh gosh no and I was not suggesting this. If I came across this way, I
apologize. I was merely trying to say that dpkg and Debian/Ubuntu policy
is what it is for a reason, and works well in many (but not all) ways.

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

I agree with all this. Seems weird outside of /etc, but I have no strong
opinion if templates/references/whatever is somewhere else as long as
admin configuration happens in /etc.

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

Kees said it best-- how Ubuntu is handling AppArmor is cultural. I
maintain Ubuntu's solution may not work perfectly, but it works well
enough for now in its culture. Other distributions are free to manage
AppArmor how they see fit, and a tool from upstream would be beneficial,
though not required.

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

I am saying, "in Ubuntu, it is the way to go *for now*". Other
distributions are free to pick and choose from what we've done and/or
push changes upstream for review and acceptance for their solutions as
well.

> > 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 absolutely agree with all of this, but my feeling is that if someone
is going to turn of AppArmor, it is because of inappropriate policy
decisions by the distribution supporting those policies. In other words,
I installed Apache; it doesn't work; I uninstall AppArmor. Good policy
is the best preventative medicine here. Once they are at the point of
modifying policy, we've more or less won because they are using the
system-- they aren't going to turn it off because of a prompt in an OS
upgrade. Security updates for a stable release generally will not update
policy (firefox in Ubuntu has been an exception, but work in this area
is ongoing) and therefore dpkg will not prompt (remember, dpkg should
only prompt if the updated package ships a different conffile than
before *and* the existing conffile is different from both the old and
new).   

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

Yes.

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

Agreeing to disagree I think is ok here. :)
 
> > 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.

Some people will abuse anything you put in front of them. I think I will
update the README file in local/ to be explicitly clear to help avoid
confusion. That will codify the intent of local/ at any rate.

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

If as upstream shipping disable/, force-complain/ and local/ is too
weird or culturally biased, we can do that in Ubuntu (and eventually
Debian) only. I do think the tools need to still support it though.

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

As implemented today in Ubuntu, apparmor-profiles and all shipped
profiles (except firefox, which is still being worked on) have something
like this in the shipped profile:
  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.sbin.tcpdump>

With the local/<file> containing something like:
# Site-specific additions and overrides for usr.sbin.tcpdump.
# For more details, please see /etc/apparmor.d/local/README.

This file is created automatically if it does not exist, but otherwise
is totally untouched by the package manager. If a user wants to use it
to modify policy, they need to opt into it.

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

There are pluses and minuses to the mode being in there.

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

Agreed and I would like to get rid of force-complain and disable. We can
do this quickly if mode is moved out of the profile.

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

Well, then it is good I am stirring the pot now then. :)


> > 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 addressed this above. A security/bugfix update should not generally
update policy, so on a dpkg-based system a changed profile should not
get a prompt. Only when a user changes policy and shipped policy changes
is there a prompt (typically only on OS upgrade).

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

Maybe? Clearly. :) You said rpm and dpkg suffer from the same sorts of
problems, which is why you want a merge tool. Maybe Slackware does
better, I have no idea. :)

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

I would love for profile mode to be moved out somewhere else so neither
the package manager or the merge tool need to deal with it.

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

Evaluating the current state is healthy and welcome. :)

-- 
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/20100810/f54f1038/attachment.pgp