On Fri, 2007-09-21 at 13:31 -0500, Mike McCarty wrote: > Arthur Pemberton wrote: > > > > I either run it (in targeted mode) or I don't - I do on servers, don't > > on desktops/laptops > > Then we are agreed on this point, at least: If SELinux has benefit, > then it is still an installation dependent issue whether the > cost outweighs the benefit, or vice versa. I have a desktop which > has exactly one LAN connected machine, my firewall. The firewall > on the WAN side is connected exactly to one machine, an ADSL modem. > > It does not make sense to install and run software which one does > not ever intend to use. Simply having it on the machine but disabled > makes the machine potentially less secure, but gives no benefit. > Even "disabled", it is present, and code is actively being executed, > though I'm sure much less of it gets executed than otherwise. The SELinux kernel code unhooks itself from the kernel code paths if you use SELINUX=disabled in /etc/selinux/config (and never hooks at all if you use selinux=0 in grub.conf). So the kernel code is not actively executed when disabled. The userland code should be doing an is_selinux_enabled() check before doing SELinux processing, and skipping it if disabled. If not, then that's a bug. If you want to be able to remove the libraries (e.g. libselinux), someone would need to rework the users of the libraries to use dlopen() and friends to dynamically lookup the selinux symbols and fall back to non-selinux behavior if not present rather than linking against libselinux at build time. Doable, but at a cost (in time to rework all calling code, and in runtime for the dlopen). If you want to make that happen, patches that implement such changes are the best way... -- Stephen Smalley National Security Agency
