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

["Quigley, David" <[e-mail]>]

I can understand wanting to use the sec_label field for capabilities but using it for the IMA and EVM data isn’t really in the spirit of what we designed this for. Those are integrity mechanisms and on Linux systems they are completely separate from the LSMs (access control is not integrity).

Also having them as 3 different LFS ids make no sense. The LFS is supposed to describe the format of what you are sending and receiving for the sec_label field. Unless something changed in the last rounds of revisions to the sec_label support there should only be one value per file?

Also something to consider is that Nico explicitly separates capabilities from MAC labeling in in RPCSECGSSv3. This is because traditionally capabilities and MAC systems are orthogonal to each other. I know file capabilities are different from the regular capabilities on processes in Linux but it is something to consider that on a normal Linux system they can co-exist and be enforced at the same time. With this mechanism you couldn’t support both SELinux and file-capabilities at the same time like you could on a local system.

I will be able to provide better feedback once I’ve read through the document another couple of times but those are my initial impressions just from a sec_label and LFS perspective.

Dave

From: nfsv4 [mailto:[e-mail]] On Behalf Of Tom Haynes
Sent: Wednesday, May 2, 2018 3:30 PM
To: Chuck Lever <[e-mail]>; Spencer Shepler <[e-mail]>
Cc: NFSv4 <[e-mail]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

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?