Subject: Re: SE Linux vs SE NetBSD !!
To: Elad Efrat <elad@NetBSD.org>
From: Robert Watson <rwatson@FreeBSD.org>
Date: 08/25/2006 15:17:20
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...
>> 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
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
University of Cambridge