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

[Chuck Lever <[e-mail]>]

> On Aug 29, 2018, at 7:48 AM, Tom Talpey <[e-mail]> wrote:
> 
> 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.

It was a good question! And I'm happy to repeat some of the
draft and PowerPoint here for folks who missed Montreal.


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

As David pointed out, perhaps different terminology would
help distinguish the purpose of this new mechanism from
typical at-rest integrity (a la ZFS) and in-transit integrity
(a la krb5i). I'll use the term "measurement metadata" for
the moment.


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

Let's consider an example of how IMA works today.

A software vendor wants to provide its own version of the
"ping" program. To avoid malicious tampering, it computes an
HMAC hash of the executable file, and signs the hash. That
signed hash accompanies the executable file to the vendor's
customers. This is the measurement metadata.

When a customer installs "ping" on a filesystem that supports
IMA, the measurement metadata is saved as an extended attri-
bute of the file storing the "ping" executable, similar to
any security label.

Before executing "ping", the customer's operating system
pulls the "ping" executable into its page cache. The IMA
module reads the measurement metadata. It verifies the signa-
ture against the software vendor's public certificate. It
verifies the hash by recomputing the HMAC on the copy of
"ping" in the page cache.

If all checks out, "ping" is allowed to execute normally. If
not, the operating system prevents execution.

Measurement metadata is typically provided by someone else,
not by local agents. And this metadata is frequently auth-
enticated.


> Are they actually looking to use NFS?

Cloud operators that support Linux provide the guest's root
filesystem, where most of the guest OS's executables reside,
using ext4 on a virtual disk (or via iSCSI). ext4 supports
IMA. Cloud operators want to use that to guarantee to
customers that they are getting OEM software components that
have not been tampered with.

Some operators would like to use NFS for guest root file-
systems. They'd like to have the same support for measure-
ment in that environment as they have with ext4.

Conversely, a cloud operator may want to provide its own
particular versions of some executables, in which case it
can hash and sign them and provide the customers with its
public cert for verification.


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

The application that uses measurement metadata is the IMA
subsystem, which resides in the kernel with the filesystem
implementation, to be clear. The measurement subsystem is a
security module that is separate from the filesystem. No
part of any filesystem implementation alters or interprets
measurement metadata.

If tripwire is similar to IMA, then perhaps we are really
talking about a class of applications. Each member of that
class might have their own metadata format, much like the
various parties that might want to write into an NFSv4
security label, which oddly enough is also an opaque array
of bytes that is not interpreted by NFS.


> 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
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever