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

["Santosh Chokhani" <[e-mail]>]

One of looking at what Russ is saying is:

1.  See if you can avoid security policy mapping, e.g., define a Common
Extensible labeling Policy.

2.  See if you can live without non-hierarchical security categories,
since their very introduction brings in complexity.

3.  See if you can live with only the hierarchical sensitivity levels
mapping and without categories mapping.  If the answer to 1 and 2 is no,
the answer to this is likely to be no also.

4.  See if you need to invalidate all the possible labels in the
lattice.

5.  Use the answers to 1 through 4 to tailor the SPIF.

6.  See if you can achieve the same functionality using simpler
paradigm.

> -----Original Message-----
> From: Casey Schaufler [mailto:[e-mail]] 
> Sent: Monday, April 06, 2009 11:04 PM
> To: Russ Housley
> Cc: Nicolas Williams; Santosh Chokhani; [e-mail]; 
> [e-mail]; Kurt Zeilenga; 
> [e-mail]; [e-mail]; Casey Schaufler
> Subject: Re: [Labeled-nfs] [saag] Common labeled security 
> (comment on CALIPSO, labeled NFSv4)
> 
> Russ Housley wrote:
> > ...
> >
> > No.  They are two separate concerns.
> >
> > Mapping labels between two different policies.  Hopefully 
> this can be 
> > avoided altogether in the NFS context.
> 
> I don't think so. Two SELinux machines will most likely have 
> different policies even if they installed from the same media 
> on similar hardware with similar configurations. If there's 
> any reason for the NFS server to know anything about the 
> client that impacts policy enforcement the server has to know 
> enough to make that judgment correctly. If the server can 
> ignore the client's policy there is no need to send any information.
> If the server can't ignore the client's policy it needs to be 
> able to reconcile the local policy to the remote policy in 
> order to enforce reasonable policy.
> 
> The problem is that the server is using client subject 
> information to enforce policy based on server object 
> information. If the policies are similar (e.g. two Bell & 
> LaPadula MLS systems) enforcement is merely difficult because 
> the two system may have different values for what means 
> "UNCLASSIFIED". For an SELinux system and an MLS system to 
> work you've got much more on your hands than matching up 
> category bits. If you don't do so however you can not make an 
> access control decision based on the information passed from 
> the other side that can possibly make sense.
> 
> You could decide that the server should enforce server policy 
> and require that the client enforce client policy and hope 
> that between the two nothing leaks out that you really care 
> about. I seriously doubt that's what you want.
> 
> So you're back to mapping policies. You have to map policies 
> if you want either side to do all the work. The mechanisms 
> used to map labels used by different installations of the 
> same 1990's MLS systems will not work for SELinux systems 
> installed for different purposes by disjoint agencies.
> 
> I'm not trying to stop progress here. I am simply trying to 
> point out that choosing a mechanism to implement a facility 
> that won't work in the end is pretty pointless. Sure the old 
> schemes worked in certain cases in the olden days. The 
> question is will they work now, and the answer is obviously "no".
> 
> 
>