Recently, Glenn Faden of Sun posted a comparison of SELinux and Solaris Trusted Extensions from an MLS point of view.
Karl MacMillan has now published a response, starting with a discussion of classic “trusted operating systems” and their manifest inadequacies. Then, he outlines the role of SELinux in providing a more general and flexible approach to security in mainstream OSs, meeting a wider range of requirements in a more comprehensive manner, and to do this not as a stale fork of an OS, but as a first class component, available by default. Karl also addresses some of the pervasive technical errors in the Sun article, which need rebuttal, even though they sidetrack more essential issues.
On trusted systems:
The worst of it, though, is that these systems were only useful for a small set of customers. Namely, government customers that maintain classified data (you know, “Top Secret”, “Secret”, etc.). The systems weren’t super secure versions of their general purpose counterparts as many people mistakenly assume. Instead, they were only secure in terms of a very narrow set of requirements.
Indeed, these old MLS models are full of problems, although generally mitigated with subsequent band-aids, people may be surprised to know, for example, that one of the foundational MLS policies, BLP, provides no integrity at all and can be trivially subverted.
Frederick Cohen, in his now fascinatingly dated A Short Course on Computer Viruses describes with great simplicity a virus which would allow the least trusted user on a BLP system to infect software run by the most trusted user. This was not exploiting an implementation flaw; merely an inherent limitation of the narrowly focused security policy. Another feature of classic MLS or trusted systems is that a trusted application can be defined as one that violates the security policy. That is, the policy is so inflexible that you must break it with a privileged application to make the system work.
This is not to get into a critique of MLS, but to highlight the role of SELinux in providing a flexible security framework with integrity built in from the ground up, and that thinking in these areas has advanced significantly since the 1970s and 1980s.
There are still some cases where MLS is indicated, particularly where there are very large numbers of distinct compartments, and for these cases, SELinux provides an integrated MLS capability. Typically, however, users who claim to need MLS quite often don’t—it’s all they’ve ever known—and they’re better off with a more flexible security policy which meets their specific requirements and does not need to be subverted by trusted applications to work.
Framing a comparison of SELinux and Solaris Trusted Extensions in terms of how each meets classic MLS requirements ignores the essential issue of SELinux as a fundamental paradigm shift in security. With SELinux, mandatory access control is available for virtually any class of user.
The case for generalized MAC is compelling, and I would invite the OpenSolaris project to consider integrating the Flask model (of which SELinux is an implementation) into their OS.
The SE-BSD and SE-Darwin efforts prove that SELinux components can be integrated into other OSs (where licensing allows), or otherwise re-implemented. I believe this would further improve and refine the technology due to greater diversity of implementations, with the potential to standardize flexible mandatory access control, similarly to the rough consensus of DAC. We’d then have greater interoperability and normalization of strong security mechanisms, which would be greatly beneficial to general users and thus computer security in general.