[Security_sig] 10/14 Conf. call minutes

[Stephen Smalley]

On Thu, 2004-10-14 at 14:47, Chris Wright wrote:
> Doc: Maybe we should make specific LSM's to just protect audit
> subsystem.
> 
> Ed: Agree, small LSM
> 
> Chris: What does this look like?
> 
> Ed: Audit framework, generate LSM that protects audit framework, then
> show that it can protect all of these.  To do this right, generate a
> protection profile.

Gentlemen,

Someone referred me to this posting due to its discussion of creating a
new LSM for audit protection rather than using SELinux for this
purpose.  I hope I'm not intruding by joining this discussion; I wasn't
aware of this list or group until now.

It is unfortunate that several people in this group seem to have
concluded that SELinux is too complex to deploy in this manner.  I would
ask whether this assumption is truly justified.  One can certainly
construct a SELinux policy that is specifically tailored to protecting
the audit infrastructure and nothing else if desired, thereby avoiding
the complexity associated with fine-grained least privilege.

I know that many people find SELinux's use of security equivalence
classes (types) rather than conventional Unix abstractions (paths, port
numbers, etc) confusing, but this is ultimately what one needs to be
able to specify in order to enforce higher level security goals.  While
the Unix abstractions might seem "higher level" to a typical admin, they
are actually "lower level" as far as the real security goals, e.g.
preventing the corruption of high integrity data by low integrity
sources, and cannot truly express higher level properties.

We ourselves have often noted that the current SELinux policy language
is an assembly language for policies.  This is natural, as one must
build up from the base control primitives in order to truly control what
is happening on the system.  It would be far better if people would
expend resources on building higher level tools and languages to make
SELinux more accessible without losing the soundness of its foundation
than re-inventing the wheel with yet another special purpose LSM, all
too likely to be built on a weak foundation.

SELinux _can_ protect the audit infrastructure now, and can do so
without necessarily applying fine-grained least privilege to the entire
system.

Perhaps this is the wrong venue for this discussion; if so, then I
apologize.  But I find it troubling that this group and discussion have
been ongoing for some time with no representation from SELinux AFAIK,
and I thought I should set the record straight on these issues.  Thanks
for listening...

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