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