Re: [nfsv4] Linux IMA on NFS follow-up

[Tom Talpey <[e-mail]>]

On 8/28/2018 7:22 PM, Chuck Lever wrote:
> Hi Tom-
> 
>> On Aug 28, 2018, at 4:42 PM, Tom Talpey <[e-mail]> wrote:
>>
>>> The issue of interoperation is IMA's problem: they need to
>>> be able to add/remove features while remaining compatible
>>> with what's already in on-disk filesystems, as their vision
>>> of IMA evolves. IOW they already have to solve this problem
>>> with local filesystems.
>>
>> Is your intention to limit the discussion to IMA? What about filesystems
>> which support native integrity, such as ReFS, ZFS, etc?
> 
> I think it is limited to integrity measurement. It is
> different than "native integrity", where the data is
> protected only while it's at rest on the NFS server.
> Native integrity metadata is generated on the fly by
> the filesystem itself.
> 
> Native integrity also would not seem to be suitable for
> protecting the data while in transit. NFS has a separate
> mechanism for that too.

Ok, thanks for the clarification. Obviously, I haven't read the
draft.

NFS has protection for its messages, at least if krb5i is used,
but that's a hop-by-hop protection and quite different. Not at
issue, here, got it.

> IMA provides provenance: the content hash is signed by a
> software provider. The signature plus the content hash
> guarantee that the content hasn't been altered since the
> file was written by the software provider. It ensures
> integrity from the "factory" all the way to the
> execution environment of the end user.
> 
> So this is a piece of long-lived security metadata that
> is generated independently of users or local storage
> devices.

Ok, that's clear, but it requires the upper layer to provide the
information. So NFS becomes basically a transport for the hash.
What upper layers are actually using such an interface? Are
they actually looking to use NFS?

Unless such an application is part of the discussion, I don't think
the working group should take this on.

Tom.

