| Network File System Version 4 | C. Lever |
| Internet-Draft | Oracle |
| Intended status: Standards Track | March 27, 2019 |
| Expires: September 28, 2019 |
Integrity Measurement for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-04
This document specifies an OPTIONAL extension to NFS version 4 minor version 2 that enables Linux Integrity Measurement Architecture metadata (IMA) to be conveyed between NFS version 4.2 servers and clients. Integrity measurement authenticates the creator of a file's content and helps guarantee the content's integrity end-to-end from creation to use.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The security of software distribution systems is complex and challenging, especially as software distribution has become increasingly decentralized. An end administrator needs to trust that she is running executables just as they are supplied by a software vendor; in other words, that they have not been modified by malicious actors, contracted system administration services, or broken hardware or software. Software vendors want a guarantee that customer-installed executables that fall under support contracts have similarly not been modified.
There already exist mechanisms that protect file data during certain portions of a file's life cycle:
A more extensive mechanism is needed to guarantee that no modification of a particular file has occurred since it was created, perhaps even after several generations of copies have been made of the file's content.
The Linux Integrity Measurement Architecture (IMA) provides assurance that the content of files is unaltered and authentic to what was originally written to those files. The primary goal is to detect when a remote attacker, a local attacker, or unintentional platform behavior has modified the content of a file either in transit or at rest.
A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of the last modifier of a file's content and serves as a strong check of the content's integrity. For the purposes of this document, we refer to this hash as "IMA metadata". Such metadata is generated and signed by a trusted authority and then associated with each file using special tools.
Each hash and its signature are verified as the file's content is read into memory immediately before it is used. If verification fails, access to the file's content is prevented. A security module separate from the file system specifies the format of the metadata, measures file content, and enforces a policy for determining when file content is safe to use on the local system. For the purposes of this document, we refer to this module as the "integrity assessor" and the policy it uses as the "appraisal policy".
Appraisal is typically performed at the point of content use. The file and storage system play no part in measurement or appraisal. The file system acts only as a conduit by which IMA metadata and file content move between storage on an NFS server and the integrity assessor module on the host where that content is to be used.
NFS peers accessing a set of shared files must all agree on the IMA metadata format. The format is specified by the integrity assessor module and is therefore not described in this document. The protocol extension in this document enables the storage and use of IMA metadata so that measurement and appraisal can occur at point-of-use on NFS clients. The extension does not provide a full assessment mechanism.
A Trusted Platform Module can seal key material used to sign and verify file content. Distributing and protecting such key material is outside the scope of the extension specified in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This document specifies an OPTIONAL extension to NFS version 4 minor version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS version 4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with NFS version 4.2 clients and servers that are aware of the extension, whether or not they support it.
Because [RFC7862] does not define NFS version 4.2 as non-extensible, [RFC8178] treats it as an extensible minor version. Therefore this Standards Track RFC extends NFS version 4.2 but does not update [RFC7862] or [RFC7863].
<CODE BEGINS> sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' <CODE ENDS>
Section 4.1 contains a description of an extension to the NFS version 4.2 protocol, expressed in the External Data Representation (XDR) language [RFC4506]. This description is provided in a way that makes it simple to extract into ready-to-compile form. The reader can apply the following sed script to this document to produce a machine-readable XDR description of the extension.
<CODE BEGINS>
sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
< ima-extension.txt > ima.x
<CODE ENDS>
That is, if this document is in a file called "ima-extension.txt" then the reader can do the following to extract an XDR description file:
Once that extraction is done, these added lines need to be inserted into an appropriate base XDR of the generated XDR from [RFC7863] together with XDR from any additional extensions to be recognized by the implementation. This will result in a ready-to-compile XDR file.
This section defines a new data type to encapsulate and a new OPTIONAL attribute to access and update IMA metadata associated with a particular file.
To enable a single IMA metadata payload to be retrieved or updated via a single RPC, and to constrain the transport resources required for the operations defined in this section, the length of IMA metadata MUST NOT exceed 4096 bytes in length.
When an NFS version 4.2 server does not recognize, or does recognize but does not support, this new attribute, the server responds in accordance with the requirements specified in Section 4.3 of [RFC8178].
<CODE BEGINS> /// /* /// * Copyright (c) 2019 IETF Trust and the person identified /// * as author of the code. All rights reserved. /// * /// * The author of the code is: C. Lever /// */ /// /// %/* /// % * New For Linux IMA support /// % */ /// opaque ima_data<4096>; /// /// const FATTR4_LINUX_IMA = XXX; /* to be assigned */ <CODE ENDS>
An NFS version 4.2 client stores IMA metadata by sending a SETATTR operation that specifies the FATTR4_LINUX_IMA attribute, targeting the file object associated with the metadata to be stored. This attribute completely replaces any previous one.
To remove IMA metadata from a file, the client sends a FATTR4_LINUX_IMA attribute whose length is zero. Modifying the file in any other way MUST NOT alter or remove FATTR4_LINUX_IMA attributes.
When a SETATTR is presented to an NFS version 4.2 server with a credential that is not authorized to replace a FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_ACCESS.
When a SETATTR is presented to an NFS version 4.2 server with a fattr4_linux_ima field whose length is larger than 4096 bytes, the server MUST respond with NFS4ERR_INVAL.
When a SETATTR is presented to an NFS version 4.2 server and the target object resides in a file system which supports FATTR4_LINUX_IMA but the object itself does not support the FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_WRONGTYPE.
When a SETATTR is presented to an NFS version 4.2 server but the target object resides in a file system which does not support the FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_ATTRNOTSUPP.
A detailed description of the SETATTR operation can be found in Section 18.30 of [RFC5661].
An NFS version 4.2 client retrieves IMA metadata by retrieving the FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying the file handle of the file object associated with the metadata to be retrieved. This information may have been computed and signed previously on this client or by some other agent.
When a GETATTR is presented to an NFS version 4.2 server and the target object resides in a file system which supports the FATTR4_LINUX_IMA attribute but the object does not support the FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_WRONGTYPE.
When a GETATTR is presented to an NFS version 4.2 server but the target object resides in a file system which does not support FATTR4_LINUX_IMA, this does not result in an error and the FATTR4_FILE_PROVENANCE attribute bit is cleared in the server's response.
Otherwise, if the target object supports FATTR4_LINUX_IMA and there is no IMA metadata is available for the target object, the server returns a FATTR4_LINUX_IMA attribute whose length is zero.
Integrity assessment occurs after file content has been delivered but immediately before that content is to be used. To enable integrity assessment on NFS clients to verify IMA metadata, NFS version 4.2 servers should not prevent access to file content if they have a local appraisal policy and it indicates that integrity verification has failed.
A detailed description of the GETATTR operation can be found in Section 18.7 of [RFC5661].
To aid the discussion in this section, we define a few handy terms:
In addition, there are intermediate modes of operation on participating peers:
Once a file is written, IMA metadata is generated and signed by an appropriate trust authority. Using the OPTIONAL extension specified in this document, the information can be associated with a file on either a full-function server or client using a tool with appropriate privileges that writes IMA metadata to the shared file system. When using a store-only server, only a full-function client can place IMA metadata in the shared file system.
Typically, once IMA metadata is associated with a file, the file's content is essentially immutable, even if the file has write permissions. This is because changing the content without updating the associated IMA metadata will make the content inaccessible, depending on the appraisal policy in effect. Thus updating the file content usually requires generating fresh IMA metadata.
A participating server should ensure that modifications to IMA metadata are done only by appropriately authorized agents. Such agents usually include only agents with super-user privileges. The NFS server MAY confirm that the new IMA metadata actually verifies the file content correctly before storing it.
Because the protocol extension described herein is OPTIONAL, clients and servers that support it must necessarily interact with clients and servers that do not support it. To set the stage for a discussion of interactions that might occur, consider the following possible simple appraisal policies that might be adopted by an integrity assessment module:
Given the above example policies and the definitions we provided earlier for participating and non-participating implementations, the following statements are true:
A integrity assessor module on an NFS version 4.2 peer needs to be prepared to deal with IMA metadata it does not recognize or cannot parse. Its policy may treat this case as a appraisal failure.
Note that an NFS version 4.2 server may use a integrity assessor module to prevent access by local users to protected files. To enable NFS version 4.2 clients to do their own assessment, an NFS version 4.2 server should not prevent remote access to participating clients if local integrity assessment fails.
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
The design of the OPTIONAL extension described in this document assumes that all IMA metadata is keyed or otherwise cryptographically signed by a trust authority to prevent unwanted alteration at rest or in transit.
When IMA metadata for a file exists and the end host has adopted an IMA policy, the content of a file is protected from creation to use. Receivers can reliably detect unintentional or malicious alteration of file content by verifying its content using the file's IMA metadata. Additional protection of file content while at rest or in transit on an untrusted network is unnecessary.
Likewise, receivers can also reliably detect unintentional or malicious alteration of IMA metadata that is cryptographically signed, simply by verifying its signature. Additional protection of signed metadata while at rest or in transit on an untrusted network is unnecessary.
Like other mechanisms that protect data integrity during transit, A malicious agent or a network malfunction can create a denial-of-service condition by repeatedly triggering integrity verification failures on NFS version 4.2 clients.
To prevent a malicious denial-of-service attempt by altering IMA metadata at rest, an NFS version 4.2 server can enforce a suitable level of privilege before authorizing a local or remote agent to alter this information. See Section 5.2.1 for more detail.
This document requests no action from IANA.
| [RFC2104] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997. |
| [RFC5662] | Shepler, S., Eisler, M. and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, DOI 10.17487/RFC5662, January 2010. |
| [RFC7861] | Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016. |
The author wishes to thank Mimi Zohar and James Morris for their early review of the concepts in this document, Wim Coekaerts for his encouragement of this work, and Dave Noveck for his work on NFS version 4 extensibility.
The author wishes to acknowledge review comments from Dave Noveck, Craig Everhart, and Bruce Fields which helped to make this a better document.
The XDR extraction conventions were first described by the authors of the NFS version 4.1 XDR specification [RFC5662]. Herbert van den Bergh suggested the replacement sed script used in this document.
Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their support.