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

[Mika Pflüger]

Hi,

I certainly can't speak for the whole team, but can offer my thoughts
about the situation of SELinux at the moment.

intrigeri <intrigeri at debian.org> 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?

I think both. Installing the default SELinux policy and enabling it
routinely breaks all kinds of stuff (avahi-things, booting with
systemd, obtaining IP addresses via dhcp, hotplugging of network
interfaces etc. just to name some things that popped up in testing or
stable during the last year), especially things not usually tested on
servers run by the more security-aware part of the linux admin
population. So for the regular user (unfortunately), enabling selinux
simply by installing the policy package would certainly feel a lot like
a grave bug ("breaks unrelated software").
> 
> >> 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.

However, I think this could be pretty reasonable, given
1) it would be e.g. a "selinux" binary package doing this, not the
library or selinux-basics/utils package. This binary package does not
exist at the moment, but could be created.
2) it would ask via debconf before enabling.
> 
> > 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.

This is basically a) for selinux, as there is no "standard selinux
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?

For the users we are currently targetting, selinux-activate is
adequate, but a debconf question would certainly be easier. We are
(slowly) working on getting better user experience, but yes, people
still have to play with a terminal as root for jessie, I'm afraid.
> 
> >> (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.

That sounds like a good idea. It would be nice to have some kind of
standard way to tell if any other LSM is enabled, otherwise we all have
to maintain some 
selinuxenabled | $apparmorenabled | $whateverelseenabled
shell snippets on our own.

Cheers,

Mika

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/selinux-devel/attachments/20140829/c8325343/attachment.sig>