Re: New stacker performance results

From: Chris Wright (chrisw@private)
Date: Thu May 26 2005 - 06:06:46 PDT

* James Morris (jmorris@private) wrote:
> On Wed, 25 May 2005, Tony Jones wrote:
> > But the LSM hooks aren't going to just dissapear. Under what you propose they 
> > will be replaced by other SELinux specific calls.  How does this change the 
> > impact to core/other kernel maintainers when they make changes? They are
> > still going to be faced with making changes near call points whose purpose
> > they may not be overly familiar with.
> That's a good point.  Yes, the SELinux specific calls would still be 
> there.
> The differences for cor maintainers would be:
> a) Clearer semantics, i.e. being able to trace the flow directly into the 
> SELinux code and be able to see exactly what's happening.

I don't agree at all.  If you can't follow a function pointer...
In fact, I don't even agree that that's the semantic issue.  I think the
semantic issue is with the loose mechanism that information is passed
from core to security module.  It errs on passing too much, and relies
on typeless data.  If anything, the problem is the layer is too thin.

So perhaps here's where our opinions converge.  Everybody wants to do
the same basic thing, control access between subject and object.  Other
core subsystems do much more to enforce semantic rules, lifetime rules,
typed interfaces, cache maintainance, etc. on behalf of the users of the
subsystem.  So, ideally what the access control module should see is only
the question we care about (does $subject get to take $action on $object).
Unfortunately, reality strikes when you want to have security model
specific ways to label $subject, interpret $action, and label $object).
SELinux has done a great job at make the access request generic through
the the avc.  So, while you say drop LSM and just use SELinux, I would
say push avc into's pretty simimlar in the end...  Problem is,
you still have to deal with calling out to modules that want to do their
own label management, have their own policy language, etc.  This is
where it starts to feel like you're just pushing the problem around.

> b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many,
> but not a large amount).

At any rate, neither of these (a, or b) are very strong reasoning for
removal.  I'll listen to real ideas on how to improve the semantics of
core interfacing with security module (and no, I don't mean function
pointers, I mean real interface semantics).

This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 06:42:01 PDT