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 List
subject: Re: [RFC & PATCH] inherited type definition. Date: Wed, 6 Apr 2005 22:49:11 +1000
This is an example of how not to do it. Many domains need search access to /var. Most of them should not be granted any access to /var/log, but your example would have them granted search access to /var/log as var_log_t inherits from var_t. Many domains access /var/log (probably more than we desire but that's a separate issue - the fact that user_ssh_t is granted read access to files of type var_log_t seems like a policy bug to me). /var/log/message may have data that is more secret than the other files/directories labeled as var_log_t, and we don't want user_ssh_t to read it.
On Wednesday 16 March 2005 15:42, Kaigai Kohei <kaigai@ak.jp.nec.com> wrote:
To address this you could have user_t inherit from a virtual base type user_base_t which doesn't have ptrace access.
> I have an idea that ALLOW statement is added an new option I don't like that idea. Tracking when the '@' symbol should be used will be beyond the skill of most people who write policy. Then there is the issue of someone writing a domain with the idea that it will never be used for inheritance but then having it used for inheritance later. If the inherited domain has it's policy in the public repository then things can get fixed, but if someone inherits a domain for their own private use then they could get surprised by a policy update that grants some access they didn't expect because the upstream policy developers didn't plan for inheritance and didn't use the '@' symbol. Your message on the 23rd of March seems to be OK in terms of access, but I doubt that the '@' operator will result in good policy. About a year ago I was involved in some discussions about these issues, and one of the major factors was how to deal with user_t/user_r/user_ssh_t and other_t/other_r/other_ssh_t type inheritance. One of the NSA guys asked me to write up a proposal for how to do this. After thinking about it for a year I haven't devised a good answer. If your work can result in a solution to this problem then I'm sure that everyone will be willing to accept some trade-offs. But currently I am not convinced that the benefits outweigh the costs of this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: KaiGai Kohei <kaigai_at_kaigai.gr.jp> subject: Re: [RFC & PATCH] inherited type definition. Date: Wed, 06 Apr 2005 23:50:45 +0900
Russell Coker wrote:
Yes, you are right.
>>I have an idea that ALLOW statement is added an new option I think that the required skill for tracking the security policy with inherited type is same as one for the security policy writen with attributes. Tracking difficulty will not change between the legacy statement and new one. But I understand your concern about an inherited domain. My original idea was started from 'inherited domain', but I noticed the worth of 'unified type' via this discussion. This statement can't ban an 'inherited domain', but it will not be significant requirement for using '@' prefix for any domain in upstream policy. It's more importantly that the permissions of Apache/Samba/FTPd/etc... to its contents files/directories will be granted with '@' prefix for extensiton on end-user configuration.
> Your message on the 23rd of March seems to be OK in terms of access, but I I think that '@' prefix and inheritable type can reduce the amount of description and redundancy. Indeed, it's not resolve all of the difficulty for policy description.
> About a year ago I was involved in some discussions about these issues, and Does the example of user_t/user_r/user_ssh_t mean 'inherited domain'? It has not been a significant issue yet, I think. I think it's enough benefit to create a new type which can be accessed from multi domains. (e.g Apache & FTPd shared directory) Thanks, -- DO NOTHING IS THE WORST POLICY. KaiGai Kohei <kaigai@kaigai.gr.jp> -- 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: [RFC & PATCH] inherited type definition. Date: Thu, 7 Apr 2005 01:30:44 +1000
When inspecting policy to determine it's operation you can see a list of attributes on a type declaration and know that each applies to the type. With inheritance as you describe you have exclusion rules such that you don't necessarily know that domain user_foo_t can access bar_t just because user_t can access bar_t and user_foo_t inherits. If we want to make a change to the inheritance it doesn't change the access granted to just one domain or type but instead it operates on an unknown number of domains/types.
> > About a year ago I was involved in some discussions about these issues, It does mean inherited domain. I want to write policy such that someone can load a binary policy module for a new user role professor_r which then automatically creates the domain professor_foo_t because the base policy has appropriate statements that are equivalent in functionality to the macros we currently use in macros/programs for such things. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: Jim McCullough <jim.mccullough_at_gmail.com> subject: Re: [RFC & PATCH] inherited type definition. Date: Wed, 6 Apr 2005 14:23:19 -0400
Just a thought on future planning. I personally prefer a separate log for any application that accesses /var/log for writing purposes. IE. sshd has /var/log/sshd, while ftp has /var/log/ftpd/, and so forth. Under a server that handles multiple domains, it makes life much easier to maintain the log files for tracking user loads by the individual client. -- Jim McCullough On Apr 6, 2005 11:30 AM, Russell Coker <russell@coker.com.au> wrote:From: Kaigai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [RFC & PATCH] inherited type definition. Date: Thu, 07 Apr 2005 11:16:31 +0900
>>I think that the required skill for tracking the security policy with
Is it same as attributes work ?
When a type is declared with attribute, we have to check this. When a type is declared with parent type, we have to check this. Both are essentially same, I think.
> If we want to make a change to the inheritance it doesn't change the access Sorry, what does mean 'make a change to the inheritance' ? If it means that changing the permission attached to parent-type make effects to some child-types, 'unknown number of domains/types' is over expression. A permission granted via parent-type is limited to child-types explicitly declared as an inherited type. If it means that changing the relationship between parent and child make effects to some child-types, it is fact that we have to grant all necessary permissions to child-types from scrach. But I think it's redundant and needlessness. This situation is similar trying to declare a new file-type without file_type attributes.
>>Does the example of user_t/user_r/user_ssh_t mean 'inherited domain'? Generally, any methods have strong and weak point. I have no intention to disallow the availability of existing macros. Each methods should be used for own strong point. Thanks, -- Linux Promotion Center, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> -- 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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: [RFC & PATCH] inherited type definition. Date: Wed, 6 Apr 2005 18:55:57 +0100
> But I understand your concern about an inherited domain. that's the reason why i suggested the inheritable(...) { } syntax. l. -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |