Re: New stacker performance results

From: Stephen Smalley (sds@private)
Date: Wed May 25 2005 - 09:36:59 PDT

On Wed, 2005-05-25 at 09:23 -0700, Casey Schaufler wrote:
> In the Unix Era we made our share of mistakes,
> especially with add on module interfaces and
> extreme security implementations. STREAMS modules
> and Information labels come to mind as prime
> examples. I can think of no instance where the
> two types of facilities were combined into the
> same blunder.

I'm not sure I follow your meaning above; it almost sounds like an
indictment of LSM, which is a module interface for security
implementations, not SELinux, which is a particular security
implementation that presently leverages LSM but was originally
implemented as a direct kernel patch that involved no kernel module at
all.  Even now, SELinux is not truly a kernel module; it has to be
built-in to be used, and is tightly coupled to the core kernel since it
implements the full range of LSM hooks (not necessarily every individual
LSM hook, but a fairly sweeping set covering all kernel subsystems).

> SELinux is a poor choice for a general framework.

Flask/SELinux was designed as a flexible MAC framework.  Feel free to
suggest your own, but be ready to provide supporting documentation of
how it has been analyzed for its ability to represent a wide spectrum of
security models.  Such analysis has been done and is available in
publically available reports for SELinux.

> While Type Enforcement may be used to implement
> many interesting policies it is far from universal.

SELinux isn't limited to TE, although it is certainly a useful building
block security model.

> SELinux is not a lightweight implementation, and
> would be overkill if all you wanted was a minor 
> policy such as time-of-day access restrictions.

Time-of-day restrictions can be implemented via the conditional policy
support in SELinux.  More generally, if there is a security model that
is useful that cannot be presently expressed via SELinux, extending
SELinux to support it should be more straightforward than having to
implement an entirely new security module from scratch.

> SELinux associates rights and privileges with
> programs, a paradighm that has it's detractors.

Aside from the fact that such detractors are wrong, SELinux doesn't
force this paradigm, it just allows it.  One can certainly write a TE
policy that only assigns rights to users and does not distinguish
programs at all.

> But the most important problem that I see from
> here is that nowhere is there a complete and
> accurate description of how, *in general* one
> would go about creating an arbitrary and
> complete policy using SELinux.

Sorry, a "complete" description of how "in general" one might create an
"arbitrary" policy?  The assumptions force the conclusion.
Stephen Smalley
National Security Agency

This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 09:46:30 PDT