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

Casey Schaufler <casey@schaufler-ca.com> Tue, 07 April 2009 03:03 UTC

Return-Path: <casey@schaufler-ca.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 4DF023A6B92 for <saag@core3.amsl.com>; Mon, 6 Apr 2009 20:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level:
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 wvACYOveHRK4 for <saag@core3.amsl.com>; Mon, 6 Apr 2009 20:03:03 -0700 (PDT)
Received: from smtp101.prem.mail.sp1.yahoo.com (smtp101.prem.mail.sp1.yahoo.com [98.136.44.56]) by core3.amsl.com (Postfix) with SMTP id 987373A6D4E for <saag@ietf.org>; Mon, 6 Apr 2009 20:03:02 -0700 (PDT)
Received: (qmail 57973 invoked from network); 7 Apr 2009 03:04:08 -0000
Received: from unknown (HELO ?192.168.1.102?) (casey@64.41.22.89 with plain) by smtp101.prem.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 03:04:08 -0000
X-YMail-OSG: ueV0.lYVM1nRbR5iB77VFh52zT7_k4d5WStHFc5QIs17tAowvYqD5oYKh20L0NmGMNBJP9PZKOFmGUw2xSeLOoRYZri.eiYUgg_hrW_sDT_UUSIu8m653yJpAtZovTPqllZ.QeTLI4uIQU.OTEJPnla43a6_PB5L6hwnVRFM2GjLRFkEdJVor1uFmU0IZOhDx2Hk942X61e5QPZr148m9OG0Y9uTcsl8GP72C_K8PE8Zcr7G9hmfKOgWfB4YjAyLjDqXj8hPPwkkrxlTCd3efQq0VuHYdDpwPlAEIdo56UdGCt7.
X-Yahoo-Newman-Property: ymail-3
Message-ID: <49DAC29D.6030902@schaufler-ca.com>
Date: Mon, 06 Apr 2009 20:03:57 -0700
From: Casey Schaufler <casey@schaufler-ca.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.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>
In-Reply-To: <20090406180424.BA7AC9A4749@odin.smetech.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 07 Apr 2009 11:18:16 -0700
Cc: Nicolas Williams <Nicolas.Williams@sun.com>, labeled-nfs@linux-nfs.org, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler <casey@schaufler-ca.com>, 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 03:03:10 -0000

Russ Housley wrote:
> ...
>
> No.  They are two separate concerns.
>
> Mapping labels between two different policies.  Hopefully this can be 
> avoided altogether in the NFS context.

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.

The problem is that the server is using client subject information
to enforce policy based on server object information. If the policies
are similar (e.g. two Bell & LaPadula MLS systems) enforcement is
merely difficult because the two system may have different values for
what means "UNCLASSIFIED". For an SELinux system and an MLS system
to work you've got much more on your hands than matching up category
bits. If you don't do so however you can not make an access control
decision based on the information passed from the other side that can
possibly make sense.

You could decide that the server should enforce server policy and
require that the client enforce client policy and hope that between
the two nothing leaks out that you really care about. I seriously
doubt that's what you want.

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
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.

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
cases in the olden days. The question is will they work now, and the
answer is obviously "no".