Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-03.txt
Chuck Lever <chuck.lever@oracle.com> Mon, 12 November 2018 18:10 UTC
Return-Path: <chuck.lever@oracle.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 309B8130E65 for <nfsv4@ietfa.amsl.com>; Mon, 12 Nov 2018 10:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 ZVkqgm0gRWlC for <nfsv4@ietfa.amsl.com>; Mon, 12 Nov 2018 10:10:13 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 BB9CD126CC7 for <nfsv4@ietf.org>; Mon, 12 Nov 2018 10:10:13 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wACI3sBY145580; Mon, 12 Nov 2018 18:10:12 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=TjHM0u1Vd1QDzzq6BnJnFYF/Ix9W4PfKU9nWNboR5as=; b=DamzoFsRUvynnTNtA/i344ae808gyHoOSRUnhydWVvC5CIuWevdRJhFDCvDd63xzm1YY x499CvHvlqXldiSQ2NMmlT4WSOQGS8KUBgPG4Pp36XIQNBz5/7TZAmUX5meIOxZQO7tr 8fwYCJdOlseiZbHPhYG1oJ1yY0GIavWg4Fj/XJP+lqq9hNKvc73JNzAiV8Qh0DxjY5lc OACrw0axrkCy6iDcgsyx1eytdwZuvTjHcE44TPdxx/8SSYBATe1YSrrYWxWQYi5fRKYp 9M2RI/Ga1ycP3ptGFmio+C0/QEUtFvZkm7ozU/gy1t5NbfiRIHcu/tyOQq+NigwuhLW6 9w==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2nnwg16kph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Nov 2018 18:10:12 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wACIABMn027004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Nov 2018 18:10:12 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wACIABTL018180; Mon, 12 Nov 2018 18:10:11 GMT
Received: from [192.168.32.39] (/64.114.255.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2018 10:10:11 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20181112063937.GB99562@kduck.kaduk.org>
Date: Mon, 12 Nov 2018 10:10:09 -0800
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A280D7E7-9D6F-4984-B588-022ADF5A0D0A@oracle.com>
References: <154160412218.26446.11676556173331817093@ietfa.amsl.com> <74E10D08-6181-49C8-B994-6554C72C4B7D@oracle.com> <BBC9F2E1-4E81-4FE4-99D0-A0B23F33AAD4@netapp.com> <D1E8642B-9A07-4812-82E0-982EDC6EF73E@oracle.com> <578769FE-6C12-4003-A579-7FB461D99A8A@netapp.com> <32BFC3DE-BF20-4A3B-88AC-FAF2C19F714D@oracle.com> <CCC8A8EA-7D8D-440F-B29C-1D3577FC104D@netapp.com> <CDC6A311-4076-405B-AE4C-26A0BC8CE685@oracle.com> <20181110113100.GW65098@kduck.kaduk.org> <B37DE303-A1B8-4817-B814-D9B7F8EDB954@oracle.com> <20181112063937.GB99562@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9075 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811120159
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pdrVAl5XcmFL9P2MeItVFIh2I8I>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-03.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: Mon, 12 Nov 2018 18:10:16 -0000
> On Nov 11, 2018, at 10:39 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > > On Sat, Nov 10, 2018 at 11:54:49AM -0500, Chuck Lever wrote: >> >> >>> On Nov 10, 2018, at 6:31 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: >>> >>> On Thu, Nov 08, 2018 at 01:23:24PM -0500, Chuck Lever wrote: >>>> >>>> >>>>> On Nov 8, 2018, at 12:03 PM, Everhart, Craig <Craig.Everhart@netapp.com> wrote: >>>>> >>>>> Hi Chuck, just one point. >>>>> >>>>> On 11/8/18, 11:54 AM, "Chuck Lever" <chuck.lever@oracle.com> wrote: >>>>> >>>>>> This means _any_ change >>>>>> to the content between the time it is generated and the time it >>>>>> is used can be detected. >>>>>> >>>>>> And detected by only these special tools. >>>>> >>>>> No, the FPI is evaluated by the provenance assessor before each >>>>> access of the file. >>>>> >>>>> Perhaps you could clarify this architecture. The menagerie of tools that would be modified, this provenance assessor--what is the architecture of the system in which these tools exist? Is the "provenance assessor" part of the presumed OS on the NFS client? >>>> >>>> We're going in circles now. I've explained this before in e-mail >>>> and in the document. >>>> >>>> >>>>> Is it active when I read a file with the menagerie (e.g., "cp")? >>>> >>>> Depending on policy, it can be. >>>> >>>> >>>>> At backup time? >>>> >>>> Depending on policy, it can be. >>>> >>>> The primary point of FPI is to prevent the use of corrupted file >>>> contents. Copying or backing up file content is not necessarily >>>> considered "use", but an administrator might be paranoid or want >>>> some notification if tampering has occurred long before a file >>>> is used. It's also possible that a tool can be constructed to >>>> scrub a file system to pre-emptively identify corrupted content. >>>> >>>> Again, this document is not meant to be a full specification of >>>> IMA and how it's used. A discussion of tooling is out of scope, >>>> IMO. >>>> >>> >>> I am not going to say that a discussion of tools needs to be in the >>> document, but I think it's okay to have some discussion on the list to get >>> people onboard with the idea that one can use this to build a useful >>> system. >> >> There already is a Linux implementation of IMA for local file >> systems. Part of this effort will be prototyping the protocol >> elements described in this document, and then assessing whether >> they can be a successful part of the existing Linux IMA eco- >> system (ie, do we end up with a useful system when NFS is >> included?). >> >> So I agree that such evaluation is necessary, but I feel like >> it will come a little later when there is real code to try out. >> I don't intend to push this document through publication without >> prototyping and assessment. > > It sounds like we're on the same page, then, great. I think so. The big picture questions I'm taking away are: - Will this be a feasible and valuable addition to IMA? - How will interoperability issues be resolved? - Resolution of details about language required in the spec > (Though I do agree with Craig that I'm not sure what would prevent > prototyping even now.) I intended to start prototyping a few months ago, but the discussion on this mailing list has continued to prompt modifications of the original protocol elements that I proposed in -00. >>> (There is precedent for wanting confidence that a useful system >>> can be built, viz. my DISCUSS ballot position on >>> draft-ietf-lisp-rfc6830bis. The situation here seems much simpler than >>> that one is, though.) >> >> Fair enough, it wasn't clear to me whether Craig was asking for >> an informal discussion here on the list or for something to be >> introduced into the document. To clarify what I wrote above, I >> believe that a detailed discussion of tooling is out of scope >> for the document. >> >> Even so, the second paragraph of Section 1.1 reads: >> >> File provenance information is generated and signed by a "provenance >> authority", and then associated with each file using special tools. >> >> Does more need to be said here and/or in Section 5.2 ? > > Nothing it sticking out at me at the moment as missing, though I only > skimmed. It may be worth considering phrasing involving "out of band", as > that term is frequently used in IETF documents. > > -Ben > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 -- Chuck Lever
- [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-me… internet-drafts
- [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-integri… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Everhart, Craig
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Everhart, Craig
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Everhart, Craig
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… David Noveck
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Chuck Lever
- Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-int… Benjamin Kaduk
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Everhart, Craig
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever