[Security_sig] 10/14 Conf. call minutes

Stephen Smalley sds at epoch.ncsc.mil
Fri Oct 22 09:15:54 PDT 2004

On Thu, 2004-10-21 at 17:16, slav at vogon.net wrote:
> IMO today SELinux is a
> good niche solution where fine-grained control does matter, however it's
> an overkill for someone who needs a generic tool to address a generic
> problem, with little deviation from baseline, in many places at once, with
> minimum cost.  There are several higher-level tools already out there that
> take the administrative overhead problem into account (like LIDS and
> SEOS/eTrust Access Control), neither of which are part of the Linux kernel
> (last I checked LIDS wasn't).  Seeing a tool as powerful as SELinux be
> part of the kernel is a good first step, a good second step would be to
> make the tool useful to the masses, while preserving its low-level
> features for those who really need them.

Thanks for your feedback.  The obvious question is why is it preferable
to deploy a limited-by-design solution than to deploy a general
mechanism like SELinux with a suite of policy configurations and tools
that make SELinux look like the limited-by-design solutions for those
who want that interface.  The latter lets you address the needs of a
wider user base with a single platform (just differing configurations
and toolsets) and lets you evolve that platform's security capabilities
over time much more easily.  It also provides you with a sounder
foundation for your protection mechanisms; focusing only on the higher
level interface lends itself to oversights at the low level.  And, as
you say, none of those other solutions are in the Linux kernel, which
has implications of its own...

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

More information about the security_sig mailing list