Research
Skip Research Menus
Research MenuSecurity 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: Wed, 03 Nov 2004 11:03:37 -0500
SELinux performs a number of checks on an exec-based context transition, including open file descriptors, controlling tty, signal-related state, and resource limits. Such checks have to be carefully balanced against application compatibility concerns (but policy can handle this on a selective basis) and against the potential for a security flaw to arise from unexpected state sanitization (e.g. you set resource limits prior to running some application to bound its resources, but it runs in a different domain and the policy forces a reset of its resource limits to protect it against subversion by the caller, thereby leading to it running with greater limits than desired - this too can be addressed by policy). Some state sanitization need to be handled by glibc (e.g. LD_* variable purging), and this is done via the AT_SECURE mechanism. Some state sanitization ultimately requires application knowledge and has to be done by the particular application during startup. We don't apply checking to every piece of state inherited on exec, as certain forms of manipulation should be countered by existing access checks (e.g. namespace manipulation already requires a capability to perform, and namespace manipulation may trick the application into accessing the wrong file, but it won't let the application access any file beyond its permissions) and since it isn't always clear what to do if a given piece of state couldn't be inherited (merely resetting to some sane default may introduce a vulnerability of its own, e.g. breaking out of a namespace set up by a caller). But no matter how "leaky" exec may be, it is far less "leaky" than seteuid, where you have no control over inheritance or initialization of the new domain. -- 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 Wed 3 Nov 2004 - 11:07:34 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |