Re: Are the reference policy abstractions the right ones?

[Joshua Brindle <method@manicmethod.com>]

Karl MacMillan wrote:
> On Tue, 2007-10-09 at 16:00 -0400, Karl MacMillan wrote:
>   
>> On Tue, 2007-10-09 at 15:44 -0400, James Carter wrote:
>>     
>>> On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:
>>>       
>> [...]
>>
>>     
>>>>>  but why would you use the attribute
>>>>> statement?
>>>>>
>>>>> wouldn't it be this?
>>>>>
>>>>> type domain
>>>>> type daemon, domain
>>>>> type network_server, daemon
>>>>>
>>>>>           
>>>> Maybe - if we remove the distinction entirely. The only reason I can
>>>> think to leave the attribute statement is to mark a type as "abstract" -
>>>> i.e., can't actually be a label on a real subject or object in the
>>>> running system.
>>>>
>>>>         
>>> There would be a few places where one might use an abstract type, domain
>>> being one of them, but I am not sure they would be needed.
>>>
>>> Your idea does seem to be simple, but it still won't handle the case
>>> where there is type mangling.
>>>
>>> if we have:
>>>
>>> type foo;
>>> allow foo foo_bar : file read;
>>> type baz, foo;
>>>
>>> Where foo_bar was created in some macro or interface.
>>>
>>> It seems like baz would have read permission on foo_bar, when probably
>>> we would like it to have read permission on baz_bar.
>>>
>>> All of which you know and previously mentioned a month ago:
>>> http://marc.info/?l=selinux&m=118961442411429&w=2
>>>
>>>       
>> Yeah - too bad I don't have an answer. We basically need a way to mark
>> groups of types as related and do self-like replacements. No good syntax
>> suggestions here.
>>
>>     
>
> Here's a suggestion (this assumes that hierarchy stops using dot in
> favor of explicit statements):
>
> type_group daemon {
> 	type process, domain;
> 	type exec, exec_file;
> 	type conf, file_type;
> 	type log, log_file;
> }
>
> allow daemon.process daemon.exec : file entrypoint;
> # etc., etc. for the exec permissions - could
> # even have a type_transition.
> allow daemon.process daemon.conf : file read;
> allow daemon.process daemon.log : file { read write };
>
> # Apache gets all of the types defined in daemon and
> # access to the apache versions - so apache.process
> # can read apache.conf.
> type_group apache, daemon {
> 	type html_files, file;
> }
>
> allow apache.process apache.html_files : file read;
>
> This handles the new set of types that is separate from the existing
> set. We could also make some of the groups "abstract" - so that
> daemon.process can't be applied to a process.
>
>   

Interesting, as we were talking about in IRC it might be an interesting 
idea to graphically export a 'reduce granularity' slider to make things 
very easy to reduce the strictness of a policy on a particular 
application (group of domains). With the dots if the hierarchy is still 
used you can just remove domains and file types at higher levels of 
granularity (more dots). I don't know, maybe a really bad idea but it 
seems like an interesting way to reduce the granularity of policy 
enforcement in an automated and easily accessible way.


> To handle the need for extension - Dan's java_t example. Assuming we
> have unconfined, wouldn't this work:
>
> type java_t, unconfined_t;
>
> allow java_t self : process execmem;
>   





--
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.