Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

"Quigley, David" <david.quigley@intel.com> Thu, 27 September 2018 18:25 UTC

Return-Path: <david.quigley@intel.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0F130EFC for <nfsv4@ietfa.amsl.com>; Thu, 27 Sep 2018 11:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6av5ReMU1pCW for <nfsv4@ietfa.amsl.com>; Thu, 27 Sep 2018 11:25:06 -0700 (PDT)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCF1130EF9 for <nfsv4@ietf.org>; Thu, 27 Sep 2018 11:25:06 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 11:25:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,311,1534834800"; d="scan'208";a="83898987"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by FMSMGA003.fm.intel.com with ESMTP; 27 Sep 2018 11:25:00 -0700
Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Sep 2018 11:24:37 -0700
Received: from orsmsx108.amr.corp.intel.com ([169.254.2.163]) by ORSMSX159.amr.corp.intel.com ([169.254.11.61]) with mapi id 14.03.0319.002; Thu, 27 Sep 2018 11:24:37 -0700
From: "Quigley, David" <david.quigley@intel.com>
To: "Everhart, Craig" <Craig.Everhart@netapp.com>, Chuck Lever <chuck.lever@oracle.com>
CC: Bruce Fields <bfields@fieldses.org>, NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt
Thread-Index: AQHUVBa2AAdeOdxGi0Gd80a1y+lVbqT//Y6AgAAK2oCAA3HogIAAAZqAgABPtICAAPABAIAAClqAgAAEKwCAAAnTgIAAE/6AgAADDoD//4sjgA==
Date: Thu, 27 Sep 2018 18:24:36 +0000
Message-ID: <106AF901BBB25B4082BCE4FEC2F79D440646BB63@ORSMSX108.amr.corp.intel.com>
References: <153780090601.28221.16958675117475194416@ietfa.amsl.com> <CADE569F-8584-42CF-A297-E60956D368A2@oracle.com> <CAKKJt-fmB5psmtbm9PJTnhkZkZLCBnCVZnr3fMsf++exN5XObQ@mail.gmail.com> <20180926202157.GA826@fieldses.org> <1F2E60B5-E09F-4B33-8301-99C5E5A0F310@oracle.com> <20180927011257.GC2715@fieldses.org> <8461C2B0-41B3-4983-86F3-78DC4B36D077@oracle.com> <E960590D-7284-4C08-83F2-C066F4713244@netapp.com> <B15A1832-FAB9-4A0B-AF4E-F2EB1D424C57@oracle.com> <E232912D-984D-441F-9B1E-59B6C6B367F9@netapp.com> <F7774906-07F9-4ADF-AB8C-2B1D32AD3223@oracle.com> <E093BA4B-2DE5-46F7-B728-6ADD66C7781D@netapp.com>
In-Reply-To: <E093BA4B-2DE5-46F7-B728-6ADD66C7781D@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ctpclassification: CTP_NT
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzlmZjk3ODgtMDY4Mi00MWI4LWFkNmQtZTU5MGJkOTJiYmExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWjlmZjJZZm5sdnJVb1wvT2pmaWNISXJnNnZtZk43c2hsTE5RcmlST2lqeVwvQkplZjBIcFRGVjZ3ekJtOWFWbTh2In0=
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-SjEmS2BT9eZGuIRJ_2JBIqiKtc>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 18:25:08 -0000

SELinux and SMACK use different label formats. You can determine which is which by looking at the LFS identifier for the security label. This is currently set to 0 in the Linux implementation but it should be set to the LFS for the label format that you are using.

-----Original Message-----
From: nfsv4 [mailto:nfsv4-bounces@ietf.org] On Behalf Of Everhart, Craig
Sent: Thursday, September 27, 2018 12:22 PM
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Bruce Fields <bfields@fieldses.org>; NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

Sigh--great sadness.

How do I tell whether NFS security labels are MAC or SMACK or one of their friends?

