not installing SELinux with Fedora

[Stephen Smalley]

On Thu, 2005-06-23 at 11:58 -0700, stewartetcie at canada.com wrote:
> Beware of forks masquerading as subsystems. The offer
> of mandatory access control is seductive, but the
> SELinux implementation is flawed if it amounts to a
> fork in the Linux code base.

It doesn't.  SELinux is upstream, in the mainline kernel.  No forking
here.

> If that were the only problem, it would be enough to
> preclude the inclusion of SELinux from a general
> purpose Linux distribution until such time as good
> management tools are available.

Chicken and the egg problem.  People aren't motivated to create good
management tools until they see that the system is mainstream.  What
management tools exist for POSIX ACLs on Linux?  Yet the kernel
mechanism is included, which allows people who want to do so to leverage
them.  In much the same way, including SELinux with a relatively simple
policy (targeted) is a natural first step.  And there are certainly
other kernel features that have followed the same path.

> One candidate is Linux (a. k. a. non-SELinux). If I
> have to roll my own distro from Fedora in order to
> optimize performance by removing unnecessary
> subsystems, such as mandatory access control on an
> isolated system, then Fedora is no longer a general
> purpose system and it is no longer Linux, now it is
> SELinux.

Um, no.  First, you can completely disable SELinux, at which point it is
no longer registered with the kernel's security framework and imposes no
performance overhead.  That actually goes well beyond what many kernel
features offer, most of which are going to be enabled in a stock Fedora
kernel simply because it is intended for general use.  Second, you
always have the freedom to rebuild the Fedora kernel SRPM or an upstream
kernel with SELinux completely omitted.  You are applying an unfair
criteria to SELinux that doesn't exist for any other kernel feature.

> These comments are offered in the spirit of
> constructive criticism. I'm grateful you declared your
> bias, for your spirited defence of your product and
> very grateful SELinux was contributed to the open
> source community, warts and all. However, SELinux isn't
> the only possible implementation of mandatory access
> control for Linux (cf. sHype). If my criticicms are
> valid, SELinux must either be improved, or it'll be
> replaced by a better implementation. Perhaps I'm wrong.
> Time will tell. Meanwhile, thanks for listening.

It is certainly true that SELinux is not the only possible
implementation of MAC for Linux, although I think you are
misunderstanding the sHype report itself (don't confuse their
explanation of how virtualization offers stronger isolation with fewer
shared resources vs. finer-grained controlled sharing available via
OS-level controls as a criticism of OS-level MAC - they are just
explaining the differing roles played by virtualization vs. OS-level
controls).  And you are certainly free to use any such alternative MAC
implementation you wish; just disable SELinux (via selinux=0 in your
grub.conf or via /etc/selinux/config SELINUIX=disabled) and load your
favorite loadable module (of course, if your alternative MAC
implementation requires a kernel patch, then you'd need to rebuild your
kernel with that patch, but that is not affected by SELinux in any way).
So your freedom is not limited in any manner by SELinux being included
in Fedora.

But remember that SELinux is:
- upstream (in the mainline Linux 2.6 kernel),
- open source (kernel code and userland and policy),
- a truly community-based project (with significant contributions by
external developers and users) ever since its initial release by the NSA
in 2000,
- a generalized access control architecture and model suitable for a
general purpose operating system,
- extensible to support application security needs.

So don't dismiss it too quickly.  Thanks ;)

-- 
Stephen Smalley
National Security Agency