Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-integrity-measurement-03.txt

[Chuck Lever <[e-mail]>]

Hi Craig-

> On Nov 7, 2018, at 12:18 PM, Everhart, Craig <[e-mail]> wrote:
> 
> Hi Chuck,
> 
> Thanks for the update.
> 
> At the end of the introduction (1), you add "Unlike traditional integrity management schemes, the hash is not replaced every time a file is copied.  Instead, the signed checksum is copied along with file content and presented whenever the content is about to be used."  You're alluding to a practice with which I'm not familiar, even when you're describing traditional schemes.  Copied for reading or for writing?  What would have replaced the hash every time the file is copied--a storage system?  (I want to understand this so that I can understand how the mechanism that you're proposing will replace and modify the existing mechanism.)

The traditional scheme I'm thinking of is the mechanism that
generates and writes a checksum during media block writes.
When a file is copied, each newly allocated and written block
gets a freshly generated checksum.

This checksum is based on the data as presented to the storage
media, so it cannot protect against unwanted changes due to
software bugs or malicious acts during the file copy operation.

The checksums on blocks of the original copy of the file data
are referenced only when the blocks are read. The checksums do
not follow the data to the new copy: fresh checksums are
generated for the copied blocks.

Indeed, block checksums are typically not exposed outside the
storage device. So there is no way to copy them.

Unlike that scheme, FPI follows without change the file's data
content. Or to put it another way, FPI is copied along with
the file's content to its destination. This means _any_ change
to the content between the time it is generated and the time it
is used can be detected.


> It sounds like a hash would have been replaced whenever a file was written, but this replacement copies the hash along with file content--presumably by some client-side tool?

Yes, when file content is updated, the FPI has to be refreshed.
This would be done using a tool, run on a client or on the
server, that is capable of re-signing the hash.

In it's simplest form, using FPI means that protected files
become effectively immutable. That's exactly what we want for
things like executables, which change infrequently.


> Down in 1.1, you likely want to add "only" immediately before the function that it most closely modifies; "NFS acts as only a conduit ..."  rather than "NFS acts only as a conduit...".  (e.g.: I'd hope that NFS acts as more than a conduit!)
> 
> In 4.2, can there be multiple FATTR4_FILE_PROVENANCE objects with different fpv_type values?

Right now my opinion is that should be allowed.


> How do I enumerate them?

There isn't an explicit mechanism to do that because I don't
believe that's going to be needed. The client will ask the
server for the particular fpv_values that the client supports.


> Clearly your description of the treatment of distinct fpv_type values would suggest that there would be multiple instances.  Are there other FATTR4_xxx attributes with multiple values?

Security Labels, but only one label can be stored at a time.


> It's a little odd that fpv_type is not in the fattr4 namespace, but that it represents a sub-type.  How do I specify a fpv_type to GETATTR?

struct file_prov4 {
        uint32_t                 fpv_type;
        opaque                   fpv_data<>;
};

I just copied the security label attribute. I'll have to go back
and look at how that works and copy that language to Section 4.3.


> Again, how do I enumerate all the stored fpv_type values?
> (It might be easier if there were only one possible FATTR4_FILE_PROVENANCE attribute, so that storing any fpv_type value would replace any other FATTR4_FILE_PROVENANCE attribute.

Easier how?

> Alternatively, you could allow for FATTR4_FILE_PROVENANCE_xxx values, in which the "xxx" extension semantically replaces your suggested fpv_type value.)

That means we'd have to extend NFSv4.2 every time we add a new
fpv_value. If we use a subtype and an IANA registry, it becomes
simple to add a new value -- it does not require any change to
the NFSv4 protocol.


--
Chuck Lever