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:

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

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.

(I have seen banks where it is required to both enter a password *and*
use a smart-card to login to the computer network. Employees ended up
leaving the smart-card in the reader 24/7 and you can guess where the
post-it with the password was. :)

> If NetBSD ever implements this, for heaven's sake, do NOT make up your
> own m4 macros or syntax without a good reason.  The documentation for
> SELinux is "good enough", but I _really_ don't want to have to
> memorize a whole new set of macros.  Understanding one is enough work.
> If you do implement new macros, try and develop some documentation
> that is better than Linux's... that may be impossible, but SELinux
> policy language documentation is a real snoozer as-is.

Perhaps that is intentional; I know several companies who make money off
of writing SELinux security policies. ;)

>> > What technical problem do these technologies solve?
> 
> Bell-LaPadula is useful for enforcing MLS.  I've forgotten what Biba
> addresses, another kind of MLS policy IIRC.

MLS (Multi-Level Security) is a rather vague (and big!) term. :)

> That's the problem definition, yes.  Simpler systems are easier to
> secure, but I like a good challenge. 

Like I said, this is hardly a question of whether SELinux (or
SEAnything) is just more complicated, but rather a collection of pros
and cons -- IMHO -- that ruled out this direction. I don't think the
effort associated with properly integrating it and making it accessible
to our entire userbase (which is something the Unix security model is)
is worth the benefits of such an architecture.

> The work here is to help
> security catch up with functionality.  Certainly to create a truly
> secure system, you have to limit its functionality and extensibility.
> The easiest system to secure is the unplugged one.  The challenge is
> in catching up with the functionality, which is going at breakneck
> speed in all directions.

Exactly. Perhaps better illustrating my point would be to ask: what
common security policy you can express using SELinux that you can't
with (due to implementation of) kauth(9)?

> BTW: Fedora Core does a good job of bundling policy modules with the
> applications; it is basically zero effort unless you need to do
> something non-standard.

Fedora Core also has much more man-power and resources, and can use
GPL'd code, which we (or FreeBSD, I hope!) can't. One of NetBSD's goals
is to be freely redistributable, and that will be impossible given
licensing issues for large parts required to implement SELinux.

To summarize, I would not object to having similar work as SELinux
done for NetBSD -- it can only do good for NetBSD, in the long-term.
However, given no proper justification so far, and the reasons outlined
above, I don't see such hypothetical work being integrated in NetBSD
itself.

That is, of course, my own opinion. :)

-e.

-- 
Elad Efrat