[Security_sig] 10/14 Conf. call minutes

[Chris Wright]

* Stephen Smalley (sds at epoch.ncsc.mil) wrote:
> Gentlemen,

Hey, there are women in the group too ;-)

> 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.

You're very welcome to participate in this discussion and list.  Let me
give a bit of contextual background.  This group was originally created
to consolidate the OSDL Working Group security efforts existing in
CGL and DCL (and anticipated DTL) to a single group.  Historically,
these efforts were not well-coordinated, and did not always include
working group members that had a security focus.  Presently, this group
is working on CGL and DCL security requirements, with CGL fairly well
underway, and DCL under discussion.

This particular DCL discussion which you refer to is about asserting
a requirement for MAC.  MAC requirements have been in DCL yet poorly
justified.  The purpose of this disucssion is to show that the core tier
(specifically database, and perhaps app) servers aren't be adequately
protected by DAC.  While we (in this group) agree on that, we actually
found this had to be better justified.  The fact that many end-users are
now requiring auditing (above any MAC requirements) became a discussion
point for leveraging a MAC requirement to protect the integrity of the
audit subsystem.

> 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.

To be clear, it is certainly not the position of the group as a whole.
More to the point, however, this group is not about advocating any
particular solution.  In many cases, it's simply reflecting actual
customer feedback, which does include experiences using SELinux that
actually generates some of the pushback against a MAC requirement.

> 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.

This is one key issue, and it is a reality that people report finding
SELinux difficult to use.  I wouldn't go so far to say equivalence
classes are _required_ to enforce higher level security goals -- perhaps
it depends on definition of higher level.  However, I do agree that the
abstraction is needed for anything that's complex and general purpose
(i.e. securing a general purpose system w/out added abstraction is
asking for major holes, and no possible formal way to convince yourself
of policy closure).  However, that's moot, considering the question is
about justification of MAC requirement,

> 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.

It depends on your goals.  And competition is a good thing.  That being
said, I absolutely agree it's time well-spent to improve the adminstrative
simplicity of SELinux.  I doubt you'd find many disagreements there.

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

This has never been under question (at least in my mind).  I believe
targeted policy was mentioned as an example of simplifying the
administrative requirements for something like this.

> 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...

Thanks for your input.
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net