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

[Russell Coker]

On Mon, 14 Jul 2014 19:13:29 intrigeri wrote:
> > 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?

The SE Linux support predates the /etc/default/grub.d support.  But even if it 
had been there I still probably wouldn't have done it automatically.  There 
are situations where you want to install things without activating them and 
there are situations where things get dragged in by dependencies but you don't 
want to use them.

> 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.

This doesn't sound like a good option.

> 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.

That would work.  The current selinux-activate is a hack that should go away.

> 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.

I'd be happy to have selinux-activate check for other LSMs and warn the user.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/
-- 
Sent from my Samsung Galaxy Note 3 with K-9 Mail.