> Our approach to this class of metadata has been to create
> additional fattr4 attributes: ACLs, security labels, and
> so on. Here we have something that has a definite purpose,
> but no defined format.
> 
> 
>> It seems that if
>> those are present, there should be a story for NFS to use them. Or if not,
>> then a portable, interoperable NFS-level definition.
> 
> The NFS protocol and NFS implementations do not have any
> role in interpreting this metadata. All that is needed
> is to store some additional bits that will be interpreted
> elsewhere.
> 
> Seems like we've done this before: NFS security labels
> are defined elsewhere, and are not interpreted by NFS
> itself. User extended attributes, named streams are not
> interpreted by NFS, and are separate from file content.
> 
> IMO it's valid to claim that interoperability in this
> case is out of scope.
> 
> 
>> Hitching onto a
>> sidetracked train doesn't seem, to me, a recipe for success.
>> Just my view from another cheap seat.
>>
>> Tom.
>>
>>> -----Original Message-----
>>> From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
>>> Sent: Tuesday, August 28, 2018 4:06 PM
>>> To: Spencer Dawkins at IETF <[e-mail]>
>>> Cc: NFSv4 <[e-mail]>
>>> Subject: Re: [nfsv4] Linux IMA on NFS follow-up
>>>
>>>
>>>
>>>> On Aug 28, 2018, at 3:13 PM, Spencer Dawkins at IETF
>>> <[e-mail]> wrote:
>>>>
>>>> Hi, Chuck,
>>>>
>>>> You invited comments from the "cheap seats" in your note, but I think that's
>>> actually me, and people who understand what's going on better than I do
>>> would be in the orchestra pit seats. So I'd also invite comments from people
>>> who understand what's going on better than I do.
>>>
>>> According to the RFC Editor, as AD you are the final
>>> authority on what is an adequate set of citations
>>> for the NFS specs we publish, so you get to be the
>>> conductor today.
>>>
>>> Or anyway, you get first crack at an opinion.
>>>
>>>
>>>> Having said that ...
>>>>
>>>>> On Tue, Aug 28, 2018 at 1:38 PM Chuck Lever <[e-mail]>
>>> wrote:
>>>>> Hi Spencer D. !
>>>>>
>>>>> During our meeting in Montreal last month, I presented a backgrounder
>>>>> on supporting Linux IMA (file integrity measurement) on NFS.
>>>>>
>>>>> A stumbling block to forward progress of the IMA-on-NFS specification
>>>>> is the lack of any standard describing IMA. You recommended reaching
>>>>> out to the Linux IMA community to inquire if they had plans for
>>>>> standardizing IMA. I have done this:
>>>>>
>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spi
>>> nics.net%2Flists%2Flinux-
>>> integrity%2Fmsg03399.html&amp;data=02%7C01%7Cttalpey%40microsoft.co
>>> m%7C18f04391586c4fcee43308d60d21a54e%7C72f988bf86f141af91ab2d7cd
>>> 011db47%7C1%7C0%7C636710835491618174&amp;sdata=Up9RBEFvcwXzx9
>>> hcDCBnYO3U1usX4MEwHlOZGbFZ83s%3D&amp;reserved=0
>>>>>
>>>>> And received no response. I conclude that there is no active effort
>>>>> and perhaps no desire to standardize Linux IMA.
>>>>
>>>> I THINK what we're talking about here, is a stable reference for draft-ietf-
>>> nfsv4-integrity-measurement to point to. Does that sound right?
>>>
>>> Yes, that was the problem described in Montreal.
>>>
>>>
>>>> I'd like to better understand what reference is available - whether it is
>>>> 	• a versioned description with a stable URL
>>>> 	• an unversioned description
>>>> 	• "the code is in github, good luck"
>>>> 	• or some variation along that spectrum
>>>
>>> There is a wiki with a white paper, and there is what
>>> is implemented in Linux.
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourcefor
>>> ge.net%2Fp%2Flinux-
>>> ima%2Fwiki%2FHome%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com
>>> %7C18f04391586c4fcee43308d60d21a54e%7C72f988bf86f141af91ab2d7cd01
>>> 1db47%7C1%7C0%7C636710835491618174&amp;sdata=iIaZX2iTXbmTvIqGuz
>>> OTJ97Zm7Sz6Y6MaWezWZA9vj0%3D&amp;reserved=0
>>>
>>> So, some from row B and some from row C. And some man
>>> pages. It's a practical implementation, not something
>>> that was conceived by standard and later implemented.
>>>
>>> However, all the participating filesystem needs to do
>>> is store some security metadata. So I would like the
>>> NFS pieces to be entirely agnostic to the metadata
>>> format, and instead focus on:
>>>
>>> a) how to find this metadata
>>> b) how large it can be
>>> c) how to protect it in-transit
>>> d) how to authorize access and updates to it
>>>
>>>
>>>> I think having a stable reference matters more than something being a
>>> "standard", from our perspective.
>>>
>>> We could cite the URL where the white paper resides, as
>>> an Informative reference, but I'm not certain that is a
>>> "stable" URL. Maybe the wiki is stable enough?
>>>
>>>
>>>>> Therefore I propose the following changes to
>>>>> draft-ietf-nfsv4-integrity-measurement:
>>>>>
>>>>> - Replace all specific mention of IMA with general discussion of
>>>>>    purpose and use cases
>>>>> - Rename the new attributes with non-specific names; for example
>>>>>    fattr4_signature_content, fattr4_signature_attributes, and
>>>>>    fattr_signature_attrlist
>>>>> - REQUIRE that the material stored in the first two attributes is
>>>>>    self-describing, such that the integrity measurement subsystems
>>>>>    on NFS endpoints can properly interpret and utilize their content
>>>>
>>>> So, is the goal here to be resilient to changes in IMA, or to be resilient to
>>> replacing IMA with something else?
>>>
>>> Mostly the former goal. The latter is hypothetical at this
>>> point, but possible down the road.
>>>
>>>
>>>>> Do you feel this is adequate for the purposes of standardization? Are
>>>>> there other approaches you would like me to consider?
>>>>
>>>> I'd only be looking for some way to achieve interoperation, so I'd be listening
>>> for feedback from people who will implement this and deploy this mechanism.
>>>
>>> Fair enough.
>>>
>>> The issue of interoperation is IMA's problem: they need to
>>> be able to add/remove features while remaining compatible
>>> with what's already in on-disk filesystems, as their vision
>>> of IMA evolves. IOW they already have to solve this problem
>>> with local filesystems.
>>>
>>>
>>>> I hope that's helpful!
>>>>
>>>> Spencer (D)
>>>>
>>>>> Comments/suggestions from the cheap seats (tm David Black) also welcome.
>>>>>
>>>>> --
>>>>> Chuck Lever
>>>
>>> --
>>> Chuck Lever
>>>
>>>
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
>>> .org%2Fmailman%2Flistinfo%2Fnfsv4&amp;data=02%7C01%7Cttalpey%40micr
>>> osoft.com%7C18f04391586c4fcee43308d60d21a54e%7C72f988bf86f141af91a
>>> b2d7cd011db47%7C1%7C0%7C636710835491628183&amp;sdata=NQQdpaw
>>> GC19QWioBOPkj2O7SnLlvweZvYSNhsLEt1MU%3D&amp;reserved=0
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>