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

[Chuck Lever <[e-mail]>]

> On May 3, 2018, at 11:42 AM, Tom Haynes <[e-mail]> wrote:
> 
> 
> 
>> On May 3, 2018, at 6:49 AM, Chuck Lever <[e-mail]> wrote:
>> 
>> 
>> 
>>> On May 2, 2018, at 8:12 PM, Tom Haynes <[e-mail]> wrote:
>>> 
>>> Hey Chuck,
>>> 
>>> For some reason I thought you were describing what Linux was doing, not something new...
>>> 
>>> But yeah, David is right, only one LFS is going to work.
>>> 
>>> I’ll have to check if xattrs allows for system atttrs, but if it does, why can’t you use them?
>> 
>> Hi Tom-
>> 
>> NFSv4 xattrs expose only the user namespace. xattrs in the security.yada namespace
>> are not exposed to NFS clients, for example.
>> 
>> Initially we were thinking of using NFSv4 security labels only for experimentation,
>> but there didn't seem to be any reason not to use them for the long-term solution.
>> Since it now appears that there can't be a separate label for security.ima and
>> security.evm, that makes it challenging to use security labels even for
>> experimentation.
>> 
> 
> No, they are not challenging to use for experimentation if you are using LNFS as designed.

I meant:

It is challenging to use NFSv4 security labels to experiment with IMA,
because IMA requires storing two independent metadata objects per file.

To experiment, I would need to find a way of encoding both objects so
that they could be stored together in the same label. That potentially
introduces a read-modify-write cycle if a client wants to update just
one of those objects.


> I.e., someone can go in and implement a new Label Format Specifier and use 128 - 255.

However if the existing seclabel implementation (Linux) does not pay
attention to or store the LSF values, there is already an interoperability
problem with experimental implementations, isn't there? That can be
fixed, though.


> BTW, it is also the case that you could not use LFS values of 1, 2, and 3 as described in RFC7569.
> The allowed new values start at 260.

The range past 255 appears to be for MAC content. I chose LFS values in
the reserved range because both IMA and file capabilities are not MAC,
similar to SELinux contexts, which appears to use reserved value 0.
I was told that SELinux is not MAC.

All academic now. I think everyone would be more comfortable with new
fattr4 attributes rather than abusing security labels, so I will pursue
the former instead.

Thanks for your review!


--
Chuck Lever