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

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

The issue is the only one defined at the moment in the LFS registry is the flask one. Casey doesn't have a number assigned for a SMACK label format so I believe that is why we have 0 used. When Jarret and I wrote the LFS document I believe the intent of id 0 was that this was a null identifier which was to be taken as no format specified. Essentially it would just be raw data. This seems to not have been codified in the actual document and it is not clear why that is the case. In my initial implementation before someone else took over I had a daemon similar to the old idmapd called doimapd which filled in the LFS field properly. Ideally when the kernel goes to package up the attribute it would see what LSM it is using and that LSM would provide it with a valid LFS structure for the attribute. On the other end it would understand the LFS structure and be able to unpack it.

>From an implementation standpoint I don't think this is an issue because what it means currently is the MAC on both the client and server have to match. In the future this could be changed so an intermediate daemon handles the label and policy translation. Ideally an SELinux enabled server could receive a request from a Trusted Solaris (I think its trusted extensions now) and be able to retain the MLS portion of the label and just assign an arbitrary SELinux label. This wasn't implemented or attempted as Linux is the only Labeled NFS implementation at the moment but that was the intent.

Dave

-----Original Message-----
From: Bruce Fields [mailto:[e-mail]] 
Sent: Thursday, May 3, 2018 9:47 AM
To: Tom Haynes <[e-mail]>
Cc: Quigley, David <[e-mail]>; Chuck Lever <[e-mail]>; Spencer Shepler <[e-mail]>; NFSv4 <[e-mail]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

On Thu, May 03, 2018 at 08:31:34AM -0700, Tom Haynes wrote:
> 
> 
> > On May 3, 2018, at 8:13 AM, J. Bruce Fields <[e-mail]> wrote:
> > 
> > On Wed, May 02, 2018 at 10:36:34PM +0000, Quigley, David wrote:
> >> 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.
> > 
> > By the way, something Chuck noticed is that the Linux client and 
> > server implementations are completely ignoring the LFS field--they 
> > always discard it when receiving, and set it to 0 when sending.  I 
> > assume we should at least fix them to reject non-zero values for now.
> > 
> > --b.
> 
> Actually, that is a bug in the Linux implementation!
> 
> According to RFC7569, a LFS of 0 is reserved.

If there's something else we should be using, we could modify them to send that and reject anything that's not that or zero.

We're stuck with the zero now, though, alas.

--b.