On Sat, 26 Aug 2006, Elad Efrat wrote:
> Robert Watson wrote:
>
>> I'm not convinced that's a firm argument: LSM, like kauth(9), relies on
>> being implemented properly.  Like kauth(9), it has hooks all over the
>> place, must properly interact with kernel subsystems, and so on.
>
> Unlike kauth(9), LSM introduces a design flaw -- IMHO -- in the form of 
> stacking. Also, kauth(9) don't have hooks in the same sense that LSM does...

Yes, I have to agree that stacking is one of the things I like least about 
LSM.  Stacking does not appear in the design used in the MAC Framework on 
FreeBSD/Mac OS X--instead the framework includes a native composition 
mechanism for multiple simultaneous policies.  However, while it is arguably a 
design flaw, it's not a vulnerability per se.

> Here are some opinions about LSM from authors of 3rd-party security
> solutions for Linux:
>
> 	http://grsecurity.net/lsm.php
> 	http://rsbac.org/documentation/why_rsbac_does_not_use_lsm

I've always had great respect for the design of the RSBAC Framework (based on 
the GFAC architecture from Marshall, et al), and it is definitely influenced 
the MAC Framework design (especially after I had a chance to sit down with the 
author at USENIX a few years ago).

> Moreover, here's an interesting post that may shed some light on LSM and
> how widely used it is:
>
> 	http://lwn.net/Articles/138046/
>
> It is a wild guess, but I think the above can be attributed to its 
> complicated nature -- which repeats my question throughout this thread: do 
> we have consumers for such a framework? Linux's userbase is bigger and more 
> diverse than NetBSD's, can we expect someone to actually make use of such a 
> subsystem given no-one did in the Linux world?
>
> (the situation had changed since, and now Novell's AppArmor also uses LSM; 
> that, however, strengthens my opinion that such work should be done by a 
> contractor for a company who needs it, rather than by us.)

There are lots of potential (and real) consumers of LSM, but one of the more 
contentious aspects of the LSM design/implementation has been its strong 
SELinux focus.  This is in large part because much of the implementation was 
driven by the SELinux developers.  However, I think I do object to the idea 
that LSM is unused by developers of other kernel security mechanisms. 
There's highly active work on DTE using LSM, and also I believe the WireX 
product line (and possibly others) use LSM.

The weak semantics of LSM are a concern -- one of the chief desires in the MAC 
Framework design was providing not just hooks, but policy infrastructure -- 
composition, kernel labeling facilities, cross-policy APIs, and so on. 
Likewise, the semantics for the caller are of concern, especially with regard 
to locking/atomicity.  These are largely omitted from the LSM design, which 
Chris Wright has indicated to me he's interested in investigating on at least 
a couple of occasions.

Remember that part of the goal of LSM, kauth, the MAC Framework, RSBAC, and 
others hasn't been just to serve current security policy modules -- it's been 
to facilitate future R&D, product development, etc.  I think it's clear that 
the right solutions here have not yet been found, despite 30+ years of R&D. 
One of the first things I ran into when looking at bringing new security 
models to FreeBSD was that you end up doing a lot of work just to get started, 
even if the policy you want to work with is relatively simple.  Giving 
developers a starting point for doing policy development, so they don't have 
to build everything from scratch, is critical.

>> Are most users qualified to make fine-grained security decisions about how 
>> their applications operate?  Making something simple to configure doesn't 
>> make it easy to use.
>
> So we would provide defaults that fit most users, and when a deviation is 
> needed... we would force the user to either not use the policy altogether 
> and fall-back to what he knows from Good Old Unix? or would we force 
> everyone to learn a known-complex policy language? :)

This is pretty much what RedHat does -- if you are an end-user, you run with 
SELinux, or without it, and they provide a giant frob to allow you to decide. 
If you start heavily customizing the system, then you need to adapt the policy 
or disable SELinux.  This isn't much different from other security mechanisms 
-- firewalls, hardening extensions of various sorts, etc.

>> Security *is* complicated, because, at its core, it has to do with the 
>> complex interactions of complex systems.
>
> Call me naive, but I don't think so. Not only that for the most part I'm not 
> sure SELinux achieves something for the majority of computer users that 
> other security models don't, but I also think that the reasons behind its 
> design (confidentiality levels etc.) suggest that its designers were trying 
> to apply a technical solution to a non-technical problem.

I think we'll have to agree to disagree on the issues of whether security is a 
complex thing, and the intent of the designers of SELinux.  Whether SELinux 
meets the needs of a majority of users is something we'll only be able to 
determine in a few years once RedHat's grand experiment with shipping SELinux 
"out of the box" has had a bit more time to settle out.

Robert N M Watson
Computer Laboratory
University of Cambridge