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

["Everhart, Craig" <[e-mail]>]

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 <[e-mail]>
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

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.




> 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