[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How NSA access was built into Windows



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]