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
