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

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

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

But let's not focus this discussion on LSM itself. :)

> I'm not sure that the criticism you're making is entirely fair: perhaps
> 99% of the user base also doesn't program in C or speak BSD make. 
> SELinux's "configurability" is a bit like the "reprogrammability" of
> open source UNIX -- you need a compiler and serious domain knowledge to
> get anywhere.  As such, it is largely being targeted at satisfying
> integrity requirements associated with applications and software
> configurations.

True, to some extent. At the moment we provide the Unix security model,
where -- or so I'd like to believe -- all of our users know how to use
it to form basic access control. If we were to introduce a new
model, especially one that *may* require user configuration, I would
not want to create a dependency on knowing a complicated policy
language.

So, yes, at some point we would have to introduce a policy language
more complicated than what we have today; but like I said several times
in this thread, I am not convinced that SELinux justifies it.

> 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? :)

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

-e.

-- 
Elad Efrat