On Fri, 25 Aug 2006, Elad Efrat wrote:

> Yes. This is something we were all aware of when we made the choice to go 
> with kauth(9). If Apple decided they want the MAC framework for a SEDarwin 
> it's their own business; 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. :)

I generally try not to express opinions on the topic :-).

> The work required to port SELinux is huge, and it is important that while 
> you mention that you did it for FreeBSD and Darwin, you also mention that 
> this was *sponsored* work for companies who needed it. There is a huge 
> difference here, and if one company or another would pay me [an unrealistic 
> amount of cash] I would happily do the same work for NetBSD. Because that 
> didn't happen, I had to objectively consider various frameworks and I think 
> we made the right choice.

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

> Of course, only time will tell...

Indeed.

>> One of the critical differences between securelevel and the Biba integrity 
>> policy (present in a number of trusted systems, including TRIX, the Argus 
>> Pitbull extensions to TSol, etc), is that it allows run-time modification 
>> and self-reinforcement of the TCB, whereas securelevels basically prohibit 
>> that. Securelevels themselves are not an integrity policy as much as an 
>> integrity mechanism, that if applied consistently and diligently, can 
>> provide integrity protection.  Doing this correctly and thoroughly is quite 
>> difficult, and results in significant compromises in usability. That isn't 
>> an argument for deploying Biba instead of securelevels in many 
>> environments, as a systemic integrity policy also comes with compromises in 
>> usability, but if you're looking for higher assurance protection of the TCB 
>> while maintaining the ability to perform run-time reconfiguration of the 
>> TCB, you need something along those lines.  SELinux encodes many of the 
>> integrity ideas from the Biba model into its sample configuration, but not 
>> explicitly in the policy engine, which offers more flexibility, but greater 
>> risk.  Whether SELinux, Biba, or any other security solution is the right 
>> solution for a technical problem, of couse, depends entirely on the nature 
>> of the technical problem.
>
> What technical problem do these technologies solve?

The best example of the application of Type Enforcement (TE) is an assured 
pipeline in a guard, which is how SCC and other companies that deploy TE use 
it in practice.  The configuration is typically fairly simple: filters are 
stacked up in a pipeline consisting of a series of isolated sandboxes, each 
only having permission to talk to the next stage, with the two endpoints 
having permission to operate on network interfaces.  There are relatively few 
domains, types, and rules -- maybe a dozen or so per pipeline, authorizing IPC 
between the components, perhaps some storage space, and communications for the 
endpoints -- certainly not 40,000 rules.  Each stage in the pipeline performs 
sections of the security function -- a first stage might be a protocol 
normalization stage, the next might filter for malicious code, the next might 
be a caching layer, a declassification stage, etc.  The layers protect each 
other; compromise of one layer doesn't necessarily result in immediate bypass 
of the guard or access to the system as a whole.  The result is a high 
assurance firewall.

The "problem" with SELinux is not the underlying technology, which is really 
just a set of fairly efficient rules (with a slightly dubious syntax) granting 
privileges to flexibly assigned identities -- the problem is instead the goal 
of creating a fine-grained policy for a very large and complex system.

Robert N M Watson
Computer Laboratory
University of Cambridge