Integrity Measurement for Network File System version 4
Oracle CorporationUnited States of Americachuck.lever@oracle.com
Transport
Network File System Version 4
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.
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:
Whole file system checksumming can verify so-called
Golden Master installation media before it is used
to install the software it contains.
File or block integrity mechanisms can protect data
at rest on storage servers.
For a distributed file system such as NFS,
transport layer security or a GSS integrity service
(as described in
)
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.
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
)
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
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
,
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
does not define NFS version 4.2 as non-extensible,
treats it as an extensible minor version.
Therefore this Standards Track RFC extends NFS version 4.2
but does not update
or
.
contains a description of an extension to the NFS version 4.2 protocol,
expressed in the External Data Representation (XDR) language
.
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.
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
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
.
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
.
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
.
To aid the discussion in this section, we define a few handy terms:
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.
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.
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.
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:
A "full-function client" is a participating client that
supports updating remote IMA metadata.
A "fetch-only client" is a participating client that
does not support modifying IMA metadata
on a participating server.
A "full-function server" is a participating server that
supports updating IMA metadata
that resides on local shared file systems.
A "store-only server" is a participating server where
there is only remote access to 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.
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:
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.
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.
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:
A participating client that uses the Disabled policy
is equivalent to
a non-participating client.
A non-participating client
never prevents access to file content on a participating server.
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.
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
.
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 Linux Foundation
https://www.kernel.org
Prototype software based on early versions of this document.
The bulk of this specification is implemented.
GPLv2
No comments from implementors.
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
for more detail.
This document requests no action from IANA.
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
.
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.