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

Chuck Lever <chuck.lever@oracle.com> Thu, 08 November 2018 18:23 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 73C9C128BCC for <nfsv4@ietfa.amsl.com>; Thu, 8 Nov 2018 10:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level:
X-Spam-Status: No, score=-4.769 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, UNPARSEABLE_RELAY=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 CY6fjIN_95W0 for <nfsv4@ietfa.amsl.com>; Thu, 8 Nov 2018 10:23:32 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 C089212426A for <nfsv4@ietf.org>; Thu, 8 Nov 2018 10:23:32 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA8IDg3W017036; Thu, 8 Nov 2018 18:23:31 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=9UFoyHlsj2jeZn21ZIc0dlVUlBXOlD7nuBAwJkI1yHI=; b=NAo4otd9G4lx+R4S4t/reXxMUA1yeJxawu3gnVyaZDRhh74lB0Lqp4nWfzxT7RPNFHPd XlIMhsecbDamFsuCcsJJgoUwSWl7i/0o5wHCYM6coIxNMmx+0oxO6tKlPN62WVFNy+QI Szj/4lZDgvLUSqCye0LEWwFVhLQU/i0VsG5h8vWdgAfN2IMmh1Rel/7CEgGyBqnO1CTC NfN4tLTZqBiA6WTFvsLPDPmNKd5g2b69+4GmgDMNihdf/09Nan367M7PHs003N20ZxkR RbXmKm2j61NuvPtrAZxNj+IM3TAPLi+h5KN4wt2zCtdu2UZQiR3036oPqO5NmhYsGSoS FA==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2nh4ar30th-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Nov 2018 18:23:31 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wA8INQUx019440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Nov 2018 18:23:26 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wA8INPjk000414; Thu, 8 Nov 2018 18:23:25 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Nov 2018 10:23:25 -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: <CCC8A8EA-7D8D-440F-B29C-1D3577FC104D@netapp.com>
Date: Thu, 08 Nov 2018 13:23:24 -0500
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDC6A311-4076-405B-AE4C-26A0BC8CE685@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>
To: "Everhart, Craig" <Craig.Everhart@netapp.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9071 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-1811080154
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/65HdT9PknbqIiQxobbvtFIaovmg>
Subject: Re: [nfsv4] Fwd: 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: Thu, 08 Nov 2018 18:23:35 -0000


> 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 assume that it will be active when I want to edit the content of a source file, or execute a binary executable file.

Most certainly just before a file is executed. If a source file
is protected, it will be assessed as it is opened but before its
contents are presented via read(2) or mmap(2). Any edits will
require that the FPI be refreshed once the file content is stable
again.

So, now that I'm paged in again, I do want to have multiple FPI
blobs per file. IMA has one for file content, and another one
for file attributes (the EVM blob). Both can exist at the same
time. I'm specifying only the IMA blob for NFS at this time, as
explained in a prior email, but you should assume that more blobs
will be coming in the future.


--
Chuck Lever