[apparmor] AppArmor and /etc/

[intrigeri]

Hi,

(reposting here with Marco's permission)

Marco d'Itri:
> I like the idea of enabling AppArmor by default in Debian,

Cool :)

> but I have 
> some concerns about its usage of /etc/: being able to support systems 
> with an empty /etc/ directory is a goal for containers and stateless 
> servers, so it is seriously annoying that we adopted something which 
> depends on a lot of new files in /etc/.

I understand and I totally agree.

> Why are policies generally installed in /etc/ and not in 
> /usr/share/apparmor/?

I'm not sure, but I *guess* that's because of:

1. History: shipping default configuration in /etc has been
   a long-established practice.

   I much prefer the systemd approach, with default config shipped in
   /usr and full support in all tools to override parts of it locally
   (`systemctl edit', `systemctl cat', etc.).

2. Our local override mechanism is incomplete

   Due to limitations in the policy language, some (rare) kinds of
   rules cannot be overridden without editing the original rule, e.g.
   https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/451422

3. Our local override mechanism is Debian-specific

   AFAIK the "#include <local/$profile>" thing is the norm only on
   Debian and derivatives. Christian, what do you do at OpenSUSE?

> Why is /etc/apparmor.d/cache/ not somewhere else?
> If the reason is to not have a dependency on /var/ being mounted

I bet this is exactly the reason (we want to load policy ASAP in the
boot process), but I've been involved in this community only since
2013 so I can't tell for sure.

> then please ship a proper CACHEDIR.TAG file to help backup software.

I didn't know about this. For the record, this is specified in
http://www.brynosaurus.com/cachedir/spec.html and supported e.g.
by GNU tar's --exclude-caches option.

This sounds like a great suggestion to me!

It seems that /etc/apparmor.d/cache is created by the Debian
packaging, so presumably I could easily ship a CACHEDIR.TAG file
in there.

What do others think?

> If there is no "#include if exists" directive that could be used for 
> the /etc/apparmor.d/local/* files then I believe that maintainers should 
> be encouraged to ship empty files instead of each repeating the same 
> "you may modify this" comment (currently we have both styles).

I don't think we have "#include if exists".

If we had one, then I think we should indeed drop these files
entirely. There's a README in that directory, that's just as
discoverable by users as these local override files, and would even be
more discoverable if it was the only file shipped in
/etc/apparmor.d/local/ by default. What do others think? If you agree
it's a good idea, then I'll file a bug report on LP about adding one
such directive (and will try to find someone whose C skills are better
than me, in order to implement it).

Until we have one such directive, then I think we should indeed DRY,
ship empty files in there, and rely on the README being the only
non-empty file by default in /etc/apparmor.d/local/.

In most cases this text is generated by dh_apparmor
(/usr/share/debhelper/autoscripts/postinst-apparmor) so it's easy to
fix this at the distro level: upload dh-apparmor, wait for all
reverse-build-deps to be rebuilt, and at some point request binNMUs to
get rid of the long tail. I can do the dh-apparmor upload. Marco,
would you like to handle the next steps?

> Do we need an apparmor minipolicy?

This might be a little bit premature: I would start with improving the
existing doc for package maintainers on the Debian wiki, and once we
have enough of it and well-defined best practices, I'm happy to encode
them in a more authoritative place.

Cheers,
-- 
intrigeri