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

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
Computer Laboratory
University of Cambridge