On Sun, Jul 13, 2014 at 11:02:46PM +0000, Patrick Schleizer wrote: > Package: debian-policy > Severity: wishlist
> Suggested policy addition:
> Do not depend on or recommend the apparmor package
> Packages must neither depend on nor recommend apparmor, because it would
> not only enable AppArmor for this package, but for any packages shipping
> an AppArmor profile, which might have unwanted effects. Enabling
> AppArmor should require at least one conscious decision by the user.
> If you are shipping an AppArmor profile, add apparmor to Suggests.
> apparmor-{utils,profiles,profiles-extra} and other packages where this
> is useful are exceptions.
> Reason:
> Before we can automatically enable AppArmor when the userspace tools are
> installed, AppArmor maintainer intrigeri said, we must make sure, that
> no packages depend on AppArmor, so AppArmor does not get installed even
> though the user does not wish this. [1]
Why should apparmor be automatically enabled when the userspace tools are
installed? AFAIK this is inconsistent with how selinux is handled, which is
only enabled via an explicit boot option. Shouldn't we handle our LSMs
symmetrically?
(Also, what happens if someone has already enabled selinux, then installs
this apparmor package which is intended to automatically enable apparmor?)
Regardless, I don't think this rises to the level of something that needs
to be documented in policy, at least at this point. It seems to me that
this should be dealt with by convention among the cooperating group of
packages, with hints from lintian, and doesn't require a statement in policy
itself.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
