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: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
From: Stephen Smalley <sds_at_tycho.nsa.gov>
Date: Thu, 13 Dec 2007 11:23:53 -0500
They would correspond with the operations provided by the /dev/cachefiles interface, at the granularity you want to support distinctions to be made. Could just be a single 'setcontext' permission if that is all you want to control distinctly, or could be a permission per operation.
> Can an object of this class 'operate' on In this case, I wouldn't expect a cachefiles object to act on anything else. Some objects are also used as subjects, especially in the networking arena.
> How does an object of this class acquire a label? What is an object of this I was thinking the latter since the only goal was to control what contexts could be set by a given task, but you could support per-cache "objects" with their own labels (in which case the label would likely be determined from the creating task). If the latter, you don't really need a label for the object, and can just use the supplied context/secid as the object of the permission check, ala: rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES, CACHEFILES__SETCONTEXT); If the former, then you'd need more than one check, as you then have to check whether the task can act on the cache in question, and then check whether it can set the context for that cache to the specified value. -- Stephen Smalley 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 Thu 13 Dec 2007 - 11:24:09 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |