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

[Chuck Lever <[e-mail]>]

Hi David-

> On May 2, 2018, at 6:36 PM, Quigley, David <[e-mail]> wrote:
> 
> 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).

Yep, I get that, but I don't see a functional problem here. It seems like
an artificial constraint to say that we can't store IMA metadata in a
generic security label, and I don't see any explicit prohibition to doing
so laid out in the existing RFCs (if there is one, please point it out).

You can make a similar argument about file capabilities, which are not
MAC security. Should they be excluded from using a security label for this
reason?


> 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?

A file can have capabilities associated with it, a security.ima xattr, and
a security.evm xattr. All three are separate objects and can change
independently of each other. Capabilities and IMA are not at all related
to each other, so at least these two need separate LSF numbers.


> 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.

Implementations can store the content of each LSF in separate xattrs, or
so it appears from my brief audit of the Linux implementation. I don't see
anything that prevents storing an SELinux label in one xattr, file
capabilities in a second xattr, and IMA metadata in a third xattr.


> 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. 

Thanks for looking!


> 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?

--
Chuck Lever