Stephen Smalley wrote:
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.
That, at least, is somewhat a relief.
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.
I'm sure it's not the only one. :-)
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()
How about implementing a library with just appropriate stubs?
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...
If it had been done right the first time...
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
