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

["Santosh Chokhani" <SChokhani at cygnacom.com>]

Kurt,

Good point.

This capability should not impact SPIF.  The capability to read Vs.
assert should impact the clearance structure and the companion access
control decision function.

I view SPIF as performing the following functions: converting machine to
human representation and vice versa; establishing equivalency between
two labeling policies, and defining which labels with the lattice are
valid and which are invalid.

> -----Original Message-----
> From: Kurt Zeilenga [mailto:Kurt.Zeilenga at Isode.com] 
> Sent: Saturday, April 04, 2009 7:01 PM
> To: Santosh Chokhani
> Cc: Russ Housley; 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 Apr 4, 2009, at 3:46 PM, Santosh Chokhani wrote:
> > On the issue of authorization to "label" an object, I 
> assume you are 
> > not saying that write authorizations need to be separate from read 
> > authorization.
> 
> No, I am saying the lack of separate "to read"/"to label"  
> authorizations is a significant limitation of the SDN SPIF 
> model.  For instance, one might not require any particular 
> clearance to read UNCLASSIFIED//RELEASEABLE-TO-PUBLIC under a 
> particular policy, but under that policy one might be 
> required a specific clearance to create an object with a 
> UNCLASSIFIED//RELEASEABLE-TO-PUBLIC label.  (There are a 
> number of real world national/international policies that 
> have asymmetric "to read"/"to label" handling of security 
> labels.)  The SDN SPIF model, unfortunately, assumes that 
> authorization to read implies authorization to label, so one 
> cannot represent such a policy in a SPIF.
> 
> -- Kurt
>