[DSE-Dev] Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor

[intrigeri]

Hi,

[adding the SELinux team into the loop]

Steve Langasek wrote (14 Jul 2014 05:44:44 GMT) :
> Why should apparmor be automatically enabled when the userspace tools are
> installed?

Usability: the idea is to lower the barrier for using AppArmor on
Debian. Learning how to install a package is one thing, learning how
to edit /etc/default/grub without any mistake is another. Patrick and
I want to make AppArmor available to the category of users who can
learn how to do the former, but won't learn how to perform the latter
any time soon.

Also, it would make things easier for derivatives to enable AppArmor
without messing with conffiles, and without patching the kernel to
enable it their preferred LSM by default.

> AFAIK this is inconsistent with how selinux is handled, which is
> only enabled via an explicit boot option.

I was not aware of that, thanks for pointing it out.

@SELinux maintainers: is this behavior on purpose, or is it due to the
historical lack of a facility (recently added by the
/etc/default/grub.d support) to easily have a package append arguments
to the kernel command-line?

> Shouldn't we handle our LSMs symmetrically?

Indeed, I think we should. I see several ways of keeping things
consistent while reaching the aforementioned AppArmor usability goal:

a) Having the SELinux equivalent of the apparmor package enable it by
   default too (and then, we'll need conflicts); I've no idea if this
   is feasible; one would need to look at the SELinux packages and
   their chain of reverse-dependencies.

b) Implementing the behavior proposed by Patrick via a dedicated
   apparmor-$something configuration package. ftp-masters likely won't
   be happy with it (understandably), unless we demonstrate it's the
   best available solution to reach a sensible goal. The SELinux team
   is then free to create a corresponding package.

c) A new package whose job is to select and enable a LSM (or none).
   Likely "none" would be the default for now. It's tempting to take
   benefit from debconf here.

d) An apparmor-activate command, very similar to selinux-activate
   (from the selinux-basics package). The resulting user experience
   would be less friendly than "just install the apparmor package",
   but perhaps that's acceptable for now.

Other ideas?

SELinux maintainers, any thoughts on this? I've no idea what's the
current situation wrt. SELinux policies in Debian — are they in
a shape that warrants thinking of usability matters for the target
userbase described above, or do potential users anyway have to play
with a terminal and text editor as root? In other words, should we
work on a shared solution to this problem, or should the AppArmor
folks do their bit on their side, merely being careful not to break
the SELinux usecases?

> (Also, what happens if someone has already enabled selinux, then installs
> this apparmor package which is intended to automatically enable apparmor?)

The *last* LSM activated on the kernel command-line is the one that's
enabled in practice (tested both ways). So, installing a apparmor
package, that automatically enables this LSM, would override the
previous manual enabling of SELinux. The reciprocal applies when
running selinux-activate (which is arguably a more explicit choice
made by the administrator than installing the apparmor package).

IMO, both should first check if another LSM is enabled.

> Regardless, I don't think this rises to the level of something that needs
> to be documented in policy, at least at this point.

Full ACK, we're not there yet. I suggest we drop 754744@ from the Cc
list on next reply.

Cheers,
-- 
intrigeri