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

[Chuck Lever <[e-mail]>]

> On Nov 8, 2018, at 11:14 AM, Everhart, Craig <[e-mail]> wrote:
> 
> Hi Chuck.   Comments in-line.
> 		Craig
> 
> On 11/8/18, 10:44 AM, "Chuck Lever" <[e-mail]> wrote:
> 
>    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.
> 
> I thought that your "traditional" scheme was to refer to how "traditional provenance" schemes worked.  Referring to this internal, unexposed checksum inside a storage system as a "traditional integrity management" scheme seems to be a strained parallel.  Perhaps "Unlike an integrity management scheme based solely on file content as seen on the file storage device"?
> 
>    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. 
> 
> By one of those special tools, again?  What copying mechanism will know about provenance?

Copying does require some modification of the normal menagerie
of file system utilities like cp, tar, and rsync.


>    This means _any_ change
>    to the content between the time it is generated and the time it
>    is used can be detected.
> 
> And detected by only these special tools.

No, the FPI is evaluated by the provenance assessor before each
access of the file.


>> 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.
> 
> The down-side is that they'd need to be enumerated, if such a system were to be backed up, for example.
> 
>> 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.
> 
> Right, as long as it's only the special tools that do the reading.
> 
> 
>> 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.
> 
> And I'd suggest that the one-at-a-time semantics is important if there's no way of doing enumeration.
> 
> 
>> 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<>;
>    };
> 
> That's in the GETATTR reply, right--how the NFS server indicates an attribute to the NFS client.  How does an NFS client specify to the GETATTR sent from client to server that it is interested in a specific value of fpv_type and not others?  (Per my reading, GETATTR accepts only the current file handle as a parameter.)  In the security-label regime, as you say, you ask for the security attribute and get back the (only) one that is stored.  Apparently you envision a file system in which many types can be stored simultaneously.  As an NFS client, how do I indicate the fpv_type value of interest to the NFS server?
> 
>    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.
> 
> I suspect that it works because there's only one kind of security label.

Agree, I will have to fix this in the document.

Jury is out on one or many, so it might be a little while
before a fresh revision of the document comes along.


>> 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?
> 
> Principally because you wouldn't have me asking how the existing stored fpv_type values are to be enumerated.
> 
>> 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.
> 
> I agree.  It's a flaky idea, but it has the advantage of not requiring a new type enumeration.

--
Chuck Lever