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

[Chuck Lever <[e-mail]>]

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.

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.

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