How best get rid of SELinux?

Stephen Smalley sds at tycho.nsa.gov
Fri Sep 21 20:06:45 UTC 2007


On Fri, 2007-09-21 at 14:28 -0500, Mike McCarty wrote:
> Stephen Smalley wrote:
> > 
> > Just to clarify (trying to avoid the flame fest here):  SELINUX=disabled
> > in /etc/selinux/config on any modern Fedora system should truly disable
> > SELinux in the kernel, by having /sbin/init write a "1" to
> 
> What you just wrote is not possible. At the very least, the code
> which checks the state of the enable flag must be present
> and active in memory.

Once SELinux has been disabled (via selinux=0 or SELINUX=disabled), its
kernel code is no longer executed, as it is unhooked from the kernel
code paths at the time of disabling.  The LSM framework is still
executed, if that is what you mean, but that framework is present to
support any kernel security module, including the Linux capabilities
model.  When you call open(2) or other syscalls after SELinux has been
disabled, no SELinux code is run, only the LSM framework code.

> [snip]
> 
> > Permissive mode is different - SELinux stays active on the code paths
> > and while permission checks are always granted, there are other possible
> > failure paths.  However, if you (here you == any user) find that
> > something is broken in permissive mode, please file a bug report so that
> > it can be examined to see whether it can be resolved.
> 
> What you write here is just as applicable to "disabled" state
> as it is to "permissive" state, just presumably less code
> gets executed, unless SELinux itself gets exploited.

Disabled:  A call to open(2) never executes any SELinux kernel code.
Permissive: A call to open(2) executes SELinux kernel code, using a mode
of operation that logs but does not deny permissions.
It's a fairly significant difference.

> [snip]
> 
> > The agenda is the already stated one, to bring flexible mandatory access
> > control to the mainstream in order to counter the threat posed by
> > malicious and flawed programs.  Nothing more, nothing less.
> 
> It would be nicer if the mandatory access control were an
> optional feature for those who don't want it.

They are optional.  Look, we provided multiple ways of disabling the
kernel code (selinux=0 at first, then SELINUX=disabled because some
people don't like boot params), and bracketed the userland code with
is_selinux_enabled() checks.  If it weren't optional, there would be no
SELINUX=disabled at all.  Possibly the degree of "optional" can be
improved, but that requires work on someone's part, always comes with a
cost, and it isn't clear that anything less than a full source rebuild
with SELinux build options disabled would satisfy you.  You can already
disable SELinux at runtime, and you can already rebuild the distro from
source with SELinux disabled at compile time.  What else did you want to
do?  yum remove libselinux?  Ok, that one requires someone to take the
time to patch all of the applications that now call it directly to
instead use dlopen+dlsym and fall back to non-selinux behavior if not
present.  Which can be done, but someone has to do it, dlopen carries a
cost at runtime, and that still leaves the code to perform the dlopen
+dlsym and to switch between the selinux and non-selinux code paths in
the application.  Is that worth it to you?  

-- 
Stephen Smalley
National Security Agency




More information about the fedora-list mailing list