Subject: Re: SE Linux vs SE NetBSD !!
To: Travis H. <firstname.lastname@example.org>
From: Robert Watson <rwatson@FreeBSD.org>
Date: 08/26/2006 04:59:46
On Fri, 25 Aug 2006, Travis H. wrote:
>> 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.
Yes -- the targeted policy approach makes a lot more sense for such a diverse
system than the original reference policy approach.
>> > 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.
Biba is an integrity policy; the more common variation is the logical inverse
of MLS, and typical implementations share 90% of their code with MLS
(determination of flow direction). Instead of tracking confidentiality, it
tracks integrity, preventing information flow from lower integrity bits of the
system to higher integrity bits. I.e., the theory behind securelevel: mark
objects key to trustworthy startup as unmodifiable by untrustworthy parties.
However, it's done using run-time labeling, you can have trusted components
that do upgrades/downgrades, etc. It's used in a number of high assurance
systems to protect the TCB. It is less often used to protect user data, so is
typically configured once by the system provider. On FreeBSD, this is
implemented in the mac_biba module.
The less often seen variation is the floating label version, in which subjects
are "downgraded" when they touch lower integrity objects, such as packets from
untrusted network interfaces, etc. The theory behind this is that it requires
less configuration -- you mark your trusted "stuff" and things remain with
high integrity rights until they touch something less trusted. mac_lomac
implements this on FreeBSD, but is considered quite experimental. I believe
there's a recent Linux implementation by IBM; the older implementations done
by Tim Fraser at TIS were done on FreeBSd and Linux, and were published about
at USENIX, I think.
The ideas behind both policies are realy ones about the notion of integrity
and corruption, and underpin a lot of other work which often implements an
interpretation or application of the ideas, rather than the theory directly,
which is what the MAC policy implementations typically do. Biba
implementations usually suffer from many of the same limitations as MLS
implementations -- labeling requirements, etc. However, since they're usually
deployed only to protect the TCB, it tends to be a bit simpler since you often
end up simply labeling things as "system" or "not system".
>> 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.
A significant part of the problem here is that policy authorship is seen by
many software authors as independent of the development process; problems
occur when the software and the policy get out of sync (and are often hard to
debug) -- coupling the two parts more tightly would make it easier.
> 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
The targeted approach of constraining only specific applications is much more
reliable; however, does it remain the end goal? I am under the impression
that at least some in the SELinux community consider the targeted policy a
pragmatic fall-back from the "least privilege" goal, and therefore a stepping
stone on the way back there in the long term...
Robert N M Watson
University of Cambridge