Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRE: dynamic context transitions
From: Stephen Smalley <sds_at_epoch.ncsc.mil>
Date: Mon, 01 Nov 2004 08:37:16 -0500
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 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.Received on Mon 1 Nov 2004 - 08:41:03 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |