Re: [nfsv4] Review of draft-ief-nfsv4-integrity-measurement-04

[Chuck Lever <[e-mail]>]

Hi Dave-

> On May 21, 2019, at 5:52 AM, David Noveck <[e-mail]> wrote:
> 
> Thanks for the quick response.    I look forward to seeing -05.
> 
> Rather than subjecting each other (and the working group) to a 
> series of messages with long strings of >'s, let me try to summarize
> our remaining disagreement by noting that you are uncomfortable with
> my description of this as a linux-only feature and deny that this
> is atypical by citing a number of other features that have only a
> single implementation, in Linux.
> 
> I agree that these features are de facto Linux-only features.   I think it
> is relevant to note two reasons that I consider the im stuff different, making
> it, in -04 and probably in -05, a de jure Linux-client-only feature.   In -00, 
> there was an attempt to make this client-neutral but those efforts seem 
> to have lapsed.   Note that:
> 	• Unlike the other features you mentioned, the word "LINUX" appears as part of the attribute name, as opposed to the use of "PROVENANCE" in -00.   My interpretation of this shift is that it indicates a decision to treat this as a Linux-client-only feature, rather than one which just happens to have only a single current client implementation.

I changed the name because of comments from you and Craig.

I used LINUX because IMA is "specified" by the Linux implementation,
not because IMA is implemented only on Linux.

So let's pick a name that does not have LINUX in it. I see that RFC
8276 uses

      /// typedef component4     xattrkey4;
      /// typedef opaque         xattrvalue4<>;

No sign of "linux" there. I'm open to suggestions. If no-one has one,
I'll use FATTR4_IMA in the next revision.


> 	• With what is in the spec, it is impossible to write a non-Linux client implementation, because the format of the IMA metadata is not described.

The attributes added by the proposed protocol extension are
completely specified in this document. Any NFS client can enable
access to and updates of IMA metadata using this document.

Why would a client without an IMA implementation want to do this?
For example, the metadata can be copied with the file's content.
There is no need for any interpretation of that metadata on the
copying host, it is simply an opaque blob. But not copying that
blob means there is unwanted loss of information in the copy.

If, for instance, the Linux IMA tool "evmctl" is ported to other
operating systems (if they have xattr support), IMA metadata is
exposed to user space on that OS and can be read or set via evmctl.

I should mention that the changes to the Linux NFS client and
server implementation do not know anything about the form of the
metadata, nor do they need to.


> There have been requests to provide this and it has not been provided and I'm not sure if I will ever understand why it has not.

I have explained repeatedly on list why it is not possible. There
is no specification for IMA, there is only an implementation. What
could be cited in my document? I stated that up front when I
presented during last summer's IETF meeting. This is the major
issue with this document. There is no specification of IMA to cite.

I have also explained why there is no need for the document to
describe the metadata format: NFS acts only as a conduit, just like
it does for user xattrs or file content. The metadata is not
interpreted by either the NFS client or server implementation.

This is the same as the local filesystem case. Local filesystems
store the metadata, and a separate security module (or user space
programs like evmctl) interprets it. To the local filesystem, IMA
metadata is completely opaque. It is no different for NFS.

[ As soon as this document provides format details, it will become
the specification for IMA. I'm not sure the IETF or the WG wants
to sign up for that responsibility, and IMO the Linux community
would not settle for being tied down by an RFC either. ]


> In any case, while the server can treat this as uninterpreted data, a client implementation cannot,

I believe that is a false assertion.

When I wrote "interpreted /on/ the NFS client" I meant on the host
where the file content is accessed via NFS and then subsequently
used. The NFS client implementation itself does not interpret the
metadata any more than it cares what's in the file's byte stream.

So my quibble yesterday is now a full blown objection to your
characterization: Neither the NFS client implementation nor the
NFS server implementation interprets IMA metadata. Both are pass-
through agents.

The metadata is interpreted by a separate (trusted) agent whenever
the file content is read (or executed). But it is totally opaque
to the NFS protocol and implementations.

In this sense, IMA metadata is precisely the same as a user xattr.


> so that, until this is is specified, the ima stuff is, from the client point of view, a Linux-only feature.

Perhaps it is, practically speaking, but I disagree with your
reasoning.

I will re-write the Introduction again to clarify the above points.


--
Chuck Lever