[Security_sig] 10/14 Conf. call minutes

Stephen Smalley sds at epoch.ncsc.mil
Mon Oct 18 13:18:41 PDT 2004

On Mon, 2004-10-18 at 12:41, Serge E. Hallyn wrote:
> Absolutely, and if SELinux is being used on the system at all, then it is
> important to use SELinux for the audit data protections.  To do otherwise
> would be begging for odd interactions leading to data leakage.

Ok, glad to hear that you hold this view.

> Nevertheless, the existance of a small audit data protection LSM would be
> useful for those who are unwilling or unable to use SELinux on their
> systems.  To do this wouldn't take anything away from SELinux itself, and
> would (IMHO) be of tremendous use to quite a few people.

Possible points to consider:
- Rather than creating a separate LSM, the same resources could be
applied to addressing the issues that might prevent them from wanting or
being able to use SELinux.  Consider the example of NEC; they took
constructive action to significantly improve the scalability of SELinux,
overcoming a significant barrier to adoption by many users.
- Creating a separate LSM that provides protection even just for the
audit infrastructure (including its userland components, log files, etc)
should be more costly than just configuring SELinux for that purpose. 
You are going to have to deal with many of the same issues, and
duplicate a fair amount of functionality, both kernel and userspace.
- SELinux is gaining the benefit of the community feedback, testing, and
integration now, particularly in Fedora Core and Hardened Gentoo, but
apparently also in other distros.  What is the likelihood of that
happening for a new special purpose LSM?
- There seems a reasonable likelihood that if such special purpose LSMs
are created and deployed, people will begin to want to stack them with each
other and with SELinux.  Such stacking is problematic, even if we assume that 
the kernel is enhanced in the near term to support the mechanism; as you noted
above, odd interactions among the kernel mechanisms are likely, and userspace
will be even worse.

>   Whether or not
> SELinux is "too complicated" would then resolve itself over time.  Personally,
> I expect the answer to slowly converge toward "no" over time.

The danger is in self-fulfilling prophecy:  people complain that SELinux
is too complex to deploy without applying any resources to improving the
situation, and thus the problem is never solved and unsurprisingly,
adoption is hindered or at least slowed.  SELinux didn't create the
complexity; it merely reveals the complexity that is occurring on real
systems and provides a mechanism for controlling it.

In any event, thanks for responding constructively.		  

Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency

More information about the security_sig mailing list