[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I am hoping that SPIF labeling in this community will either not be a
problem or if it is part of the labeling and MAC policy, SPIF is not the
only mechanism that is exacerbating it. 

> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] 
> Sent: Friday, April 03, 2009 12:52 PM
> To: Russ Housley
> Cc: Santosh Chokhani; saag at ietf.org; 
> labeled-nfs at linux-nfs.org; selinux at tycho.nsa.gov; 
> nfsv4 at ietf.org; nfs-discuss at opensolaris.org
> Subject: Re: [saag] Common labeled security (comment on 
> CALIPSO, labeled NFSv4)
> 
> On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote:
> > I really do not have time to write about all of my 
> concerns.  However, 
> > once you get beyond the basic classifications, the SPIF 
> model breaks.  
> > They are markings that are only to be known to people that have the 
> > clearance for those markings, this leads to a SPIF distribution 
> > nightmare, as a subset of the real SPIF must be given out based on 
> > access (or not) to various compartments and such.  It just does not 
> > scale.
> 
> I'm aware of the fact that labels can themselves be labeled.  
> But I don't think that implies that we can't make a SPIF-like 
> solution scale.
> 
> Peers that have access to different subsets of the policy 
> should still be able to interop if care is taken to specify 
> what happens when a node sees a label that falls outside its 
> policy subset, and provided, of course, that the peers can 
> agree that they have subsets of the *same* master policy.  
> Peers can check whether they do have subsets of the
> *same* master policy by exchanging [for each DOI to both] a 
> master policy URI that includes a version number.
> 
> Nico
> -- 
> 

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.