On 8/25/06, Robert Watson <rwatson@freebsd.org> wrote:
> > I haven't seen a single benefit of SELinux since
> > its incarnation. In fact, all I've seen are Linux kernel exploits that can
> > very easily disable it. :)

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.

However, just because it can be subverted due to kernel bugs isn't
reason to say it's worthless.  Everything can be subverted due to
kernel exploits, except maybe TC hardware, and that can be subverted
due to bugs in it.  Just because there were ways to break out of
chroot doesn't mean it's not a valuable tool either.

> Absolutely -- the man-power investment in SELinux is enourmous; I don't know
> if it's still the case, but at least at one point, RedHat had two full time
> employees just working on policy adaptation and integration; NSA also had
> several people working full-time during that.  The overhead of a port was not
> too bad, although quite time-consuming.  The biggest single task, if you have
> a MAC Framework already (which we did) is the user space policy adaptation.

It's actually not too bad if you already know m4 and understand
TE/DTE.  I've written policy modules for procmail/nmh.

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.

> But the problem with the whole underlying concept is that the the
> general-purpose OS and application environment is not actually what TE was
> designed and implemented for.  Where TE works really well is in a relatively
> fixed-configuration, high assurance system, such as a firewall, not a desktop.

Some people use BSD for firewalls and other appliances.  The SELinux
targeted policy is just right for desktops; protect network servers
and let the guy at the console do what he wants.  I am in the process
of developing a policy that's like targeted, but protects
cryptographic keys from programs that don't need access to them.

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

> the problem is instead the goal
> of creating a fine-grained policy for a very large and complex system.

That's the problem definition, yes.  Simpler systems are easier to
secure, but I like a good challenge.  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.

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.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484