Why wait for a collision before specifying how a choice of label formats is represented?

		Craig


On 9/27/18, 2:11 PM, "Chuck Lever" <chuck.lever@oracle.com> wrote:

    Hi Craig-
    
    > On Sep 27, 2018, at 9:59 AM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
    >
    > Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with some other unspecified character encoding scheme.
    >
    > The analogy here is that you're either trying to reserve an "8-bit-clean" repository of opaque data, where a server doesn't know what it's storing and a separate client has no idea what it's seeing, or you're trying to reserve a particular slot for the sole use of some format that you don't describe.  In that second case, the analogy with file name data isn't so clear: NFS is built around having exactly one (component) file name, without a label explaining how to interpret that file name label.
    >
    > But you're effectively asking for private use of the "file provenance" name space.  I hope there's never another community that also comes up with a "file provenance" description scheme.
    
    We've already taken this route this with NFS security labels. There is
    exactly one xattr that can store only _one_ of a MAC label, or SMACK,
    or ...
    
    Both cases you describe above are serviceable via the mechanism
    I proposed. If there ever is a collision, then the assessment
    applications involved can use an XML wrapper to label and store
    both types of FPI in the same slot, or they can approach the WG
    and request another fattr4 attribute.
    
    Alternatively, an implementation may choose to have a security.ima
    xattr for local consumers, and a separate xattr that stores FPI
    consumed by remote users.
    
    
    >               Craig
    >
    >
    >
    > On 9/27/18, 12:24 PM, "Chuck Lever" <chuck.lever@oracle.com> wrote:
    >
    >> On Sep 27, 2018, at 9:09 AM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
    >>
    >> This exact issue needs to be discussed in the draft--whether it makes sense for clients/servers that don't a-priori recognize the "file provenance" information to reject the communication, and how.  Should non-recognizing servers store the information blind?  Or should they reject such files?
    >
    >    Good point. I can add language that fills that in. In fact
    >    that will be a copy-and-paste from an earlier version of
    >    this document.
    >
    >
    >> Essentially, the draft seems to imply that there's a well-understood way that some community of file handlers has of describing file provenance.  Instead of explaining what that is, the author(s) of the draft simply want to standardize a way of describing data that is otherwise opaque.  The draft gives no information on how to construct an appropriate file-provenance blob of bits, to my reading, or to explain what a formatted blob of bits would mean.
    >>
    >> Let's say that there are multiple communities that all are composed of people that understand some formatting scheme.  How should they interact?  How would I (a file server) take a blob from community A and present it in a way that community B would understand?  Or is this formatting scheme to remain opaque forever?
    >>
    >> We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's fine as long as everybody who sees a given name knows how to interpret it.  (This was in the days before UTF-8 or its analogues; we had a lot of localized character sets that people wanted to use verbatim.)  Thank heavens that we no longer have that particular fight.  But this draft feels analogous: it apparently wants NFS to store and retrieve "provenance" blobs without altering them, saying that they have meaningful semantics, but without explaining what those semantics are.
    >
    >    Yes, that's what we want to do. This is exactly the same
    >    as storing opaque file data. NFS is conveying and storing
    >    data on behalf of an application which is responsible for
    >    interpreting that data.
    >
    >
    >>              Craig Everhart
    >>
    >>
    >>
    >> On 9/27/18, 11:32 AM, "nfsv4 on behalf of Chuck Lever" <nfsv4-bounces@ietf.org on behalf of chuck.lever@oracle.com> wrote:
    >>
    >>   The consequences of not recognizing the file provenance information
    >>   are not dire. In those cases, clients simply don't allow access to
    >>   the file's content, and the implementations are free to report to
    >>   the administrator that the FPI format is not recognized.
    >>
    >>   Would it help to state that in the draft?
    >>
    >
    >    --
    >    Chuck Lever
    >
    >
    >
    >
    >
    
    --
    Chuck Lever
    
    
    
    

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4