Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified MandatoryAccess Control Kernel

[Stephen Smalley]

On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> --- "Serge E. Hallyn" <serge@xxxxxxxxxx> wrote:
> 
> > Quoting Casey Schaufler (casey@xxxxxxxxxxxxxxxx):
> > > ...
> > > Good suggestion. In fact, that is exactly how I approached my
> > > first two attempts at the problem. What you get if you take that
> > > route is an imposing infrastructure that has virually nothing
> > > to do and that adds no value to the solution. Programming to the
> > > LSM interface, on the other hand, allowed me to drastically reduce
> > > the size and complexity of the implementation.
> > 
> > (tongue-in-cheek)
> > 
> > No no, everyone knows you don't build simpler things on top of more
> > complicated ones, you go the other way around.  So what he was
> > suggesting was that selinux be re-written on top of smack.
> > 
> > :)
> 
> I'm not sure how seriously anyone ought to take what I'm about to
> outline. Please feel free to treat it with as much or as little
> reverence as you choose.
> 
> How to implement SELinux starting from Smack.
> 
> You'll need to break up the current rwxa accesses into a set
> that matches the current SELinux set. Assign each a letter and
> a "MAY_ACTION" #define.
> 
> You'll need a mapping for domain transitions, something like:
> 
>      subject-label program-label new-subject-label
> 
> This will require bprm hooks that aren't there now.
> 
> Additional hooks will need to be filled out as Smack does not
> add access control to things that aren't objects or actions that
> aren't accesses. Treat these as if they are accesses to objects
> and there shouldn't be too much trouble.
> 
> Do something about the linear search for subject/object label pairs.
> With the larger label set searching will become an issue.
> 
> Audit integration, too. The networking code will require some work
> for ipsec. The interfaces are pretty clean, Smack isn't using it
> because the CIPSO interface is simpler, not because there's any
> real problem with it.
> 
> I wouldn't expect the whole thing to be more than a couple week's
> work for someone who really wanted to do it.

Note that Serge said "SELinux re-written on top of Smack", not "rewrite
Smack to be more like SELinux".  I don't believe the former is even
possible, given that Smack is strictly less expressive and granular by
design.  Rewriting Smack to be more like SELinux should be possible, but
seems like more work than emulating Smack on SELinux via policy, and to
what end?

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/