On Thu, 24 Aug 2006, Travis H. wrote:

>> Note that the kernel side of things is only one part of it.  You still 
>> would need to write a security policy for NetBSD (or adapt the existing 
>> Linux one) in the SELinux policy language which is no small feat.
>
> I'd like to see MAC ported to NetBSD, but in the meantime it appears that 
> Elad is diligently working on a more granular securelevel and integration 
> with kauth, which accomplishes much of the same thing; IIUC basically 
> securelevel is designed to prevent persistent changes to the critical files 
> that control initial boot, so that a reboot can get you into a trusted 
> state.

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.

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.

(now back to your regularly scheduled, non-mandatory access control, 
programme)

Robert N M Watson
Computer Laboratory
University of Cambridge