Robert Watson wrote:

> As an FYI, the kauth(9) framework, while quite useful in doing a wide
> variety of things relating to the basic BSD security model, including
> the privilege model, would require significant extension in order to be
> able to support mandatory access control.  This is why it was necessary
> to port the MAC Framework from FreeBSD to Mac OS X in order to get the
> FLASK/TE implementation from SELinux built as a module (SEDarwin), even
> though kauth(9) is present in more recent Mac OS X versions. 
> Introducing more sophisticated security models into operating systems
> (FreeBSD, Mac OS X, Linux, etc) generally requires a more capable
> extension framework, as the goals of the kauth(9) work at Apple were
> fairly constrained: to support their ACL implementation, and to support
> third party anti-virus/firewall vendors, which it quite well.

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

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.

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?

-e.

-- 
Elad Efrat