[apparmor] Location for extra profiles

[Christian Boltz]

Hello,

(answering on the ML since there isn't much discussion in the bugreport)

@Ludwig: you started this, therefore feel free to comment on the 
AppArmor ML ;-)

Am Mittwoch, 24. August 2011 schrieb John Johansen:
> On 08/23/2011 02:48 PM, Steve Beattie wrote:
> > On Tue, Aug 23, 2011 at 07:51:38AM -0700, John Johansen wrote:
> >> On 08/23/2011 05:14 AM, Christian Boltz wrote:
> >>> there's an openSUSE enhancement request to move the "extra"
> >>> profiles to /lib/apparmor/profiles/.
> >>> 
> >>> See https://bugzilla.novell.com/show_bug.cgi?id=713647 for
> >>> details. (You can also comment there so that I don't have to
> >>> forward the answer.)
> >>> 
> >>> Do you like the idea of moving the "extra" profiles to /lib/?
> >>> What changes would be needed so that genprof still finds them?
> >> 
> >> Well I am not opposed to re-examining this as I don't really like
> >> the set up we currently have. I am not opposed to moving the
> >> "extra" profiles out of /etc/ but I don't really like /lib/ as a
> >> location (though I can see why people would choose it).

Using /lib/ doesn't really make sense - my understanding is that /lib 
should contain libraries etc. that are needed for booting and single-
user login (even if /usr/ is not mounted for whatever reason).
AppArmor profiles that are only used as template for aa-genprof 
obviously don't match this.

Maybe /usr/lib/ would be an option if you really want a path with "lib" 
- but I don't really like this idea.


I'd say /usr/share/apparmor/profiles/ would be a nice place and would 
fit the "definition"/intended usage of /usr/share best.
(Opinions? Better ideas? Flames?)

> > As upstream, I don't think we can really dictate to distributions
> > where they should place them. For the record, the extras profiles
> > get installed into /usr/share/doc/apparmor-profiles/extras/ on
> > Ubuntu.

Hmm, the profiles aren't documentation IMHO.

(You could consider them documentation of which files a programm 
accesses  [1], but then they would need to be in /usr/share/doc/$program 
;-)

> Right, but we could discuss where we put them by default (ie
> reference location).

Exactly. And I'm sure there are good chances that distributions accept 
the default location if it makes sense and saves them some work (as in 
"no need to move them elsewhere").

> > I think probably the best thing would be if the location that
> > distribution vendors chose to place them was captured in a
> > configuration file in /etc/apparmor/; that way, tools to manage
> > profiles would know where to look for the extras profiles.
> 
> yeah this is a very good idea.

You mean like in /etc/apparmor/logprof.conf

[settings]
  inactive_profiledir = /usr/share/doc/apparmor-profiles/extras

Funnily this example comes from openSUSE 11.4, which has the profiles in 
/etc/apparmor/profiles/extra/ - but that's not too surprising because 
the (in the meantime unused) [repository] section says 
distro = ubuntu-intrepid ;-)

I guess aa-logprof has some hardcoded default paths that are used as 
fallback if logprof.conf contains funny things?

> >> Just where the "extra" profiles should go will depend on your pov
> >> of how they should interact with the active profile set and what
> >> should be done at the packaging level.
> >> 
> >> For example should the "extra" profiles really be a reference set
> >> that the packaging system expects not to change, with the active
> >> set symlinking to them.  Or do you want the packaging system to
> >> actively manage the active set as conf files so that when a
> >> conflict occurs it is immediately apparent.
> > 
> > Historically, the upstream expectation has been that the "extras"
> > profiles are incomplete and could/should be used as a starting
> > point for profile development (with the hope that improvements
> > would be contributed back). 

That's also my understanding, and also means that the "extras" profiles 
are installed read-only - the real work is done on the copy in 
/etc/apparmor.d/. read-only files are the natural enemy of living in 
/etc ,-)

> > It was the way for profile developers
> > to collaborate before the apparmor repository (now dead) was
> > developed. Ideally, policy distribution and development would get
> > separated from implementation.
> 
> well not exactly dead as the online repo still exists
>   http://apparmor.opensuse.org/
> and the base ability still exists in the tools.  But it has bit
> rotted for years and needs some serious updating/replacing.
> 
> But whether or not a repository exists doesn't currently matter
> to the discussion of where we store profiles locally.

Independent of the technical implementation of the profile repo, I'm 
still missing an interactive merge tool for profiles. I'm dreaming of 
something like aa-logprof that reads another profile instead of an 
audit.log. The user interface could work exactly like aa-genprof.

But you are right, that's a totally different discussion...


Regards,

Christian Boltz

[1] that's one of the reasons why I like AppArmor - it gives me a nice 
    inventory list. For example, I can see which apache vHost uses which 
    of my server-wide shared scripts. This can be quite useful when 
    thinking about possibly incompatible changes - "will I have to fix
    one page or 100?" ;-)
-- 
Ich hasse Kabel, denn sie haben zwei Enden und meist sitzt an jedem
Ende ein Anderer, der schuld ist.      [Thomas Arend in suse-linux]