On Sat, 2007-01-20 at 07:44 +1030, Tim wrote: > On Fri, 2007-01-19 at 07:40 -0500, Stephen Smalley wrote: > > 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. > > For some people, having it running certainly causes a performance loss. > Whether that's down to SELinux, itself, or the logging, I've not > experimented with. The difference I mentioned above was between the current scheme for disabling selinux at runtime (relying on the is_selinux_enabled() checks in the applications to fall back to the correct branch) and the hypothetical scheme of dlopen'ing libselinux and falling back to the selinux-disabled branch if it is not present. Not the performance difference between selinux enabled and selinux disabled. SELinux does have some performance overhead when enabled, naturally. -- Stephen Smalley National Security Agency
