On Wed, 2004-04-21 at 04:40, Gene Czarcinski wrote: > On Tuesday 20 April 2004 22:25, Jeremy Katz wrote: > > Disabled like the current "disabled" in anaconda right now. Hopefully > > Stephen Smalley's patch to allow completely deregistering SELinux hooks > > from before policy gets loaded won't get torn apart too badly on lkml; > > then we'll do that as well. > > I am unclear on this (anaconda disabled versus selinux=0). Can someone > explain? The selinux=0 boot parameter is handled by the kernel and causes SELinux to immediately abort initialization, so that it never registers as a security module with the kernel, never registers its NetFilter hooks, and never registers the selinuxfs pseudo filesystem (no-selinux for short). The boot parameter was introduced by RH to support shipping a single kernel with SELinux included while still allowing for disabling of SELinux. But Jeremy later informed us that kernel boot parameters are difficult to employ on certain platforms, so RH looked for another approach that would be more portable across all platforms. The /etc/sysconfig/selinux disabled setting is handled by /sbin/init and occurs after SELinux has already performed basic initialization (but before policy load), and merely causes SELinux to proceed under permissive mode with no policy loaded (permissive/no-policy for short). permissive/no-policy looks very similar to no-selinux in behavior, but isn't quite identical and still imposes processing overhead on kernel operations. To address this problem, we have developed and submitted a kernel patch for the SELinux module that adds a runtime disable that can be invoked prior to the initial policy load, so that /sbin/init will be able to truly disable SELinux, unregistering its security hooks, NetFilter hooks, and the selinuxfs filesystem. The patches were posted to lkml and the NSA selinux mailing list, and are now in 2.6.6-rc2-mm1 and have been submitted to Linus (but are not yet in bk). Once a kernel is released with this support, /sbin/init can be updated to use it. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
