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

From: [email-masked]
Date: Wed, 07 Nov 2018 07:22:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 WG of the IETF.

        Title           : File Content Provenance for Network File System version 4
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-integrity-measurement-03.txt
	Pages           : 15
	Date            : 2018-11-07

Abstract:
   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables file provenance information to be conveyed
   between NFS version 4.2 servers and clients.  File provenance
   information authenticates the creator of a file's content and helps
   guarantee the content's integrity from creation to use.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-integrity-measurement/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-integrity-measurement-03
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Chuck Lever <[email-masked]>
Date: Wed, 7 Nov 2018 10:25:41 -0500

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-03.txt
> Date: November 7, 2018 at 10:22:02 AM EST
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

Revision -03 is an attempt to address Craig Everhart's concerns about the
interoperability of the proposed mechanism. I've introduced an IANA registry
for File Provenance Information types, as suggested by Benjamin Kaduk.

Thanks for everyone's time on this project.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 7 Nov 2018 17:18:50 +0000

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.)  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?

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?
How do I enumerate them?  
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?
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?
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.  Alternatively, you could allow for FATTR4_FILE_PROVENANCE_xxx values, in which the "xxx" extension semantically replaces your suggested fpv_type value.)

		Best,
		Craig

On 11/7/18, 10:25 AM, "nfsv4 on behalf of Chuck Lever" <[email-masked] on behalf of [email-masked]> wrote:

    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

    

    --
    Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 8 Nov 2018 10:43:40 -0500

Hi Craig-

> On Nov 7, 2018, at 12:18 PM, Everhart, Craig <[email-masked]> 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.

> 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.

