[pkg-apparmor] Bug#879590: apparmor: Decide how we enable AppArmor by default

intrigeri intrigeri at debian.org
Wed Oct 25 15:09:58 UTC 2017


Hi,

intrigeri:
> Next step: figure out how to actually pull AppArmor utilities & policy
> by default (enabling the LSM is not very useful if we don't install
> those too).

For new installations, making the apparmor package "Priority:
standard" seems to be the way to go. I've trimmed its dependencies
a bit (to be uploaded as 2.11.1-2) so it seems to be an OK thing to
do. I'll ask on -devel@ if there's a problem with that, once I have
something to propose for the following problem.

But I'm not sure what's the best way to pull the apparmor package:

1. on testing/sid upgrades, during the Buster dev cycle: this would
   greatly increase the value of the "enable AppArmor by default for
   a while" experiment;
2. during Stretch to Buster upgrades: this seems necessary so every
   user gets the AppArmor benefits, regardless of when they installed
   their system initially.

I could not find anything better so far than having another package,
that's already installed by default, add a "Recommends: apparmor" (I'm
assuming that APT installs newly recommended packages by default on
upgrade). This feels artificial and rather ugly, but it might be the
only option. I'll ask more people around.

FTR Ubuntu installs the apparmor package by default using something
that has a very similar definition to "Priority: standard":
http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.artful/view/head:/standard#L73
(the parenthesis around the package name means it'll be a Recommends,
not a Depends, so it gets installed by default but the user may choose
to remove it). But we don't use germinate so it's not useful for
Debian. They don't install apparmor-utils by default.



More information about the pkg-apparmor-team mailing list