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

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 07 April 2009 17:22 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 40FC83A6929; Tue, 7 Apr 2009 10:22:51 -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 St3tpdHQVnRT; Tue, 7 Apr 2009 10:22:50 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 17C913A67A6; Tue, 7 Apr 2009 10:22:50 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n37HNtdi009520; Tue, 7 Apr 2009 17:23:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n37HNtT0001428; Tue, 7 Apr 2009 11:23:55 -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 n37GiMiP005932; Tue, 7 Apr 2009 11:44:22 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n37GiLRw005931; Tue, 7 Apr 2009 11:44:21 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 07 Apr 2009 11:44:21 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <20090407164420.GW1500@Sun.COM>
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> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE9@scygexch1.cygnacom.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <49DAC29D.6030902@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: Tue, 07 Apr 2009 17:22:51 -0000

On Mon, Apr 06, 2009 at 08:03:57PM -0700, Casey Schaufler wrote:
> I don't think so. Two SELinux machines will most likely have different
> policies even if they installed from the same media on similar hardware
> with similar configurations. If there's any reason for the NFS server
> to know anything about the client that impacts policy enforcement the
> server has to know enough to make that judgment correctly. If the server
> can ignore the client's policy there is no need to send any information.
> If the server can't ignore the client's policy it needs to be able to
> reconcile the local policy to the remote policy in order to enforce
> reasonable policy.

We can have label-aware servers with non-label-aware protocols.  But
that's too constraining: it means clients have to be at a single label
or otherwise communicate labels by convention (e.g., data location).  It
also means that interfaces to labeling will be proprietary.

We can have non-label-aware server, non-label-aware protocols, and label
aware clients, trusting the clients to enforce a common policy.  But
this too is too constraining: a) it forces one to associate labels with
document _location_, b) it forces one to trust the clients too much.

We need multi-level clients, since many users will have a
range of clearances, not just a single one (and they need a trusted
desktop).

Given the above then we need label-aware servers and label-aware
protocols so as to support for multi-level clients (with clients trusted
to within a range of labels associated with clients' and users'
authenticated identities and other authorization information).

Even before putting labels on the wire we'd have a security policy
management issue since storage can span many servers.

With labels appearing on the wire (in IP headers, in application
protocols, in PKIX certificate extensions and Kerberos V authorization-
data, ...) we simply cannot avoid the need to express common security
policies.  We also cannot force everything and everyone to operate in a
single DOI.  And we cannot avoid the need to classify the security
policies themselves, including varying classification for different
subsets of the policies.

IMO that means that we need something like SPIF, including:

 - a generic security policy data model/syntax
 - an interoperable encoding of security policies
 - a method by which two peers can detect and agree that they know a
   given common subset of a common security policy
 - label equivalencies

The last item is the least critical -- we can deal with that later.

> So you're back to mapping policies. You have to map policies if you
> want either side to do all the work. The mechanisms used to map

Yes.

> labels used by different installations of the same 1990's MLS systems
> will not work for SELinux systems installed for different purposes by
> disjoint agencies.

That's fine, unless you want them to interop and you can establish
equivalencies.  And provided SELinux can deal -- but that's less
important because if it's just a small matter of programming (i.e., we
have specs to code to or know what to code that we can write specs
from) then it's just a matter of time.

So we need to know whether solutions in this space are technically
feasible.  I believe they are.  (We also need to know whether they are
politically feasible, but here I think we'll find that they are
politically required :)

> I'm not trying to stop progress here. I am simply trying to point out
> that choosing a mechanism to implement a facility that won't work in
> the end is pretty pointless. Sure the old schemes worked in certain

No one is knowingly proposing a mechanism that won't work so far as I
can tell.

> cases in the olden days. The question is will they work now, and the
> answer is obviously "no".