Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4)
Nicolas Williams <Nicolas.Williams@sun.com> Wed, 08 April 2009 05:56 UTC
Return-Path: <Nicolas.Williams@sun.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 9FD573A6AD0; Tue, 7 Apr 2009 22:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Level:
X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 ZtFvP6YOU-Qn; Tue, 7 Apr 2009 22:56:12 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id E8F953A6A9B; Tue, 7 Apr 2009 22:56:11 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n385vI7n029537; Wed, 8 Apr 2009 05:57:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n385vIdf051880; Tue, 7 Apr 2009 23:57:18 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n385HmvC006318; Wed, 8 Apr 2009 00:17:48 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n385HjeS006317; Wed, 8 Apr 2009 00:17:45 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 08 Apr 2009 00:17:45 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <20090408051745.GG1500@Sun.COM>
References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE0@scygexch1.cygnacom.com> <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE9@scygexch1.cygnacom.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <49DC13DA.10405@schaufler-ca.com>
User-Agent: Mutt/1.5.7i
Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani <SChokhani@cygnacom.com>
Subject: Re: [saag] [Labeled-nfs] 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: Wed, 08 Apr 2009 05:56:13 -0000
On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > Wow. > > Before I go too far, how familiar are you with MLS, SELinux, or Smack? I'm familiar with Solaris TX (which is MLS). I'm also familiar with the OpenSolaris community that is trying to extend the TX model to include DTE. I don't know much at all about SELinux or Smack. I think common security policies for MLS are within reach. DTE... not so much. Some subsets of specific DTE policies, probably on a per-application basis, should be. > All three provide general security policy models (Opinions vary on MLS) > but none would lend themselves as a "generic" model. MLS is strictly > oriented toward sensitivity, SELinux depends on the programs installed > on the machine, and Smack uses no syntax in its labels at all. An > interoperable encoding of policies might be possible for very limited > policies. I suggest that mapping any other policy to the SELinux > reference policy is beyond the state of the art, and I welcome an > informed argument that proves me wrong. Two peers negotiating a IIUC it should be possible to generate SELinux policies from generic ones, but not the reverse. If so then that provides a path to interoperable deployment, though it would mean sacrificing some flexibility. Can you clarify my understanding? > policy subset? How does that help? Regarding the notion that the issue > of label equivalences is "least critical", I don't see how you can > claim to have successfully addressed any of the other bullet items > without it. Why send data at some label to a peer who doesn't understand what that label is? As for label equivalencies I was referring to the example cited earlier of multiple agencies with different MLS policies needing to communicate. To clarify: by "less critical" I meant that we could solve the equivalency problem later (provided we don't paint ourselves into any corners). > You're busy stocking the nursery and you haven't kissed the girl yet. Thanks. > If the information from the client is meaningless to the server the > server can not use it to make an access control decision. Same goes > the other way. With Smack I can assert that the label space for the Therein lies the interop problem. Will SELinux and Solaris TX interop with the labeled NFSv4 protocol we're working on? Evidently: not w/o policy agreement (that was Jarret's point, which kick-started this thread on the NFSv4 WG list). > client and server are the same and that it's OK if they use the labels > passed around even if their rule sets differ. I know a good number of > people who would find such an assertion dangerous, maybe even > criminal. Label representations are meaningless without the policy So you're saying that a) "a good number of people" think a solution is needed that allows the client and server to each know with certainty that the other will understand their labels, b) you're among those people (?), but c) no solution is feasible. Correct? So close up shop, forget interop? Or did I misunderstand you? What is the message that you're imparting here? I get the impression that it's "you can't solve this problem" and "I know what I'm doing" (and "you don't") but you're not telling us what it is that is. Is what you really mean "forget labeled protocol interop"? Please clarify. > behind them and mapping policies is hard enough that you could probably > get a PHD from a reputable institution by measuring just how hard it > is. I'm not interested in a PhD. I'm interested in solutions. SPIF is evidence that it's been tried. But I know little about how successful SPIF has been. Nico --
- [saag] Common labeled security (comment on CALIPS… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Shawn Campbell
- Re: [saag] Common labeled security (comment on CA… Russ Housley
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Kurt Zeilenga
- Re: [saag] Common labeled security (comment on CA… Russ Housley
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Kurt Zeilenga
- Re: [saag] Common labeled security (comment on CA… Sean Turner
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Santosh Chokhani
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] Common labeled security (comment on CA… Russ Housley
- Re: [saag] Common labeled security (comment on CA… Nicolas Williams
- Re: [saag] [Labeled-nfs] Common labeled security … Santosh Chokhani
- Re: [saag] [Labeled-nfs] Common labeled security … Nicolas Williams
- Re: [saag] [Labeled-nfs] Common labeled security … Casey Schaufler
- Re: [saag] [Labeled-nfs] Common labeled security … Casey Schaufler
- Re: [saag] [Labeled-nfs] Common labeled security … Nicolas Williams
- Re: [saag] [nfsv4] [Labeled-nfs] Common labeled s… James Morris
- Re: [saag] [Labeled-nfs] Common labeled security … Santosh Chokhani
- Re: [saag] [Labeled-nfs] Common labeled security … Casey Schaufler
- Re: [saag] [nfsv4] [Labeled-nfs] Common labeled s… Nicolas Williams
- Re: [saag] [Labeled-nfs] Common labeled security … Santosh Chokhani
- Re: [saag] [Labeled-nfs] Common labeled security … Nicolas Williams
- Re: [saag] [Labeled-nfs] Common labeled security … Jarrett Lu
- Re: [saag] [Labeled-nfs] Common labeled security … James Morris
- Re: [saag] [Labeled-nfs] Common labeled security … Nicolas Williams
- Re: [saag] [Labeled-nfs] Common labeled security … Casey Schaufler