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
Abstract
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.
Status of This Memo
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 Notice
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
Lever Expires September 28, 2019 [Page 1]
Internet-Draft IMA over NFS March 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Linux Integrity Measurement Architecture . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Extension Considerations . . . . . . . . . . . . . . 4
3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 4
4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 5
4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 5
4.2. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 6
4.3. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 8
5.2.1. Authorizing Updates to IMA Metadata . . . . . . . . . 8
5.3. Interaction With Non-Participating Implementations . . . 8
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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:
o Whole file system checksumming can verify so-called Golden Master
installation media before it is used to install the software it
contains.
Lever Expires September 28, 2019 [Page 2]
Internet-Draft IMA over NFS March 2019
o File or block integrity mechanisms can protect data at rest on
storage servers.
o For a distributed file system such as NFS, transport layer
security or a GSS integrity service (as described in [RFC7861])
can protect data while it traverses a network between a storage
server and a client.
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.
1.1. The Linux Integrity Measurement Architecture
The Linux Integrity Measurement Architecture (IMA) [1] 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
Lever Expires September 28, 2019 [Page 3]
Internet-Draft IMA over NFS March 2019
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 [2] 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.
2. Requirements Language
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.
3. Protocol Extension Considerations
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].
3.1. XDR Extraction
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'
<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:
Lever Expires September 28, 2019 [Page 4]
Internet-Draft IMA over NFS March 2019
<CODE BEGINS>
sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
< ima-extension.txt > ima.x
<CODE ENDS>
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.
4. Managing IMA Metadata on NFS Files
4.1. XDR Definition
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>
Lever Expires September 28, 2019 [Page 5]
Internet-Draft IMA over NFS March 2019
4.2. Storing IMA Metadata
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].
4.3. Retrieving IMA Metadata
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.
Lever Expires September 28, 2019 [Page 6]
Internet-Draft IMA over NFS March 2019
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].
5. Operation
5.1. Terminology
To aid the discussion in this section, we define a few handy terms:
o A "participating client" is an NFS version 4.2 client that
supports the OPTIONAL extension described in this document and
employs a integrity assessor module.
o A "non-participating client" is an NFS version 4.2 client that
does not support the OPTIONAL extension described in this document
or does not employ a integrity assessor module.
o A "participating server" is an NFS version 4.2 server that
supports the OPTIONAL extension described in this document and its
shared filesystems can store IMA metadata. A participating server
is not required to implement an integrity assessor module.
o A "non-participating server" is an NFS version 4.2 server that
does not support the OPTIONAL extension described in this document
or its shared filesystems are not capable of storing IMA metadata.
In addition, there are intermediate modes of operation on
participating peers:
o A "full-function client" is a participating client that supports
updating remote IMA metadata.
Lever Expires September 28, 2019 [Page 7]
Internet-Draft IMA over NFS March 2019
o A "fetch-only client" is a participating client that does not
support modifying IMA metadata on a participating server.
o A "full-function server" is a participating server that supports
updating IMA metadata that resides on local shared file systems.
o A "store-only server" is a participating server where there is
only remote access to IMA metadata.
5.2. Instantiating IMA Metadata
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.
5.2.1. Authorizing Updates to 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.
5.3. Interaction With Non-Participating Implementations
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:
Strict: Access is prevented to a file's content if the file has no
IMA metadata or if the extant IMA metadata fails to verify the
file content. Otherwise access to the file's content is not
prevented.
Lever Expires September 28, 2019 [Page 8]
Internet-Draft IMA over NFS March 2019
Audit: Access to a file's content is never prevented. Warnings are
reported when a file has no IMA metadata or when extant IMA
metadata fails to verify the file's content.
Disabled: Access to file content is never prevented and IMA metadata
is ignored.
Given the above example policies and the definitions we provided
earlier for participating and non-participating implementations, the
following statements are true:
o A participating client that uses the Disabled policy is equivalent
to a non-participating client.
o A non-participating client never prevents access to file content
on a participating server.
o A participating client using the Strict policy never allows access
to files stored on a non-participating server.
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.
6. Implementation Status
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.
Lever Expires September 28, 2019 [Page 9]
Internet-Draft IMA over NFS March 2019
6.1. Linux NFS server and client
Organization: The Linux Foundation
URL: https://www.kernel.org
Maturity: Prototype software based on early versions of this
document.
Coverage: The bulk of this specification is implemented.
Licensing: GPLv2
Implementation experience: No comments from implementors.
7. Security Considerations
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.
Lever Expires September 28, 2019 [Page 10]
Internet-Draft IMA over NFS March 2019
8. IANA Considerations
This document requests no action from IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR)
Description", RFC 7863, DOI 10.17487/RFC7863, November
2016, <https://www.rfc-editor.org/info/rfc7863>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>.
Lever Expires September 28, 2019 [Page 11]
Internet-Draft IMA over NFS March 2019
9.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description",
RFC 5662, DOI 10.17487/RFC5662, January 2010,
<https://www.rfc-editor.org/info/rfc5662>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>.
9.3. URIs
[1] http://downloads.sf.net/project/linux-ima/linux-ima/
Integrity_overview.pdf
[2] https://trustedcomputinggroup.org/wp-content/uploads/Trusted-
Platform-Module-Summary_04292008.pdf
Acknowledgments
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.
Lever Expires September 28, 2019 [Page 12]
Internet-Draft IMA over NFS March 2019
Author's Address
Charles Lever
Oracle Corporation
United States of America
Email: chuck.lever@oracle.com
Lever Expires September 28, 2019 [Page 13]