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

[Tom Haynes <[e-mail]>]

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.

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?