Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07

[Chuck Lever <[e-mail]>]

Hi Spencer, thanks for your reply. Unfortunately it leaves me with more questions.

> On Nov 7, 2019, at 2:05 AM, spencer shepler <[e-mail]> wrote:
> 
> 
> Apologies for top posting but I would like to address one portion of this thread only.
> 
> I have poached one particular comment.... the below is quoted from Chuck's last response on this thread.
> --
> > I think I lack the background to understand why Spencer doesn't believe
> > this is an appropriate use of the NFS protocol, but I don't think that this
> > is the right thread to educate me.
> 
> I'm also interested in learning more about this. The same argument has been
> made in the past about extending NFS in general, and I guess I had assumed
> that this had been resolved with the publication of RFCs 8178 and 8276.
> 
> --
> 
> I agree that RFC 8178 provides the ability to add features, particularly attributes, to the protocol and I agree with the utility of 8178 and that is appropriate.
> 
> I also agree with the utility of RFC 8276 but I disagree with the interpreted precedent of the RFC per Chuck's comment.
> 
> To quote from RFC 8276:
> 
> "Xattr keys and values MUST NOT be interpreted
> by the NFS clients and servers, as such behavior would lead to
> non-interoperable implementations.  If there were a need to specify
> one or more attributes that servers need to act upon, the appropriate
> semantics would be specified by adding a new attribute for the
> purpose as provided for by [RFC5661] and [RFC8178]."
> 
> I read the proposed integrity measurement capability as providing a "system-level" interpretation.

The intent of the quoted text was to prevent the use of xattrs as a side-channel ioctl mechanism, which I'm not proposing here. However, I am proposing "adding a new attribute" as suggested in the quoted text. Therefore, I feel that I'm following the letter, if not also the intention, of this text.


> The decision to allow for the execution of application binaries is a "system" level activity or in other words, a feature that explicitly requires the client to interpret the semantics of the protocol extension.  Because of the client's need to interpret the capability, the definition should be defined in a way that it can be implemented in an open fashion and hopefully, but not required, defined in a way that it is "upgradeable".

"System level activity" is not defined in the quoted text, so it's not clear-cut to me that there is any consensus that can be relied upon as solid rhetorical ground.

Interpretation of the stored metadata can be done by the NFS implementations themselves, by the kernels on those hosts, or by unprivileged agents running in user space. The same functionality, but are all three "system level activity" ? Not clear where the boundary is.

Why is "outside of the NFS implementation but in the kernel" still a system-level activity? How would you draw this line on a non-POSIX or user space NFS client, for example?


> To the point of "open", I don't believe the availability of open source sufficient in this instance.  Yes, a clean-room approach to implementation can be executed but even with that action, a patent claim can still be made.  Therefore, without the protocol definition being captured in a way that clearly allows the reader to have a sense that IETF's policies for disclosure have followed, I don't believe it should be allowed as an extension of the NFS protocol.

NFS is being used only to transport and store this metadata, in the same way that is used to transport and store file content, which is also interpreted on clients in ways that are out of the purview of the IETF. It would be a stronger argument if there existed an actual IETF document which recorded a consensus and an on-point legal opinion about this.

My document also permits an implementation not to interpret the metadata at all. If a reader or implementer has any doubts, s/he can simply treat that metadata as the opaque blob that it is.


> So, I am left with my objection to this work moving forward.

Even if I introduce an Informative definition of the metadata format to the document? Does that not meet your second suggested way forward (from earlier email)?

Is there a need to make the format Normative, either within the IETF or in some other standards setting context?

What if the Linux community made the IMA metadata format completely open (ie, stated publicly that it is unencumbered IP) ?

What if Linux stored this metadata in a user xattr instead?


> If this proposal would to be accepted, it sets a precedent that a individual could define a similar extension for their favorite XYZ product in such a way that interoperable implementations could be not implemented.  In least this could lead to a proliferation of OS, vendor specific feature creep and at worse, non IP infringing implementations would be impossible to implement.

That's dire. I wish this requirement was clearly documented somewhere.

Why isn't the SELinux label work a problem in this regard?


--
Chuck Lever