draft-ietf-nfsv4-integrity-measurement-04.txt   draft-ietf-nfsv4-integrity-measurement-05.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track March 27, 2019 Intended status: Standards Track June 6, 2019
Expires: September 28, 2019 Expires: December 8, 2019
Integrity Measurement for Network File System version 4 Integrity Measurement for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-04 draft-ietf-nfsv4-integrity-measurement-05
Abstract Abstract
This document specifies an OPTIONAL extension to NFS version 4 minor This document specifies an OPTIONAL extension to NFS version 4 minor
version 2 that enables Linux Integrity Measurement Architecture version 2 that enables Linux Integrity Measurement Architecture
metadata (IMA) to be conveyed between NFS version 4.2 servers and metadata (IMA) to be conveyed between NFS version 4.2 servers and
clients. Integrity measurement authenticates the creator of a file's clients. Integrity measurement authenticates the creator of a file's
content and helps guarantee the content's integrity end-to-end from content and helps guarantee the content's integrity end-to-end from
creation to use. creation to use.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2019. This Internet-Draft will expire on December 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Linux Integrity Measurement Architecture . . . . . . 3 1.1. The Linux Integrity Measurement Architecture . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1.1.1. IMA Metadata . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Extension Considerations . . . . . . . . . . . . . . 4 1.1.2. Creating and Verifying IMA Metadata . . . . . . . . . 4
3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 4 1.1.3. Distributing and Protecting Keying Material . . . . . 5
4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 5 1.1.4. Using IMA to Protect NFS Files . . . . . . . . . . . 5
4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4.2. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 6 3. Protocol Extension Considerations . . . . . . . . . . . . . . 5
4.3. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 6 3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 6
5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 6
5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 8 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) . . . . . . . . 7
5.2.1. Authorizing Updates to IMA Metadata . . . . . . . . . 8 4.2. Detecting support for IMA Metadata . . . . . . . . . . . 7
5.3. Interaction With Non-Participating Implementations . . . 8 4.2.1. Reporting Server-Side IMA Appraisal Failures . . . . 7
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 4.3. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 8
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 10 4.3.1. Sending IMA Metadata When Creating a New Object . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.3.2. Authorizing Updates to IMA Metadata . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.4. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Interaction With Non-Participating Implementations . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The security of software distribution systems is complex and The security of software distribution systems is complex and
challenging, especially as software distribution has become challenging, especially as software distribution has become
increasingly decentralized. An end administrator needs to trust that increasingly decentralized. An end administrator needs to trust that
she is running executables just as they are supplied by a software she is running executables just as they are supplied by a software
vendor; in other words, that they have not been modified by malicious vendor; in other words, that they have not been modified by malicious
actors, contracted system administration services, or broken hardware actors, contracted system administration services, or broken hardware
or software. Software vendors want a guarantee that customer- or software. Software vendors want a guarantee that customer-
skipping to change at page 3, line 20 skipping to change at page 3, line 29
can protect data while it traverses a network between a storage can protect data while it traverses a network between a storage
server and a client. server and a client.
A more extensive mechanism is needed to guarantee that no A more extensive mechanism is needed to guarantee that no
modification of a particular file has occurred since it was created, modification of a particular file has occurred since it was created,
perhaps even after several generations of copies have been made of perhaps even after several generations of copies have been made of
the file's content. the file's content.
1.1. The Linux Integrity Measurement Architecture 1.1. The Linux Integrity Measurement Architecture
The Linux Integrity Measurement Architecture (IMA) [1] provides The Linux Integrity Measurement Architecture (IMA) [SAILER] provides
assurance that the content of files is unaltered and authentic to assurance that the content of a file is unaltered and authentic to
what was originally written to those files. The primary goal is to what was originally written to that file. The goal is to detect when
detect when a remote attacker, a local attacker, or unintentional an attacker, unintentional platform behavior, or local tinkering has
platform behavior has modified the content of a file either in modified the content of a file, either in transit or at rest.
transit or at rest.
A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of This is done by separately storing metadata about a file's content
the last modifier of a file's content and serves as a strong check of and then using that metadata to verify the content before it is used.
the content's integrity. For the purposes of this document, we refer Verification of the content is entirely independent of the file
to this hash as "IMA metadata". Such metadata is generated and system. File systems, both local and remote, act simply as storage
signed by a trusted authority and then associated with each file for both the content and the metadata, both of which are opaque to
using special tools. the storage subsystem.
Each hash and its signature are verified as the file's content is An informative description of this mechanism is presented in the
read into memory immediately before it is used. If verification following subsections to provide context for understanding the NFS
fails, access to the file's content is prevented. A security module protocol extension described later in this document. As the file
separate from the file system specifies the format of the metadata, system does not interpret IMA metadata, this description is not
measures file content, and enforces a policy for determining when necessary to implement the extension.
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 1.1.1. IMA Metadata
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 A cryptographically signed hash stored separately from a file's
metadata format. The format is specified by the integrity assessor content serves as a strong check of file content integrity and
module and is therefore not described in this document. The protocol authenticates the identity of the provider of the file's content.
extension in this document enables the storage and use of IMA The signer is verified at time of content use via a web of trust
metadata so that measurement and appraisal can occur at point-of-use commonly provided by PKI or x.509 certificates [RFC4158].
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 The hash is typically computed using either the SHA-1 or SHA-256
verify file content. Distributing and protecting such key material algorithm and is stored as an HMAC [RFC2104]. For the purposes of
is outside the scope of the extension specified in this document. this document, the current document refers to this blob as "IMA
metadata".
The precise format of this metadata is determined by policies set by
the local security administrator; the metadata and its format are
opaque to the mechanisms that store or transport it (i.e., file
systems). The particulars of the PKI and the hash algorithm are
agreed upon out-of-band and recognized by all participating IMA
subsystems.
1.1.2. Creating and Verifying IMA Metadata
In a typical deployment, an authority (such as a software vendor)
computes the hash of a file after its content has been finalized.
The hash is then signed and attached to the file. A web of trust
typically links the signer to the users of the file's content (such
as customers of the software vendor).
Directly before file content is to be used, a security module locally
re-computes the hash of the file content and stores it in a cache.
This step is known as "measurement".
The next step is referred to as "appraisal". The security module
then reads the associated IMA metadata and validates its signature.
If the signature is invalid or the locally computed hash does not
match the stored hash, the security module applies an appraisal
policy. The file may be flagged in an audit log or access to the
file may be denied.
Underlying file and storage systems play no part in measurement or
appraisal. They act only as a conduit by which file content and IMA
metadata move between at-rest storage and the security module on the
host where that content is to be used. Both IMA metadata and file
content are opaque to storage subsystems.
1.1.3. Distributing and Protecting Keying Material
A Trusted Platform Module [1] can seal key material used to sign and
appraise file content. Unprotected keys are not stored in or
distributed via file systems. Distributing and protecting such key
material is outside the scope of the extension specified in this
document.
1.1.4. Using IMA to Protect NFS Files
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 client and server hosts. This mechanism is similar to
NFSv4 Security Labels (specified in [RFC7862] et al). The purpose of
the mechanism defined in the current document is to store security-
related file metadata that is not interpreted by the file system
itself.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Extension Considerations 3. Protocol Extension Considerations
skipping to change at page 5, line 45 skipping to change at page 7, line 15
<CODE BEGINS> <CODE BEGINS>
/// /* /// /*
/// * Copyright (c) 2019 IETF Trust and the person identified /// * Copyright (c) 2019 IETF Trust and the person identified
/// * as author of the code. All rights reserved. /// * as author of the code. All rights reserved.
/// * /// *
/// * The author of the code is: C. Lever /// * The author of the code is: C. Lever
/// */ /// */
/// ///
/// %/* /// %/*
/// % * New For Linux IMA support /// % * New For Integrity Measurement support
/// % */ /// % */
/// opaque ima_data<4096>; /// opaque ima_data4<4096>;
/// ///
/// const FATTR4_LINUX_IMA = XXX; /* to be assigned */ /// const FATTR4_IMA = XXX; /* to be assigned */
///
/// %/*
/// % *New value added to enum nfsstat4
/// % */
/// const NFS4ERR_INTEGRITY = YYYYY; /* to be assigned */
<CODE ENDS> <CODE ENDS>
4.2. Storing IMA Metadata 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY)
An NFS version 4.2 client stores IMA metadata by sending a SETATTR The server rejected this request because a data or metadata integrity
operation that specifies the FATTR4_LINUX_IMA attribute, targeting check failed during its execution.
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 4.2. Detecting support for IMA Metadata
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 An NFS version 4.2 client discovers support for IMA metadata on an
credential that is not authorized to replace a FATTR4_LINUX_IMA NFS version 4.2 server by sending an NFS GETATTR operation that
attribute, the server MUST respond with NFS4ERR_ACCESS. specifies the FATTR4_SUPPORTED_ATTRS attribute and the FATTR4_IMA
attribute. When a server supports IMA metadata, it sets the
FATTR4_IMA attribute bit in the NFS GETATTR bitmask returned in the
reply. Otherwise that bit is clear.
When a SETATTR is presented to an NFS version 4.2 server with a An NFS version 4.2 server MUST NOT return NFS4ERR_INTEGRITY to a
fattr4_linux_ima field whose length is larger than 4096 bytes, the client unless that client has queried the server for IMA metadata
server MUST respond with NFS4ERR_INVAL. support using the above mechanism. The server identifies clients
using their client_id4 for this purpose.
When a SETATTR is presented to an NFS version 4.2 server and the 4.2.1. Reporting Server-Side IMA Appraisal Failures
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 An NFS server that has rigorous integrity checking must somehow
report integrity-related failures to clients. Until now, a server
implementer chose amongst status codes that were available in the
base NFS version 4.2 protocol, typically NFS4ERR_IO or
NFS4ERR_ACCESS, even though these code points have generic meanings
that do not necessarily imply an integrity-related failure.
Once the above FATTR4_SUPPORTED_ATTRS handshake is done, the server
has determined that a client can properly recognize the
NFS4ERR_INTEGRITY status code. In instances where an NFS request
fails due to an integrity-related issue, and the server has
determined that the client recognizes the NFS4ERR_INTEGRITY status
code, the server MAY return NFS4ERR_INTEGRITY for the following
operations: ACCESS, COMMIT, CREATE, GETATTR, GETDEVICELIST, LINK,
LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, READ, READDIR, READLINK,
REMOVE, RENAME, SETATTR, VERIFY, WRITE. The server MUST NOT return
NFS4ERR_INTEGRITY for any other operation.
The NFS4ERR_INTEGRITY status code is useful to inform the client (or
the end user, depending on the client implementation) that access to
the file's content was not blocked because of a permissions setting
but rather because an integrity check failed. This distinction can
guide the user or client towards a recovery action that is
appropriate.
[ cel: this is still an open issue ]
4.3. Storing IMA Metadata
An NFS version 4.2 client stores IMA metadata by sending an NFS
SETATTR operation that specifies the FATTR4_IMA attribute and targets
the file system object associated with the metadata to be stored.
This attribute completely replaces any previous FATTR4_IMA attribute
associated with that object. Modifying an object in any other way
MUST NOT alter or remove FATTR4_IMA attributes.
To remove IMA metadata from an object, the client sends a FATTR4_IMA
attribute whose length is zero.
When an NFS SETATTR is presented to an NFS version 4.2 server with a
credential that is not authorized to replace a FATTR4_IMA attribute,
the server MUST respond with NFS4ERR_ACCESS.
When an NFS SETATTR is presented to an NFS version 4.2 server with an
ima_data4 field whose length is larger than 4096 bytes, the server
MUST respond with NFS4ERR_INVAL.
When an NFS SETATTR is presented to an NFS version 4.2 server and the
target object resides in a file system which supports FATTR4_IMA but
the object itself does not support the FATTR4_IMA attribute, the
server MUST respond with NFS4ERR_WRONGTYPE. For example, if the
server's file system supports associating IMA metadata with regular
files but not with sockets or FIFOs, then the result of an attempt to
associate IMA metadata with a FIFO will be NFS4ERR_WRONGTYPE.
When an NFS SETATTR is presented to an NFS version 4.2 server but the
target object resides in a file system which does not support the target object resides in a file system which does not support the
FATTR4_LINUX_IMA attribute, the server MUST respond with FATTR4_IMA attribute, the server MUST respond with
NFS4ERR_ATTRNOTSUPP. NFS4ERR_ATTRNOTSUPP.
A detailed description of the SETATTR operation can be found in When a client presents an NFS SETATTR that modifies FATTR4_IMA along
with other attributes and the server responds with an error, the
client can retry setting each attribute separately to sort out which
attribute is causing the server to reject the NFS SETATTR operation.
A detailed description of the NFS SETATTR operation can be found in
Section 18.30 of [RFC5661]. Section 18.30 of [RFC5661].
4.3. Retrieving IMA Metadata 4.3.1. Sending IMA Metadata When Creating a New Object
An alternate way to set an attribute is to provide the attribute
during an NFS OPEN(CREATE) operation. Upon creation, an object has
no content to protect. If a client presents an FATTR4_IMA attribute
to an NFS version 4.2 server during NFS OPEN(CREATE), the server MUST
respond with NFS4ERR_INVAL.
4.3.2. Authorizing Updates to IMA Metadata
An NFS version 4.2 server needs to ensure that modifications to IMA
metadata are done only by appropriately authorized agents. Although
access to file content is typically controlled by ACLs and permission
bits, these mechanisms do not apply to IMA metadata. The question of
"who is authorized to modify IMA metadata" is left to local security
policy.
Possible implementations include limiting IMA metadata update
authority to:
Particular users
The server may allow IMA metadata updates only by UID 0 or by a
client's machine principal.
Particular clients
The server may allow IMA metadata updates only from specific
client IP addresses.
File owners
The server may allow IMA metadata updates only by the file's owner
or group owner.
[ cel: this is still an open issue. ]
4.4. Retrieving IMA Metadata
An NFS version 4.2 client retrieves IMA metadata by retrieving the An NFS version 4.2 client retrieves IMA metadata by retrieving the
FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying the FATTR4_IMA attribute via an NFS GETATTR operation, specifying the
file handle of the file object associated with the metadata to be file handle of the object associated with the metadata to be
retrieved. This information may have been computed and signed retrieved.
previously on this client or by some other agent.
When a GETATTR is presented to an NFS version 4.2 server and the The IMA subsystem typically manages its own cache of this metadata to
target object resides in a file system which supports the maintain reasonable performance. The NFS client implementation MUST
FATTR4_LINUX_IMA attribute but the object does not support the always pass retrieval requests for this metadata to the server. This
FATTR4_LINUX_IMA attribute, the server MUST respond with metadata MUST NOT be cached by the NFS client.
NFS4ERR_WRONGTYPE.
When a GETATTR is presented to an NFS version 4.2 server but the When an NFS GETATTR is presented to an NFS version 4.2 server and the
target object resides in a file system which supports the FATTR4_IMA
attribute but the object does not support the FATTR4_IMA attribute,
the server MUST respond with NFS4ERR_WRONGTYPE. For example, if the
server's file system supports associating IMA metadata with regular
files but not named attributes, then the result of an attempt to
retrieve IMA metadata on a named attribute will be NFS4ERR_WRONGTYPE.
When an NFS GETATTR is presented to an NFS version 4.2 server but the
target object resides in a file system which does not support target object resides in a file system which does not support
FATTR4_LINUX_IMA, this does not result in an error and the FATTR4_IMA, this does not result in an error and the FATTR4_IMA
FATTR4_FILE_PROVENANCE attribute bit is cleared in the server's attribute bit is cleared in the server's response.
response.
Otherwise, if the target object supports FATTR4_LINUX_IMA and there Otherwise, if the target object supports FATTR4_IMA and there is no
is no IMA metadata is available for the target object, the server IMA metadata is available for the target object, the server returns a
returns a FATTR4_LINUX_IMA attribute whose length is zero. FATTR4_IMA attribute whose length is zero.
Integrity assessment occurs after file content has been delivered but When a client presents an NFS GETATTR that retrieves FATTR4_IMA along
immediately before that content is to be used. To enable integrity with other attributes and the server responds with an error, the
assessment on NFS clients to verify IMA metadata, NFS version 4.2 client can retry by retrieving each attribute separately to sort out
servers should not prevent access to file content if they have a which attribute is causing the server to reject the NFS GETATTR
local appraisal policy and it indicates that integrity verification operation.
has failed.
A detailed description of the GETATTR operation can be found in A detailed description of the NFS GETATTR operation can be found in
Section 18.7 of [RFC5661]. Section 18.7 of [RFC5661].
5. Operation 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY)
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 The NFS VERIFY and NVERIFY operations, described in Sections 18.31
supports the OPTIONAL extension described in this document and and 18.15 of [RFC5661] respectively, permit a client to add a fence
employs a integrity assessor module. in an NFS COMPOUND where, if a provided FATTR4 attribute does or does
not match, the server can force processing of that COMPOUND to stop.
The FATTR4_IMA attribute is a valid choice for these operations.
o A "non-participating client" is an NFS version 4.2 client that The server MUST use a simple byte comparison to evaluate whether the
does not support the OPTIONAL extension described in this document client-provided FATTR4_IMA matches the FATTR4_IMA attribute
or does not employ a integrity assessor module. associated with the target object. If the server has a local IMA
implementation, it MAY prevent the use of the local FATTR4_IMA
attribute value for the purpose of this comparison (via EVM
protection). If the client has indicated support for IMA metadata,
the server MUST respond with NFS4ERR_INTEGRITY. Otherwise it MUST
respond with NFS4ERR_ACCESS.
o A "participating server" is an NFS version 4.2 server that 5. Deployment Examples
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 5.1. Terminology
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 Because the protocol extension described in this document is
participating peers: OPTIONAL, clients and servers that support it will necessarily
interact with clients and servers that do not support it. To aid the
discussion in this section, we define the following terms:
o A "full-function client" is a participating client that supports Integrity Assessor: A security module separate from the file system
updating remote IMA metadata. that appraises file content based on a policy and IMA measurement
results.
o A "fetch-only client" is a participating client that does not Participating Client: An NFS version 4.2 client that employs a
support modifying IMA metadata on a participating server. integrity assessor, supports the OPTIONAL extension described in
this document, and indicates this support to servers using the
handshake described in Section 4.2.
o A "full-function server" is a participating server that supports Non-participating Client: An NFS client that does not support the
updating IMA metadata that resides on local shared file systems. OPTIONAL extension described in this document.
o A "store-only server" is a participating server where there is Participating Server: An NFS version 4.2 server that supports the
only remote access to IMA metadata. OPTIONAL extension described in this document, indicates this
support to clients using the handshake described in Section 4.2,
and its shared file systems can store IMA metadata. A
participating server is not required to implement an integrity
assessor.
5.2. Instantiating IMA Metadata Non-participating Server: An NFS server that does not support the
OPTIONAL extension described in this document.
Once a file is written, IMA metadata is generated and signed by an In addition, there are intermediate modes of operation on
appropriate trust authority. Using the OPTIONAL extension specified participating peers:
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 Full-function Client: A participating client that can modify IMA
content is essentially immutable, even if the file has write metadata via NFS.
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 Fetch-only Client: A participating client that does not support
modifying IMA metadata on a participating server.
A participating server should ensure that modifications to IMA Full-function Server: A participating server that has a local user
metadata are done only by appropriately authorized agents. Such execution environment and supports updating IMA metadata that
agents usually include only agents with super-user privileges. The resides on local shared file systems.
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 Store-only Server: A participating server where there is only remote
access to file content and IMA metadata.
Because the protocol extension described herein is OPTIONAL, clients Lastly, we provide the following possible simple appraisal policies
and servers that support it must necessarily interact with clients that might be applied by an integrity assessor:
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 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 IMA metadata or if the extant IMA metadata fails to verify the
file content. Otherwise access to the file's content is not file content. Otherwise access to the file's content is not
prevented. prevented.
Audit: Access to a file's content is never prevented. Warnings are Audit: Access to a file's content is never prevented. Warnings are
reported when a file has no IMA metadata or when extant IMA reported when a file has no IMA metadata or when extant IMA
metadata fails to verify the file's content. metadata fails to verify the file's content.
Disabled: Access to file content is never prevented and IMA metadata Disabled: Access to file content is never prevented and IMA metadata
is ignored. is ignored.
Given the above example policies and the definitions we provided 5.2. Instantiating IMA Metadata
earlier for participating and non-participating implementations, the
Once a file is written and closed, a specialized tool generates and
signs the IMA metadata and then writes it to the file system. The
tool can be used on a full-function client to sign files on a
participating server. Or, the tool can be used on a full-function
server to sign local files. The IMA metadata is then visible to
participating clients and local users on the server (if there are
any).
Typically, once IMA metadata is associated with a file, the file's
content is essentially immutable, even if the file's permissions
settings permit writing to it. This is because changing the content
without updating the associated IMA metadata will make the file's
content inaccessible, depending on the appraisal policy in effect.
Updating the file content requires generating fresh IMA metadata to
prevent subsequent IMA appraisal failures.
5.3. Interaction With Non-Participating Implementations
Given the example policies and definitions we provided earlier, the
following statements are true: following statements are true:
o A participating client that uses the Disabled policy is equivalent o A participating client that uses the Disabled policy is equivalent
to a non-participating client. to a non-participating client, except that a participating server
is allowed to respond with NFS4ERR_INTEGRITY to a participating
client.
o A non-participating client never prevents access to file content o A non-participating client never prevents access to file content
on a participating server. on a participating server, but a participating server that has a
local integrity assessor may prevent access to a non-participating
client.
o A participating client using the Strict policy never allows access o A participating client using the Strict policy never allows access
to files stored on a non-participating server. to files stored on a non-participating server.
A integrity assessor module on an NFS version 4.2 peer needs to be An integrity assessor on a participating NFS version 4.2 peer needs
prepared to deal with IMA metadata it does not recognize or cannot to be prepared to deal gracefully with IMA metadata it does not
parse. Its policy may treat this case as a appraisal failure. 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 It is not required for an NFS version 4.2 server to implement an
module to prevent access by local users to protected files. To integrity assessor. However, some servers, such as the Linux NFS
enable NFS version 4.2 clients to do their own assessment, an NFS server, do just that, applying local IMA policy to both local and
version 4.2 server should not prevent remote access to participating remote file accesses.
clients if local integrity assessment fails.
If an appraisal failure occurs during a remote access, the server
responds to a non-participating client with NFS4ERR_ACCESS or
NFS4ERR_IO. The server's local policy can decide that a
participating client sees NFS4ERR_INTEGRITY, or rather that the
server allows access to the file content and IMA metadata so that the
client's own IMA policies can be fully applied.
[ cel: Permitting remote access to files that fail a local integrity
check is still an open issue. ]
6. Implementation Status 6. Implementation Status
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. RFCs.
skipping to change at page 10, line 22 skipping to change at page 14, line 22
document. document.
Coverage: The bulk of this specification is implemented. Coverage: The bulk of this specification is implemented.
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
7. Security Considerations 7. Security Considerations
The design of the OPTIONAL extension described in this document The design of the NFS extension described in this document assumes
assumes that all IMA metadata is keyed or otherwise cryptographically that all IMA metadata is cryptographically signed to prevent unwanted
signed by a trust authority to prevent unwanted alteration at rest or alteration at rest or in transit.
in transit.
When IMA metadata for a file exists and the end host has adopted an When IMA metadata for a file exists and the end host has an IMA
IMA policy, the content of a file is protected from creation to use. assessor, the content of a file is protected from creation to use.
Receivers can reliably detect unintentional or malicious alteration Receivers can reliably detect unintentional or malicious alteration
of file content by verifying its content using the file's IMA of file content by verifying its content using the file's IMA
metadata. Additional protection of file content while at rest or in metadata. Additional protection of file content while at rest or in
transit on an untrusted network is unnecessary. transit on an untrusted network is unnecessary.
Likewise, receivers can also reliably detect unintentional or Likewise, receivers can also reliably detect unintentional or
malicious alteration of IMA metadata that is cryptographically malicious alteration of IMA metadata that is cryptographically
signed, simply by verifying its signature. Additional protection of signed, simply by verifying its signature. Additional protection of
signed metadata while at rest or in transit on an untrusted network signed metadata while at rest or in transit on an untrusted network
is unnecessary. is unnecessary.
Like other mechanisms that protect data integrity during transit, A Like other mechanisms that protect data integrity during transit, a
malicious agent or a network malfunction can create a denial-of- malicious agent or a network malfunction can create a denial-of-
service condition by repeatedly triggering integrity verification service condition by repeatedly triggering integrity verification
failures on NFS version 4.2 clients. failures on NFS version 4.2 clients.
To prevent a malicious denial-of-service attempt by altering IMA To prevent a malicious denial-of-service attempt by altering IMA
metadata at rest, an NFS version 4.2 server can enforce a suitable metadata at rest, an NFS version 4.2 server can enforce a suitable
level of privilege before authorizing a local or remote agent to level of privilege before authorizing a local or remote agent to
alter this information. See Section 5.2.1 for more detail. alter this information. See Section 4.3.2 for more detail.
8. IANA Considerations 8. IANA Considerations
This document requests no action from IANA. This document has no IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 12 skipping to change at page 16, line 12
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>. <https://www.rfc-editor.org/info/rfc8178>.
9.2. Informative References 9.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158,
DOI 10.17487/RFC4158, September 2005,
<https://www.rfc-editor.org/info/rfc4158>.
[RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description", External Data Representation Standard (XDR) Description",
RFC 5662, DOI 10.17487/RFC5662, January 2010, RFC 5662, DOI 10.17487/RFC5662, January 2010,
<https://www.rfc-editor.org/info/rfc5662>. <https://www.rfc-editor.org/info/rfc5662>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861, Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>. November 2016, <https://www.rfc-editor.org/info/rfc7861>.
9.3. URIs [SAILER] Sailer, R., Zhang, X., Jaeger, T., and L. van Doorn,
"Design and Implementation of a TCG-based Integrity
Measurement Architecture", Proceedings of the 13th USENIX
Security Symposium, August 2004.
[1] http://downloads.sf.net/project/linux-ima/linux-ima/ 9.3. URIs
Integrity_overview.pdf
[2] https://trustedcomputinggroup.org/wp-content/uploads/Trusted- [1] https://trustedcomputinggroup.org/wp-content/uploads/Trusted-
Platform-Module-Summary_04292008.pdf Platform-Module-Summary_04292008.pdf
Acknowledgments Acknowledgments
The author wishes to thank Mimi Zohar and James Morris for their The author wishes to thank Mimi Zohar and James Morris for their
early review of the concepts in this document, Wim Coekaerts for his early review of the concepts in this document, Wim Coekaerts for his
encouragement of this work, and Dave Noveck for his work on NFS encouragement of this work, and Dave Noveck for his work on NFS
version 4 extensibility. version 4 extensibility.
The author wishes to acknowledge review comments from Dave Noveck, The author wishes to acknowledge review comments from Dave Noveck,
 End of changes. 61 change blocks. 
191 lines changed or deleted 374 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/