> (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

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 8 Nov 2018 16:14:12 +0000

Hi Chuck.   Comments in-line.
		Craig

On 11/8/18, 10:44 AM, "Chuck Lever" <[email-masked]> wrote:
   
    Hi Craig-

    

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?

    This means _any_ change

And detected by only these special tools.

    

The down-side is that they'd need to be enumerated, if such a system were to be backed up, for example.

Right, as long as it's only the special tools that do the reading.

And I'd suggest that the one-at-a-time semantics is important if there's no way of doing enumeration.

    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 suspect that it works because there's only one kind of security label.

    Easier how?

Principally because you wouldn't have me asking how the existing stored fpv_type values are to be enumerated.

   
I agree.  It's a flaky idea, but it has the advantage of not requiring a new type enumeration.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 8 Nov 2018 11:53:40 -0500

> On Nov 8, 2018, at 11:14 AM, Everhart, Craig <[email-masked]> wrote:
> 

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

> And detected by only these special tools.

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

> 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.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 8 Nov 2018 17:03:47 +0000

Hi Chuck, just one point.

    

Perhaps you could clarify this architecture.  The menagerie of tools that would be modified, this provenance assessor--what is the architecture of the system in which these tools exist?  Is the "provenance assessor" part of the presumed OS on the NFS client?  Is it active when I read a file with the menagerie (e.g., "cp")?  At backup time?  I assume that it will be active when I want to edit the content of a source file, or execute a binary executable file.

		Craig

---

From: Chuck Lever <[email-masked]>
Date: Thu, 8 Nov 2018 13:23:24 -0500

> On Nov 8, 2018, at 12:03 PM, Everhart, Craig <[email-masked]> wrote:
> 
> Perhaps you could clarify this architecture.  The menagerie of tools that would be modified, this provenance assessor--what is the architecture of the system in which these tools exist?  Is the "provenance assessor" part of the presumed OS on the NFS client?

We're going in circles now. I've explained this before in e-mail
and in the document.

> Is it active when I read a file with the menagerie (e.g., "cp")?

Depending on policy, it can be.

> At backup time?

Depending on policy, it can be.

The primary point of FPI is to prevent the use of corrupted file
contents. Copying or backing up file content is not necessarily
considered "use", but an administrator might be paranoid or want
some notification if tampering has occurred long before a file
is used. It's also possible that a tool can be constructed to
scrub a file system to pre-emptively identify corrupted content.

Again, this document is not meant to be a full specification of
IMA and how it's used. A discussion of tooling is out of scope,
IMO.

> I assume that it will be active when I want to edit the content of a source file, or execute a binary executable file.

Most certainly just before a file is executed. If a source file
is protected, it will be assessed as it is opened but before its
contents are presented via read(2) or mmap(2). Any edits will
require that the FPI be refreshed once the file content is stable
again.

So, now that I'm paged in again, I do want to have multiple FPI
blobs per file. IMA has one for file content, and another one
for file attributes (the EVM blob). Both can exist at the same
time. I'm specifying only the IMA blob for NFS at this time, as
explained in a prior email, but you should assume that more blobs
will be coming in the future.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 9 Nov 2018 05:52:01 -0500

> I do want to have multiple FPI
> blobs per file.

If so, then this desire could be accommodated more simply than by
allowing each such blob type (fpv_type) to be invidually settable
and retrievable as is suggested in -03.  The existing NFSv4 attribute
model would need substantial change to accommodate that.

I think the best way to provide for the possibility of multiple blobs would
be to make the provenace  attribute an array of blobs.   I think the
following would work but I might have messed up the typdef syntax.

typedef file_prov4 fattr4_file_provenance[];

Those who sign content will need to generate all the blobs they want
to support. I don't see why setting each blob needs to a separate operation.

Assesors, could get the entire blob set and fairly easily find the blob(s)
they want to access.

> IMA has one for file content, and another one
> time.

OK.

> I'm specifying only the IMA blob for NFS at this time, as
> explained in a prior email,

As I understood it, wou were not actually specifying it but were
simply directing people to a description.   I can't recall the details, but
I recall some complexity about whether that description was actually
a specfication.

> but you should assume that more blobs

They might and implemeters will make their own decisions about how much
space to allocate to store potenial blobs.

On Thu, Nov 8, 2018 at 1:23 PM Chuck Lever <[email-masked]> wrote:

> > Perhaps you could clarify this architecture.  The menagerie of tools
> that would be modified, this provenance assessor--what is the architecture
> of the system in which these tools exist?  Is the "provenance assessor"
> part of the presumed OS on the NFS client?
>
> > I assume that it will be active when I want to edit the content of a
> source file, or execute a binary executable file.
>

---

From: Chuck Lever <[email-masked]>
Date: Fri, 9 Nov 2018 10:27:30 -0500

Hi Dave-

> On Nov 9, 2018, at 5:52 AM, David Noveck <[email-masked]> wrote:
> 

Modifying one at a time doesn't seem impractical, but
getting all of them at once would eliminate the need for
enumeration.

> typedef file_prov4              fattr4_file_provenance[];

The problem with this design is it makes it impossible for
the client to predict how large its RPC Reply buffer needs
to be.

> to support.  I don't see why setting each blob needs to a separate operation.

Because they might be set at different points in a file's
lifetime by different tools.

> Assesors, could get the entire blob set and fairly easily find the blob(s) they want to access.
>  

What I meant was, I'm requesting from IANA just the IMA
container. The EVM container will wait for another
document.

> They might and implemeters will make their own decisions about how much space to allocate to store potenial blobs.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 10 Nov 2018 05:31:00 -0600

> IMA and how it's used. A discussion of tooling is out of scope,

I am not going to say that a discussion of tools needs to be in the
document, but I think it's okay to have  some discussion on the list to get
people onboard with the idea that one can use this to build a useful
system.  (There is precedent for wanting confidence that a useful system
can be built, viz. my DISCUSS ballot position on
draft-ietf-lisp-rfc6830bis.  The situation here seems much simpler than
that one is, though.)

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Sat, 10 Nov 2018 11:54:49 -0500

> On Nov 10, 2018, at 6:31 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> system.

There already is a Linux implementation of IMA for local file
systems. Part of this effort will be prototyping the protocol
elements described in this document, and then assessing whether
they can be a successful part of the existing Linux IMA eco-
system (ie, do we end up with a useful system when NFS is
included?).

So I agree that such evaluation is necessary, but I feel like
it will come a little later when there is real code to try out.
I don't intend to push this document through publication without
prototyping and assessment.

> (There is precedent for wanting confidence that a useful system

Fair enough, it wasn't clear to me whether Craig was asking for
an informal discussion here on the list or for something to be
introduced into the document. To clarify what I wrote above, I
believe that a detailed discussion of tooling is out of scope
for the document.

Even so, the second paragraph of Section 1.1 reads:

   File provenance information is generated and signed by a "provenance
   authority", and then associated with each file using special tools.

Does more need to be said here and/or in Section 5.2 ?

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Sun, 11 Nov 2018 17:20:39 +0000

Is there something stopping you from implementing something now?  To run your proposed experiment?

If this is to be useful for more than Linux platforms, it would seem that the other platforms’ communities would need to be able to participate, ideally in more than a transparent-repository fashion.  Will those other platforms need to have interesting trust relationships with a Linux-based installation?  Why or why not?  What kinds of relationships are required?

Or is this a conduit for only Linux machines?  If it is, will those multiple machines require trust relationships of interest?  Surely it’s at least as interesting as having compatible, mutually-understood spaces for owners and groups; but from your document as well as the Linux reference that you’ve given, it’s not at all obvious what the answers are.  At least not to me.

            Craig

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Chuck Lever <[email-masked]>
Sent: Saturday, November 10, 2018 11:54:49 AM
To: Benjamin Kaduk; Everhart, Craig
Cc: NFSv4
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-03.txt

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Nov 2018 00:39:37 -0600

> prototyping and assessment.

It sounds like we're on the same page, then, great.

(Though I do agree with Craig that I'm not sure what would prevent
prototyping even now.)

> Does more need to be said here and/or in Section 5.2 ?

Nothing it sticking out at me at the moment as missing, though I only
skimmed.  It may be worth considering phrasing involving "out of band", as
that term is frequently used in IETF documents.

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Mon, 12 Nov 2018 10:10:09 -0800

> On Nov 11, 2018, at 10:39 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I think so. The big picture questions I'm taking away are:

- Will this be a feasible and valuable addition to IMA?
- How will interoperability issues be resolved?
- Resolution of details about language required in the spec

> (Though I do agree with Craig that I'm not sure what would prevent

I intended to start prototyping a few months ago, but the
discussion on this mailing list has continued to prompt
modifications of the original protocol elements that I
proposed in -00.

--
Chuck Lever