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

[Chuck Lever <[e-mail]>]

> On Nov 10, 2018, at 6:31 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Thu, Nov 08, 2018 at 01:23:24PM -0500, Chuck Lever wrote:
>> 
>> 
>>> On Nov 8, 2018, at 12:03 PM, Everhart, Craig <[e-mail]> wrote:
>>> 
>>> Hi Chuck, just one point.
>>> 
>>> On 11/8/18, 11:54 AM, "Chuck Lever" <[e-mail]> wrote:
>>> 
>>>>  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.
>>> 
>>> 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 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 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
> can be built, viz. my DISCUSS ballot position on
> draft-ietf-lisp-rfc6830bis.  The situation here seems much simpler than
> that one is, though.)

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