Re: pam_namespace

[Janak Desai <janak@us.ibm.com>]

Russell Coker wrote:

>On Tuesday 09 May 2006 22:57, Russell Coker <russell@coker.com.au> wrote:
>  
>
>>>>Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to
>>>>have "user" and "context" as separate items to replace "both" and then
>>>>support a fourth option as "range", "high" or "low".
>>>>        
>>>>
>>>I am not sure I understand. We have "user", "context" and "both", where
>>>type in the context can be controlled through type-member policy rules
>>>and the mls range is inherited from the process. Can you give an example
>>>of what context the instance would have with "range" or "high" or "low"?
>>>      
>>>
>>My idea is that the range, high, and low values would be candidates for the
>>file name.
>>    
>>
>[...]
>  
>
>>Probably the easiest thing to do is to default to including the entire
>>security context of the process in the directory name.
>>    
>>
>
>One thing that I consider to be necessary is to allow the administrator to 
>determine in which situations the PI directories should be shared.  Using a 
>default that has the full context including range will work, but many admins 
>will want finer grained control.
>
>For example if the aim is to separate MLS ranges such that file names can not 
>be used to accidentally reveal secret data then there may not be a need for 
>separate Unix UIDs to have different directories, and directory names could 
>be based on range alone.
>
>Another possibility is when running the strict policy a user might have 
>multiple roles but not want to have a different copy of /tmp for each one.  
>For example if I scp a file to the /tmp directory used for role A then after 
>running newrole to change to role B I will still want to see the file in 
>question (assuming of course that the policy allows access to it).
>
>Then for MCS the issue of whether it's most desirable to base instance 
>directory names on the high or the low level is something that we probably 
>won't ever get an agreement on.
>
>  
>
Just to clarify, it is the instance security context that is important 
from the
perspective of access to it. The inclusion of context in the directory 
name is
just so that the admin can correctly identify them. The earlier incarnation
of the pam namespace module put an md5 hash instead of the more useful
uid+context names.

As far as the ability to control which instances to share, I assume you
can do that with the policy. The namespace module just calls
security_compute_member() to get the context of the instance.
security_compute_member() looks at process context and the
target directory context to arrive at the context for the member(instance).
So you could setup the policy such that different process contexts
return different (or the same, if so desired) contexts for the instance.

-Janak



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