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

[David Noveck <[e-mail]>]

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

I don't understand Spencer's position well  enough to know if he has
a problem with this, but given that this model has already been adopted
by the working group for arguably system-level attributes, it is hard for
me to believe such objections, if they were to exist, would be widely
shared.

Since adopting a parallel approach for the IMA metadata
format is compatible with your plans for -08, perhaps you should
adopt a similar approach (an IANA registry with a specification-required
policy) for IMA.   I know that such things have been suggested in the past
and seemed at the time like overkill, but, given that there are a number
of existing formats, and likely there will be a more general format which
has not been arrived at  right now, it might be best to take this step,
hoping that it will deal with the objections about the lack of a metadata
format specification even though the Linux community is kind of slow
about producing  one.  I think you ould have to add a new fs-scope
attribute with the id, rather than stick with the local-policy approach,
but there would b no requirement tat the client check this.

BTW, specification-required and even RFC-required do not require a
normative specification.   With specification-required, the IETF does
not have to be involved in writing the spec although a designated-expert
would have to check that it clear enough to enable implementation.

On Thu, Nov 7, 2019 at 10:56 AM Chuck Lever <[e-mail]> wrote:

> 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
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>