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

"Santosh Chokhani" <SChokhani@cygnacom.com> Mon, 06 April 2009 11:02 UTC

Return-Path: <SChokhani@cygnacom.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D428728C12A for <saag@core3.amsl.com>; Mon, 6 Apr 2009 04:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level:
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SMbw86n7PW2 for <saag@core3.amsl.com>; Mon, 6 Apr 2009 04:02:29 -0700 (PDT)
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id F05B828C126 for <saag@ietf.org>; Mon, 6 Apr 2009 04:02:28 -0700 (PDT)
Received: (qmail 12373 invoked from network); 6 Apr 2009 11:02:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Apr 2009 11:02:24 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 6 Apr 2009 07:03:32 -0400
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE9@scygexch1.cygnacom.com>
In-Reply-To: <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
Thread-Index: Acm1eS9jLv/W1lPHShC3bzOQCp9dFABLaj8Q
References: <20090402154402.GM1500@Sun.COM> <FAD1CF17F2A45B43ADE04E140BA83D48A9FF82@scygexch1.cygnacom.com> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE0@scygexch1.cygnacom.com> <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com>
From: "Santosh Chokhani" <SChokhani@cygnacom.com>
To: "Kurt Zeilenga" <Kurt.Zeilenga@Isode.com>
Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org
Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2009 11:02:29 -0000

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@Isode.com] 
> Sent: Saturday, April 04, 2009 7:01 PM
> To: Santosh Chokhani
> Cc: Russ Housley; saag@ietf.org; labeled-nfs@linux-nfs.org; 
> selinux@tycho.nsa.gov; nfsv4@ietf.org; nfs-discuss@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
>