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: [RFC & PATCH] inherited type definition.
From: Karl MacMillan <kmacmillan_at_tresys.com>
Date: Fri, 18 Mar 2005 17:28:57 -0500
Ok - I'll send you a patch.
> > I disagree - macros allow this. Also, what we want, I I am saying, that if almost all access - including, for example, the access between httpd and httpd_content_t - is expressed as a set of well-defined macros, then this becomes easy. That means that a policy author can look at the macros defining access between httpd and httpd_content_t and samba and samba_share_t and then reuse those to create samba_httpd_content_t. Also, the more I think about it the more convinced I am that the show-stopper limitation of the extends syntax is that it allows only one subset of access. The discussion so far has exposed that we don't usually want to grant all of the access to httpd_content_t and samba_share_t to samba_httpd_content_t, but the @ syntax allows us to form only one subset. What if we want to create ftp_httpd_content_t that has a different subset of the access to httpd_content_t than is useful for samba_httpd_content_t? What if we want to give httpd the kind of read access it has to httpd_content_t to foo_t and the kind of write access it has to httpd_content_t to bar_t? With the extends syntax we are limited to just one subset. The macros allow us to form arbitrary subsets of the access and it apply to other types at will.
> So you would actually have to define macros Yes - exactly. I think that this has far-reaching benefits beyond this one use case as well, including readability and documentation.
> Further, this wouldn't necessarily cover I think that this is a benefit - it makes the granting of access intentional and explicit.
> > I would like to see how some real world problems would be I agree, but I want to make certain that it is clear that I am not suggesting that the current use of macros is an appropriate alternative. Also, we have started a worked example of the macro abstraction that I am suggesting. Unfortunately, it is a time-consuming task, but we have committed significant resources to this as part of a larger effort to create a new security first policy. As soon as possible, I'll start posting examples of how this is progressing. My intuition says that this is the solution to a wide range of policy writing difficulties and I am eager to have it tested and vetted. Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134Received on Fri 18 Mar 2005 - 17:28:59 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |