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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
