Subject: Re: SE Linux vs SE NetBSD !!
To: Elad Efrat <elad@NetBSD.org>
From: Robert Watson <rwatson@FreeBSD.org>
Date: 08/26/2006 05:10:43
On Fri, 25 Aug 2006, Elad Efrat wrote:
> Travis H. wrote:
>> If you have any URLs handy, I'd like to see them. OTOH, I can google
>> and if you don't have any handy will do so. Thanks for the reference.
> Nope, none at hand, but the design of LSM, on top of which SELinux is
> implemented, should give you a rough idea of one attack vector. Either way,
> let's not make *that* the center of our discussion; see below:
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. There's certainly more
to LSM, in that like the MAC Framework it supports control of a broader set of
system behaviors, security labeling, and so on, but most of the other
differences are gloss -- do you have lots of function pointers, or lots of
enumerated constants. kauth(9) was designed and implemented with full
awareness of the MAC-related work on various platforms, and intentionally
provides a limited subset of that behavior in ordeer to provide a narrower set
of functionality with a fixed ABI for third party security providers.
>> It's actually not too bad if you already know m4 and understand TE/DTE.
>> I've written policy modules for procmail/nmh.
> A rough assumption would be that 99% of NetBSD's userbase does not know m4
> *and* understands TE/DTE enough to create their own policies; nor they
> should. Part of what I'm interested in, beyond implementing yet another
> security architecture, is making it also as easy as possible to use.
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.
> If we provide a framework that is complicated to understand, configure, use,
> and debug, people will simply not use it, or use it "blind-folded". I think
> providing strong *and* usable security is a more interesting goal than
> supporting a security architecture that it is still unclear whether the
> majority of our userbase will benefit from.
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.
Not that I don't agree in general with your argument, but I think sweeping
statements about "ease of use" need to be avoided. Security *is* complicated,
because, at its core, it has to do with the complex interactions of complex
systems. You may not implement Biba as an abstract policy, but the ideas
behind it are behind the notion of protecting a system: how do you limit the
effects of compromise to subsets of the system, and what does compromise mean?
Providing a simple menu of hardening options is extremely useful, but somehow
those hardening options do have to be crafted with all the domain knowledge of
the implementation of the system, since that knowledge is key to protection of
the system. kauth(9) doesn't remove that requirement -- it's a vehicle for
people with domain knowledge to provide tools to people without domain
knowledge. Theframework is less complex, and less capable, but the underlying
idea is the same.
Robert N M Watson
University of Cambridge