How NSA access was built into Windows

[Stephen Smalley]

On Thu, 2007-01-18 at 22:55 -0500, Todd Zullinger wrote:
> Peter Gordon wrote:
> > Also, you can boot with 'selinux=0' to disable SELinux for that
> > system session; or (if the system is already running), run the
> > following commands as root to make SELinux switch to passive mode or
> > be disabled entirely (respectively):
> > 
> > # echo 0> /selinux/enforce
> > # echo 1> /selinux/disable
> > 
> > SELinux, while an excellent technology and highly-recommended for
> > its security benefits, is not a mandatory aspect of a Fedora
> > installation.  If you do not feel it is needed, then you are free to
> > disable, remove, or prevent it from being installed entirely. 
> 
> The discussion on removing it was regarding how to remove all of the
> selinux bits from an installation, for those that didn't trust just
> disabling it.  I'm not one of those advocating that position, but
> merely commented on what you'd need to do to truly remove it. :)
> 
> I don't think that you can *remove* it from Fedora in any easy way.
> Please correct me if I'm wrong about that.

Aside from rebuilding from source with selinux options disabled in the
compile-time configuration, you are correct - you cannot remove the
actual selinux bits from Fedora at runtime, although you can disable
their execution (boot with selinux=0).  Performing an audit of the code
associated with disabling SELinux at boot time isn't difficult, and
doesn't require understanding the rest of the SELinux code that is never
reached in that case.

The entire discussion of allowing one to rpm -e libselinux is a red
herring; applications already perform an is_selinux_enabled() test
before performing SELinux processing and skip it if disabled. Supporting
removal of libselinux would just mean that those applications would
first dlopen() libselinux (vs. direct calls to the libselinux functions,
which create the current fixed link-time dependency) and fall back to
the selinux-disabled code path if libselinux isn't present.  But in both
cases, you are relying on the application code to follow the right
branch and to truly skip all SELinux processing when selinux isn't
enabled / libselinux isn't present.  It might make a difference in terms
of code bloat (although libselinux isn't that big and you are trading
off runtime performance for the dlopen), but it doesn't change the trust
issues.  It also doesn't change the situation wrt to the selinux kernel
code, which is built-in.  We played around with trying to support it as
a loadable kernel module long ago, but it wasn't practical (tight
coupling with the core kernel is inherent in the goal of mediating
access to all kernel objects and requires very early initialization,
prior to normal module init), and the mainline kernel developers
actively discouraged us from pursuing it.

-- 
Stephen Smalley
National Security Agency