On Sun, 2004-10-31 at 17:47, Frank Mayer wrote:
> > The MLS model is another reason for this functionality. We have
> > chosen to create MLS policy overrides using a new SELinux MLS
> > capability class.
>
> I have not thought greatly about this choice, but I wonder if it was wise to
> make the MLS mechanism dependent on the capability mechanism. Orthogonal
> mechanisms would seem smarter.

Point of clarification: These MLS capabilities only exist as TE abstractions, not as part of the Linux capabilities logic, IIUC. Using TE to control MLS privileges is desirable.

> Ah and here we have the beginning of the slippery slope. This might be easy in
> terms of lines of code, but the conceptual complexity of what you describe above
> scares me. I still wonder why we have to change TE to support a MLS convention.
> I'd much rather you did not make these mechanisms dependent on each other.

TE was originally developed to fill in the gaps of MLS, including privilege management for trusted subjects. Using TE to control MLS privileges is a good thing. Whether or not privilege bracketing is a good thing is more open to debate, although it is clearly entrenched in applications today, and not just MLS applications; the prior requests for such a feature have been to support traditional Unix applications that presently use seteuid/setfsuid.

Devil's advocate: Would you argue for removing the ability to reload policy at runtime from SELinux? For removing the ability to relabel files at runtime from SELinux? Or is it sufficient that these "unsafe" operations are controlled by the policy? The dynamic context transitions can be controlled on a pairwise context basis, so you do get much finer control than a traditional setuid-like operation.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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