> The DoD and associated communities have long requested and utilized
> the privilege bracketing technique for information sharing solutions.
> Thus the majority of existing applications are built to this
> framework. TCS and other ISVs have a large existing code base of
> fielded accredited solutions based on this framework.

To be fair, privilege bracketing came about primarily as a compromise of how to meet the B2 requirements. The ideal was something like ring brackets from the Multics hardware, or even the simplified execution privilege levels from x86 architecture. I'm sure that on of the first places privilege bracketing argument was used was the B2 Trusted XENIX project, where we stretched greatly the B2 requirements of least privilege and separation of security relevant code, and successfully used the concept of privilege bracketing as en evaluation strategy.

So I'll admit my culpability in weakening the B2 requirements, but that does not mean privilege bracketing is a good idea just because we used it in the pass as a means to expedite evaluations. Rings and x86 privilege levels are truly separate, distinct security domains. Privilege bracketing is not (all software in the process will typically have complete control over what privileges it desires to use). Unfortunately, like Trusted XENIX (and any Unix), the only really distinct execution domains we have are processes, which has much greater overhead cost for switching than rings.

So if we were honest, the real reason we want to change security content is for performance reasons, not security assurance reason.

Frank

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.