idnits 2.17.1 draft-cel-nfsv4-linux-seclabel-xtensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 9, 2018) is 2209 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-TBD' is mentioned on line 306, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track April 9, 2018 5 Expires: October 11, 2018 7 Linux-related Extensions to NFS version 4.2 Security Labels 8 draft-cel-nfsv4-linux-seclabel-xtensions-00 10 Abstract 12 NFS version 4.2 introduces an optional feature known as NFSv4 13 Security Labels. This document extends NFSv4 Security Labels to 14 support Linux file capabilities and the Linux Integrity Measurement 15 Architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 11, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Linux Integrity Measurement Architecture . . . . . . . . 2 53 1.2. Linux File Capabilities . . . . . . . . . . . . . . . . . 3 54 1.3. NFSv4 Security Labels . . . . . . . . . . . . . . . . . . 4 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Handling File Capabilities on NFS Mounts . . . . . . . . . . 4 57 4. Handling IMA Metadata on NFS Mounts . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5.1. Protection of File Capability Metadata . . . . . . . . . 6 60 5.2. Protection of IMA Metadata . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 In the current document, we define a way to manage both IMA metadata 71 and Linux file capabilities on NFS files using existing NFSv4 72 Security Label protocol elements. Before specifying new protocol, 73 let's contextualize and define the terminology used in the body of 74 this document. 76 1.1. Linux Integrity Measurement Architecture 78 The Linux Integrity Measurement Architecture (hereafter, IMA) 79 provides assurance that the content of a file is unaltered and 80 authentic to what was originally written to that file. In addition, 81 an Extended Verification Module (hereafter, EVM) can assure that a 82 file's attribute information remains unaltered. 84 The goal is to detect when a remote attacker, a local attacker, or 85 unintentional software behavior has modified the content or 86 attributes of a file. This is done by cryptographically signing HMAC 87 hashes of a file's content and attribute metadata, and then storing 88 the signed hashes separately. These hashes are typically updated 89 whenever the file is legitimately modified. 91 Integrity verification is not performed by applications or by file 92 systems. Applications are not exposed to the operation of integrity 93 verification. File systems are responsible only for persistent 94 storage of file content and signed hashes. When a file is first 95 read, content and hashes are passed to IMA modules for measurement 96 and appraisal. Application access is denied if the hashes cannot be 97 verified. 99 Some files may be immutable, in which case their integrity metadata 100 is signed by an RSA public key signature [RFC8017]. These files can 101 only be accessed in read-only mode, or deleted by a privileged 102 process. 104 Key material used to sign and verify file content and attribute 105 metadata must be protected. A Trusted Platform Module [TPM-SUM] can 106 be used to seal the key material. This use case is typical for 107 providing a read-only operating system image that is 108 cryptographically verified; for example, in a cloud environment or on 109 mobile devices. 111 The goals and use cases of the Linux Integrity Measurement 112 Architecture (IMA) are presented in further detail in [IMA-WP]. 114 1.2. Linux File Capabilities 116 The Linux kernel divides privileges traditionally associated with the 117 superuser into distinct subprivileges, referred to as "capabilities". 118 These capabilies include but are not limited to 120 o The ability to override file read and write permission checks 122 o The ability to signal processes without permission checks 124 o The ability to bind to a privileged socket port or perform other 125 privileged network administration tasks 127 o The ability to perform a range of system administrative tasks such 128 as rebooting or setting the system clock 130 Being broken out from the monolithic superuser privilege, individual 131 capabilities can be enabled and disabled independently of one 132 another. Individual capabilities are associated with a process and 133 are inherited during execve(2), similar to the traditional superuser 134 privilege. 136 File capabilities enable capabilities to be associated with a file 137 containing an executable object, like a setuid permission bit. File 138 capability sets are combined with the capability sets of a parent 139 process to determine the capabilities of a child process after an 140 execve(2). 142 This enables an otherwise unaware application to be given a 143 particular and specific privilege -- say, the privilege to bind to a 144 privileged port -- without granting it the privilege to reboot the 145 system or kill processes that do not share its owner UID, thus 146 improving overall system security. 148 The Linux capability implementation is based on the withdrawn 149 POSIX.1e draft standard (see [POSIX1e]). An overview of the facility 150 can be found in the Linux capabilities(7) man page (citation needed). 152 1.3. NFSv4 Security Labels 154 Section 9 of the NFS version 4.2 specification [RFC7862] defines an 155 optional feature, known as NFSv4 Security Labels, that permits per- 156 file extended security labels to be conveyed between NFSv4 clients 157 and servers. 159 The intention of these labels is to enable the conveyance of MAC 160 security labels, but in special cases, non-MAC security information 161 may be handled. There is no prohibitory language in [RFC7204], 162 [RFC7569], or [RFC7862] which excludes non-MAC security metadata from 163 being conveyed via an NFSv4 Security Label, for instance. 165 2. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in BCP 14 [RFC2119] 170 [RFC8174] when, and only when, they appear in all capitals, as shown 171 here. 173 3. Handling File Capabilities on NFS Mounts 175 Linux file capabilities are typically manipulated in a native binary 176 format. However, a capability set can be converted to a human- 177 readable text format. See the Linux cap_from_text(3) man page 178 (citation needed). 180 An NFSv4 client stores the capability set associated with an NFS file 181 by first converting the capability set to a text format and then 182 conveying it to an NFSv4 server via a SETATTR operation, using the 183 LFS number assigned for this purpose (see Section 6). This 184 capability set completely replaces the previous capability set for 185 that file. 187 Likewise, an NFSv4 client retrieves the capability set associated 188 with a file by first retrieving the text form of the capability set, 189 as stored in an NFSv4 Security Label, via a GETATTR operation, using 190 the LFS number assigned for this purpose, and then converting the 191 retrieved text form into the client's native capability set 192 representation. 194 There is no MAC policy associated with the file capabilities LFS 195 number. The contents of the lfs_pi field MUST be ignored by clients 196 and servers when this LFS number is used. See Section 12.2.4 of 197 [RFC7862] for further details about how clients and servers form 198 these GETATTR and SETATTR requests. 200 In order to enable file capabilities to be retrieved or updated in a 201 single RPC, the text format representation of a capability set MUST 202 NOT exceed 8192 bytes in length. 204 This document does not specify how an NFSv4 server handles file 205 capability metadata. Server implementation choices include: 207 o If there are accessors of shared files that are local to an NFSv4 208 server, the server may choose to store file capabilities in a 209 native format and convert them to a text form when an NFSv4 client 210 retrieves them. 212 o Alternately, an NFSv4 server may itself not support file 213 capabilities at all, in which case the server can store capability 214 sets in text form without conversion to a native format. 216 4. Handling IMA Metadata on NFS Mounts 218 On Linux, there are two parts to a file's IMA metadata: 220 o A cryptographically signed HMAC hash of the file's byte stream, 221 stored in the file's security.ima extended attribute 223 o A cryptographically signed HMAC hash of the file's attributes, 224 stored in the file's security.evm extended attribute 226 An NFSv4 client stores the signed hash of an NFS file's byte stream 227 or attributes by conveying the hash to an NFSv4 server via a SETATTR 228 operation, using the LFS number appropriate for the hash (see 229 Section 6). This signed hash completely replaces the previous hash. 230 This document does not specify a policy for authorizing changes to 231 IMA or EVM hashes. 233 Likewise, an NFSv4 client retrieves the signed hash of an NFS file's 234 byte stream or attributes by retrieving the appropriate NFSv4 235 Security Label via a GETATTR operation using the LFS number assigned 236 for this purpose. An NFSv4 server MUST NOT prevent an NFSv4 client 237 from accessing a file based on IMA verification failures on the 238 server. 240 There is no MAC policy associated with the IMA or EVM LFS numbers. 241 The contents of the lfs_pi field MUST be ignored by clients and 242 servers when these LFS numbers are used. See Section 12.2.4 of 243 [RFC7862] for further details about how clients and servers form 244 these GETATTR and SETATTR requests. 246 In order to enable IMA metadata to be retrieved or updated in a 247 single RPC, a signed hash MUST NOT exceed 4096 bytes in length. 249 This document does not specify how an NFSv4 server handles IMA 250 metadata. If there are local accessors of shared files on an NFSv4 251 server, the server may choose to store IMA metadata in a native 252 format that can be handled by the server's local integrity modules. 254 A note about performance: IMA measurement and appraisal is always 255 performed on the entirety of a file's byte stream. In other words, a 256 file's entire byte stream must be read over to an NFSv4 client in 257 order for its IMA module to verify its integrity. It is recognized 258 that this requirement can have a significant performance impact for 259 large files. An NFSv4 client may employ other mechanisms, not 260 specified here, to reduce this performance impact. For example, 261 instead of signing a hash of the file's byte stream, a Merkle tree 262 can be constructed that allows clients to verify the integrity of 263 smaller portions of a large file, and that tree can be signed instead 264 of signing the file content. 266 5. Security Considerations 268 An NFSv4 server is required to enforce a suitable level of privilege 269 before allowing a local or remote agent to alter NFSv4 Security 270 Labels. Consult Section 9.6 of [RFC7862] for further details. 272 This document does not specify a policy for authorizing changes to 273 IMA or EVM metadata or file capabilities. 275 5.1. Protection of File Capability Metadata 277 File capabilities are conveyed as text strings. To prevent a man-in- 278 the-middle from escalating the capability set of a file in transit, 279 these strings must be protected in transit using a GSS service that 280 provides integrity verification [RFC7861]. A server response that 281 indicates that a file has no associated file capabilities must be 282 similarly cryptographically protected. While at rest on durable 283 storage or in a cache, capability metadata requires the same 284 protections as other file attribute metadata. 286 5.2. Protection of IMA Metadata 288 IMA metadata is cryptographically signed. Receivers can detect 289 unintentional and malicious alteration of this metadata simply by 290 verifying the signature. Therefore additional protection using GSS 291 [RFC7861] or other security mechanisms is not mandatory. 293 6. IANA Considerations 295 This section provides guidance to the Internet Assigned Numbers 296 Authority (IANA) regarding the addition of new entries in the 297 "Security Label Format Selection Registry" in accordance with 298 Section 5.2 of [RFC7569]. 300 +---------------+---------------------+--------+--------------------+ 301 | Label Format | Description | Status | Reference | 302 | Specifier | | | | 303 +---------------+---------------------+--------+--------------------+ 304 | 1 | LINUX-IMA | active | [RFC-TBD] | 305 | 2 | LINUX-EVM | active | [RFC-TBD] | 306 | 3 | LINUX-FCAP | active | [RFC-TBD] | 307 +---------------+---------------------+--------+--------------------+ 309 New entries in the Security Label Format Selection Registry 311 Table 1 313 7. References 315 7.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC7569] Quigley, D., Lu, J., and T. Haynes, "Registry 323 Specification for Mandatory Access Control (MAC) Security 324 Label Formats", RFC 7569, DOI 10.17487/RFC7569, July 2015, 325 . 327 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 328 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 329 November 2016, . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 7.2. Informative References 337 [IMA-WP] Safford, D., "An Overview of The Linux Integrity 338 Subsystem", . 341 [POSIX1e] POSIX, "POSIX.1e Specification", 342 . 344 [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, 345 DOI 10.17487/RFC7204, April 2014, 346 . 348 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 349 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 350 November 2016, . 352 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 353 "PKCS #1: RSA Cryptography Specifications Version 2.2", 354 RFC 8017, DOI 10.17487/RFC8017, November 2016, 355 . 357 [TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM) 358 Summary", April 2008, . 362 Acknowledgments 364 The author thanks Trond Myklebust for suggesting these extentions to 365 NFSv4 Security Labels. Special thanks go to Transport Area Director 366 Spencer Dawkins, NFSV4 Working Group Chair Spencer Shepler, and NFSV4 367 Working Group Secretary Thomas Haynes for their support. 369 Author's Address 371 Charles Lever 372 Oracle Corporation 373 1015 Granger Avenue 374 Ann Arbor, MI 48104 375 United States of America 377 Phone: +1 248 816 6463 378 Email: chuck.lever@oracle.com