Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

Chuck Lever <chuck.lever@oracle.com> Wed, 02 May 2018 21:36 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 A5C5E12DA3D for <nfsv4@ietfa.amsl.com>; Wed, 2 May 2018 14:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, UNPARSEABLE_RELAY=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 suXLweC8NGcY for <nfsv4@ietfa.amsl.com>; Wed, 2 May 2018 14:36:21 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 E74AE12DA2C for <nfsv4@ietf.org>; Wed, 2 May 2018 14:36:20 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w42LaCkO129849; Wed, 2 May 2018 21:36:19 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-2017-10-26; bh=5Ss0p9U7GxCi4YrkD7LJpx0Wp9eqpJ8IB9nSxd97k4k=; b=pZH2/VUy8grxSSbXP8RpI1F6OCjb/x/RWZFrt88XDsuBvDE5RRysM9kmVukhwqsdJHkZ FDQKOKckiahtC621q929QXouCgCSCJJI1xjP9Asx/+ThEf/9kKPc2OyeNAijpeB3XsmP Op667oXpLsk0fh+JaH1Hd1ycziFZugSosBotuHQAexLqE4xrQTZP586AIt6dU0xvIMGe MRi/Ur1uzm4XWw9yoD0lSCSP7ajejWhN5Pa3eC0YeDBa++/TrXprghWG8tW+Mmf103tD ALwTg+qSiNHM4KW82h2kxLCqRlUdnS7wz7q/84EoZsNIeSf6Ne+ixn3KY8CJhEkRFS1O Bw==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2hmeg5y7rm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 May 2018 21:36:19 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w42LaI5B019834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 May 2018 21:36:18 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w42LaH1b028996; Wed, 2 May 2018 21:36:17 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2018 14:36:17 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <2CBB38A6-45FF-46A4-96A5-5D1B431E1365@gmail.com>
Date: Wed, 02 May 2018 17:36:16 -0400
Cc: Spencer Shepler <spencer.shepler@gmail.com>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE7EE7BF-F4BB-436C-8A3B-2097DBCB6066@oracle.com>
References: <152337099624.13448.11040477333954216664.idtracker@ietfa.amsl.com> <FB6B8D57-CEF6-46E1-97C7-E43C7E49752F@oracle.com> <2CBB38A6-45FF-46A4-96A5-5D1B431E1365@gmail.com>
To: Tom Haynes <loghyr@gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8881 signatures=668698
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-1711220000 definitions=main-1805020180
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/fEwI0EdBK9XnXqStIybciZ3a7yM>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 02 May 2018 21:36:22 -0000


> On May 2, 2018, at 5:30 PM, Tom Haynes <loghyr@gmail.com> wrote:
> 
> Hey Chuck,
> 
> For the most part, my issues are the ones common to first drafts.
> 
> And Spencer S, 
> 
> Can we nominate this as official WG document? It is mature enough and on point with the earlier LFS work.

Tom, thanks for the review. I was planning to submit

  draft-cel-nfsv4-linux-seclabel-xtensions-01

next week with substantial clarifications and some corrections.
If the WG and Spencer approve your request, I can submit

  draft-ietf-nfsv4-linux-seclabel-xtensions-00

instead.


> Thanks,
> Tom
> 
> Abstract
> 
> NFS version 4.2 
> Need to define NFS first.
> 
> Introduction
> 
> Before specifying new protocol,
> ->
> 
> Before specifying a new protocol,
> —
> 
> (hereafter, IMA)
> (hereafter, EVM)
> drop the hereafters
> 
> —
> 
> This is done by cryptographically signing HMAC
> please introduce HMAC
> --
> RSA public key signature
> Please define RSA
> 
> ——
> 
> The goals and use cases of the Linux Integrity Measurement
>    Architecture (IMA) are presented in further detail in [IMA-WP].
> 
> Already have defined IMA
> 
> —
> 
> with the
>    superuser 
> 
> What is a superuser?
> 
> ——
> 
> You then have four bullet points, which as they are complete sentences should end with ‘.’
> 
> —
> 
> execve(2)
> 
> need a citation (probably to POSIX)
> 
> ===
> 
> Section 3
> 
> Linux file capabilities
> becomes
> a capability set
> without motivating the connection.
> 
> =====
> 
> LFS
> 
> not introduced.
> 
> ====
> 
> MAC
> 
> not introduced
> 
> —
> 
>    In order to enable file capabilities to be retrieved or updated in a
>    single RPC, the text format representation of a capability set MUST
>    NOT exceed 8192 bytes in length.
> 
> 
>    In order to enable IMA metadata to be retrieved or updated in a
>    single RPC, a signed hash MUST NOT exceed 4096 bytes in length.
> 
> Why the restrictions? Is it a matter of the length of the compound?
> 
> ——
> 
> a Merkle
> citation?
> 
> ——
> 
> An NFSv4 server is required to enforce a suitable level of privilege
>    before allowing a local or remote agent to alter NFSv4 Security
>    Labels.  Consult Section 9.6 of [RFC7862] for further details.
> 
> 
> Is the last sentence a sentance?
> 
> ——
> 
> Therefore additional protection using GSS
>    [RFC7861] or other security mechanisms is not mandatory.
> 
> 
> Either define GSS or perhaps say RPCSEC_GSS?
> 
> 
> 
> 
> 
> 
> 
>  

--
Chuck Lever