[DSE-Dev] forbid most packages to depend on or recommend apparmor

[intrigeri]

Hi SELinux maintainers,

here's a friendly ping regarding what follows, as I think we're
currently blocked by lack of input from your side. Oh, and if any of
you is in Portland currently, I'd be delighted to meet and discuss
this in person :)

intrigeri wrote (14 Jul 2014 17:13:29 GMT) :
> 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