Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Casey Schaufler <[e-mail]>]

Nicolas Williams wrote:
> On Wed, Apr 08, 2009 at 03:41:55PM -0700, Jarrett Lu wrote:
>   
>> It's not clear to me how much information is sufficient to guarantee a 
>> subset of policy is consistent so that labeled communication is safe and 
>> correct. One extreme is to require systems to be configured identically. 
>> As I understand it, roles/types on DTE systems usually depend on what 
>> kind of applications are run on the systems, and the types are defined 
>> to constrains what the applications can do on a system. In other words, 
>> policy on different systems are most likely different.
>>     
>
> Right, but presumably applications using NFS can be made to have
> identical sub-policies on all relevant NFS clients and servers.

I do not believe that you can make that assumption with SELinux.

> If not
> then why use NFS for such an application?  

That is a very good question.

> Of course, there's the matter
> of home directories and random apps loaded on clients without server
> knowledge, but if you're using labeled NFS then presumably you have an
> infrastructure and site-/org-wide system administration that can ensure
> orderly application deployment.
>
>   

That's quite an assumption.

>>> Jarret's point was that this is true even for MLS labels because a node
>>> might not know what the meaning of a given sensitivity and compartment
>>> are.  This is not a problem for CALIPSO because middle boxes need only
>>> determine label dominance, but Jarret thinks that this is a problem for
>>> NFS.
>>>  
>>>       
>> I believe this is a problem for MLS end systems (client and server), 
>> even when CALIPSO is in use. If labels are defined differently on 
>> different systems, e.g. same binary bit patten on two different systems 
>> maps to different labels, label comparison is meaningless. The 
>> underlying assumption is that if two systems use different label mapping 
>> schemes, they should not be using the same DOI to communicate without 
>> some sort of translation mechanism. The agreement of associating a DOI 
>> with a particular label mapping is done outside of a protocol option 
>> such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, 
>> CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label 
>> option for IPv6. It is not designed to communicate policy agreements 
>> among systems.
>>     
>
> Based on this I think I'm ready to conclude that for MLS we don't need
> anything more than the DOI number/name to produce MLS policy agreement,
> though a URI scheme for naming policies (including version) would have
> better semantics.  

MLS is an easier problem to solve, unfortunately it is a technology
that has fallen off the roadmap.

> DTE does not seem as simple, though assuming common
> per-app sub-policies then it may be doable.
>   

If you can create an uber-policy that can be shown to
incorporate all the aspects of both the client policy and
the server policy, one case of which being either the client
policy or the server policy being a sub-set of the other,
you may have a chance.

Each policy is a million lines.