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

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Sat, 04 April 2009 22:59 UTC

Return-Path: <Kurt.Zeilenga@Isode.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 79D713A6903; Sat, 4 Apr 2009 15:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.984
X-Spam-Level:
X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599]
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 CaTHAPXIRgHA; Sat, 4 Apr 2009 15:59:38 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A81D33A6891; Sat, 4 Apr 2009 15:59:38 -0700 (PDT)
Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <SdfmlgAs9LHX@rufus.isode.com>; Sun, 5 Apr 2009 00:00:41 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-Id: <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com>
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
To: Santosh Chokhani <SChokhani@cygnacom.com>
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE0@scygexch1.cygnacom.com>
Date: Sat, 4 Apr 2009 16:00:36 -0700
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>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
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: Sat, 04 Apr 2009 22:59:39 -0000

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