Internet DRAFT - draft-cel-nfsv4-linux-seclabel-xtensions
draft-cel-nfsv4-linux-seclabel-xtensions
Network File System Version 4 C. Lever
Internet-Draft Oracle
Intended status: Standards Track April 9, 2018
Expires: October 11, 2018
Linux-related Extensions to NFS version 4.2 Security Labels
draft-cel-nfsv4-linux-seclabel-xtensions-00
Abstract
NFS version 4.2 introduces an optional feature known as NFSv4
Security Labels. This document extends NFSv4 Security Labels to
support Linux file capabilities and the Linux Integrity Measurement
Architecture.
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 October 11, 2018.
Copyright Notice
Copyright (c) 2018 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.
Lever Expires October 11, 2018 [Page 1]
Internet-Draft Linux Seclabel Extensions April 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Linux Integrity Measurement Architecture . . . . . . . . 2
1.2. Linux File Capabilities . . . . . . . . . . . . . . . . . 3
1.3. NFSv4 Security Labels . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Handling File Capabilities on NFS Mounts . . . . . . . . . . 4
4. Handling IMA Metadata on NFS Mounts . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Protection of File Capability Metadata . . . . . . . . . 6
5.2. Protection of IMA Metadata . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In the current document, we define a way to manage both IMA metadata
and Linux file capabilities on NFS files using existing NFSv4
Security Label protocol elements. Before specifying new protocol,
let's contextualize and define the terminology used in the body of
this document.
1.1. Linux Integrity Measurement Architecture
The Linux Integrity Measurement Architecture (hereafter, IMA)
provides assurance that the content of a file is unaltered and
authentic to what was originally written to that file. In addition,
an Extended Verification Module (hereafter, EVM) can assure that a
file's attribute information remains unaltered.
The goal is to detect when a remote attacker, a local attacker, or
unintentional software behavior has modified the content or
attributes of a file. This is done by cryptographically signing HMAC
hashes of a file's content and attribute metadata, and then storing
the signed hashes separately. These hashes are typically updated
whenever the file is legitimately modified.
Integrity verification is not performed by applications or by file
systems. Applications are not exposed to the operation of integrity
verification. File systems are responsible only for persistent
storage of file content and signed hashes. When a file is first
read, content and hashes are passed to IMA modules for measurement
Lever Expires October 11, 2018 [Page 2]
Internet-Draft Linux Seclabel Extensions April 2018
and appraisal. Application access is denied if the hashes cannot be
verified.
Some files may be immutable, in which case their integrity metadata
is signed by an RSA public key signature [RFC8017]. These files can
only be accessed in read-only mode, or deleted by a privileged
process.
Key material used to sign and verify file content and attribute
metadata must be protected. A Trusted Platform Module [TPM-SUM] can
be used to seal the key material. This use case is typical for
providing a read-only operating system image that is
cryptographically verified; for example, in a cloud environment or on
mobile devices.
The goals and use cases of the Linux Integrity Measurement
Architecture (IMA) are presented in further detail in [IMA-WP].
1.2. Linux File Capabilities
The Linux kernel divides privileges traditionally associated with the
superuser into distinct subprivileges, referred to as "capabilities".
These capabilies include but are not limited to
o The ability to override file read and write permission checks
o The ability to signal processes without permission checks
o The ability to bind to a privileged socket port or perform other
privileged network administration tasks
o The ability to perform a range of system administrative tasks such
as rebooting or setting the system clock
Being broken out from the monolithic superuser privilege, individual
capabilities can be enabled and disabled independently of one
another. Individual capabilities are associated with a process and
are inherited during execve(2), similar to the traditional superuser
privilege.
File capabilities enable capabilities to be associated with a file
containing an executable object, like a setuid permission bit. File
capability sets are combined with the capability sets of a parent
process to determine the capabilities of a child process after an
execve(2).
This enables an otherwise unaware application to be given a
particular and specific privilege -- say, the privilege to bind to a
Lever Expires October 11, 2018 [Page 3]
Internet-Draft Linux Seclabel Extensions April 2018
privileged port -- without granting it the privilege to reboot the
system or kill processes that do not share its owner UID, thus
improving overall system security.
The Linux capability implementation is based on the withdrawn
POSIX.1e draft standard (see [POSIX1e]). An overview of the facility
can be found in the Linux capabilities(7) man page (citation needed).
1.3. NFSv4 Security Labels
Section 9 of the NFS version 4.2 specification [RFC7862] defines an
optional feature, known as NFSv4 Security Labels, that permits per-
file extended security labels to be conveyed between NFSv4 clients
and servers.
The intention of these labels is to enable the conveyance of MAC
security labels, but in special cases, non-MAC security information
may be handled. There is no prohibitory language in [RFC7204],
[RFC7569], or [RFC7862] which excludes non-MAC security metadata from
being conveyed via an NFSv4 Security Label, for instance.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD 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. Handling File Capabilities on NFS Mounts
Linux file capabilities are typically manipulated in a native binary
format. However, a capability set can be converted to a human-
readable text format. See the Linux cap_from_text(3) man page
(citation needed).
An NFSv4 client stores the capability set associated with an NFS file
by first converting the capability set to a text format and then
conveying it to an NFSv4 server via a SETATTR operation, using the
LFS number assigned for this purpose (see Section 6). This
capability set completely replaces the previous capability set for
that file.
Likewise, an NFSv4 client retrieves the capability set associated
with a file by first retrieving the text form of the capability set,
as stored in an NFSv4 Security Label, via a GETATTR operation, using
the LFS number assigned for this purpose, and then converting the
Lever Expires October 11, 2018 [Page 4]
Internet-Draft Linux Seclabel Extensions April 2018
retrieved text form into the client's native capability set
representation.
There is no MAC policy associated with the file capabilities LFS
number. The contents of the lfs_pi field MUST be ignored by clients
and servers when this LFS number is used. See Section 12.2.4 of
[RFC7862] for further details about how clients and servers form
these GETATTR and SETATTR requests.
In order to enable file capabilities to be retrieved or updated in a
single RPC, the text format representation of a capability set MUST
NOT exceed 8192 bytes in length.
This document does not specify how an NFSv4 server handles file
capability metadata. Server implementation choices include:
o If there are accessors of shared files that are local to an NFSv4
server, the server may choose to store file capabilities in a
native format and convert them to a text form when an NFSv4 client
retrieves them.
o Alternately, an NFSv4 server may itself not support file
capabilities at all, in which case the server can store capability
sets in text form without conversion to a native format.
4. Handling IMA Metadata on NFS Mounts
On Linux, there are two parts to a file's IMA metadata:
o A cryptographically signed HMAC hash of the file's byte stream,
stored in the file's security.ima extended attribute
o A cryptographically signed HMAC hash of the file's attributes,
stored in the file's security.evm extended attribute
An NFSv4 client stores the signed hash of an NFS file's byte stream
or attributes by conveying the hash to an NFSv4 server via a SETATTR
operation, using the LFS number appropriate for the hash (see
Section 6). This signed hash completely replaces the previous hash.
This document does not specify a policy for authorizing changes to
IMA or EVM hashes.
Likewise, an NFSv4 client retrieves the signed hash of an NFS file's
byte stream or attributes by retrieving the appropriate NFSv4
Security Label via a GETATTR operation using the LFS number assigned
for this purpose. An NFSv4 server MUST NOT prevent an NFSv4 client
from accessing a file based on IMA verification failures on the
server.
Lever Expires October 11, 2018 [Page 5]
Internet-Draft Linux Seclabel Extensions April 2018
There is no MAC policy associated with the IMA or EVM LFS numbers.
The contents of the lfs_pi field MUST be ignored by clients and
servers when these LFS numbers are used. See Section 12.2.4 of
[RFC7862] for further details about how clients and servers form
these GETATTR and SETATTR requests.
In order to enable IMA metadata to be retrieved or updated in a
single RPC, a signed hash MUST NOT exceed 4096 bytes in length.
This document does not specify how an NFSv4 server handles IMA
metadata. If there are local accessors of shared files on an NFSv4
server, the server may choose to store IMA metadata in a native
format that can be handled by the server's local integrity modules.
A note about performance: IMA measurement and appraisal is always
performed on the entirety of a file's byte stream. In other words, a
file's entire byte stream must be read over to an NFSv4 client in
order for its IMA module to verify its integrity. It is recognized
that this requirement can have a significant performance impact for
large files. An NFSv4 client may employ other mechanisms, not
specified here, to reduce this performance impact. For example,
instead of signing a hash of the file's byte stream, a Merkle tree
can be constructed that allows clients to verify the integrity of
smaller portions of a large file, and that tree can be signed instead
of signing the file content.
5. Security Considerations
An NFSv4 server is required to enforce a suitable level of privilege
before allowing a local or remote agent to alter NFSv4 Security
Labels. Consult Section 9.6 of [RFC7862] for further details.
This document does not specify a policy for authorizing changes to
IMA or EVM metadata or file capabilities.
5.1. Protection of File Capability Metadata
File capabilities are conveyed as text strings. To prevent a man-in-
the-middle from escalating the capability set of a file in transit,
these strings must be protected in transit using a GSS service that
provides integrity verification [RFC7861]. A server response that
indicates that a file has no associated file capabilities must be
similarly cryptographically protected. While at rest on durable
storage or in a cache, capability metadata requires the same
protections as other file attribute metadata.
Lever Expires October 11, 2018 [Page 6]
Internet-Draft Linux Seclabel Extensions April 2018
5.2. Protection of IMA Metadata
IMA metadata is cryptographically signed. Receivers can detect
unintentional and malicious alteration of this metadata simply by
verifying the signature. Therefore additional protection using GSS
[RFC7861] or other security mechanisms is not mandatory.
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding the addition of new entries in the
"Security Label Format Selection Registry" in accordance with
Section 5.2 of [RFC7569].
+---------------+---------------------+--------+--------------------+
| Label Format | Description | Status | Reference |
| Specifier | | | |
+---------------+---------------------+--------+--------------------+
| 1 | LINUX-IMA | active | [RFC-TBD] |
| 2 | LINUX-EVM | active | [RFC-TBD] |
| 3 | LINUX-FCAP | active | [RFC-TBD] |
+---------------+---------------------+--------+--------------------+
New entries in the Security Label Format Selection Registry
Table 1
7. References
7.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>.
[RFC7569] Quigley, D., Lu, J., and T. Haynes, "Registry
Specification for Mandatory Access Control (MAC) Security
Label Formats", RFC 7569, DOI 10.17487/RFC7569, July 2015,
<https://www.rfc-editor.org/info/rfc7569>.
[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>.
Lever Expires October 11, 2018 [Page 7]
Internet-Draft Linux Seclabel Extensions April 2018
[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>.
7.2. Informative References
[IMA-WP] Safford, D., "An Overview of The Linux Integrity
Subsystem", <http://downloads.sf.net/project/linux-ima/
linux-ima/Integrity_overview.pdf>.
[POSIX1e] POSIX, "POSIX.1e Specification",
<http://wt.tuxomania.net/publications/posix.1e/>.
[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204,
DOI 10.17487/RFC7204, April 2014,
<https://www.rfc-editor.org/info/rfc7204>.
[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>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM)
Summary", April 2008, <https://trustedcomputinggroup.org/
wp-content/uploads/
Trusted-Platform-Module-Summary_04292008.pdf>.
Acknowledgments
The author thanks Trond Myklebust for suggesting these extentions to
NFSv4 Security Labels. Special thanks go to Transport Area Director
Spencer Dawkins, NFSV4 Working Group Chair Spencer Shepler, and NFSV4
Working Group Secretary Thomas Haynes for their support.
Author's Address
Charles Lever
Oracle Corporation
1015 Granger Avenue
Ann Arbor, MI 48104
United States of America
Phone: +1 248 816 6463
Email: chuck.lever@oracle.com
Lever Expires October 11, 2018 [Page 8]
