idnits 2.17.1 draft-dnoveck-nfsv4-security-04.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC8881, but the abstract doesn't seem to directly say this. It does mention RFC8881 though, so this could be OK. -- The draft header indicates that this document updates RFC7530, but the abstract doesn't seem to directly say this. It does mention RFC7530 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1220 has weird spacing: '...r_mixed who;...' == 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 December 2021) is 855 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 5247, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 5251, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 5256, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 5268, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 5278, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 5288, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-cel-nfsv4-rpc-tls-pseudoflavors-01 -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Obsolete informational reference (is this intentional?): RFC 5661 (ref. '16') (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 D. Noveck, Ed. 3 Internet-Draft NetApp 4 Updates: 8881, 7530 (if approved) 24 December 2021 5 Intended status: Standards Track 6 Expires: 27 June 2022 8 Security for the NFSv4 Protocols 9 draft-dnoveck-nfsv4-security-04 11 Abstract 13 This document describes the core security features of the NFSv4 14 family of protocols, applying to all minor versions. The discussion 15 includes the use of security features provided by RPC on a per- 16 connection basis. 18 This preliminary version of the document, is intended, in large part, 19 to result in working group discussion regarding existing NFSv4 20 security issues and to provide a framework for addressing these 21 issues and obtaining working group consensus regarding necessary 22 changes. 24 When a successor document is eventually published as an RFC, it will 25 supersede the description of security appearing in existing minor 26 version specification documents such as RFC 7530 and RFC 8881. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 27 June 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Document Motivation . . . . . . . . . . . . . . . . . . . 5 75 1.2. Document Annotation . . . . . . . . . . . . . . . . . . . 5 76 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 77 2.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 7 78 2.2. Special Considerations . . . . . . . . . . . . . . . . . 7 79 3. Introduction to this Update . . . . . . . . . . . . . . . . . 8 80 3.1. Per-connection Security Features . . . . . . . . . . . . 8 81 3.2. Handling of Multiple Minor Versions . . . . . . . . . . . 9 82 3.3. Handling of Minor-version-specific features . . . . . . . 10 83 3.4. Features Needing Extensive Clarification . . . . . . . . 12 84 3.5. Process Going Forward . . . . . . . . . . . . . . . . . . 15 85 4. Introduction to NFSv4 Security . . . . . . . . . . . . . . . 17 86 4.1. NFSv4 Security Terminology . . . . . . . . . . . . . . . 19 87 4.2. NFSv4 Security Scope Limitations . . . . . . . . . . . . 23 88 5. Structure of NFSv4 Access Control Lists . . . . . . . . . . . 26 89 5.1. Access Control Entries . . . . . . . . . . . . . . . . . 26 90 5.2. ACE Type . . . . . . . . . . . . . . . . . . . . . . . . 27 91 5.3. ACE Access Mask . . . . . . . . . . . . . . . . . . . . . 28 92 5.4. Uses of Mask Bits . . . . . . . . . . . . . . . . . . . . 29 93 5.5. Requirements and Recommendations Regarding Mask 94 Granularity . . . . . . . . . . . . . . . . . . . . . . 39 95 5.6. Handling of Deletion . . . . . . . . . . . . . . . . . . 41 96 5.6.1. Previous Handling of Deletion . . . . . . . . . . . . 42 97 5.7. ACE flag bits . . . . . . . . . . . . . . . . . . . . . . 43 98 5.8. Details Regarding ACE Flag Bits . . . . . . . . . . . . . 45 99 5.9. ACE Who . . . . . . . . . . . . . . . . . . . . . . . . . 46 100 5.10. Automatic Inheritance Features . . . . . . . . . . . . . 49 101 5.11. Attribute 13: aclsupport . . . . . . . . . . . . . . . . 51 102 5.12. Attribute 12: acl . . . . . . . . . . . . . . . . . . . . 52 103 6. Authorization in General . . . . . . . . . . . . . . . . . . 53 104 7. User-based File Access Authorization . . . . . . . . . . . . 54 105 7.1. Attributes for User-based File Access Authorization . . . 54 106 7.2. Handling of Multiple Parallel File Access Authorization 107 Models . . . . . . . . . . . . . . . . . . . . . . . . . 55 108 7.3. Posix Authorization Model . . . . . . . . . . . . . . . . 57 109 7.3.1. Attribute 33: mode . . . . . . . . . . . . . . . . . 57 110 7.3.2. NFSv4.1 Attribute 74: mode_set_masked . . . . . . . . 58 111 7.4. ACL-based Authorization Model . . . . . . . . . . . . . . 59 112 7.4.1. Processing Access Control Entries . . . . . . . . . . 59 113 7.4.2. V4.1 Attribute 58: dacl . . . . . . . . . . . . . . . 61 114 8. Common Considerations for Both File access Models . . . . . . 61 115 8.1. Server Considerations . . . . . . . . . . . . . . . . . . 62 116 8.2. Client Considerations . . . . . . . . . . . . . . . . . . 65 117 9. Combining Authorization Models . . . . . . . . . . . . . . . 66 118 9.1. Background for Combined Authorization Model . . . . . . . 66 119 9.2. Needed Attribute Coordination . . . . . . . . . . . . . . 69 120 9.3. Computing a Mode Attribute from an ACL . . . . . . . . . 72 121 9.4. Alternatives in Computing Mode Bits . . . . . . . . . . . 73 122 9.5. Handling of UNIX ACLs . . . . . . . . . . . . . . . . . . 75 123 9.6. Setting Multiple ACL Attributes . . . . . . . . . . . . . 75 124 9.7. Setting Mode and not ACL (overall) . . . . . . . . . . . 75 125 9.7.1. Setting Mode and not ACL (vestigial) . . . . . . . . 76 126 9.7.2. Setting Mode and not ACL (Discussion) . . . . . . . . 77 127 9.7.3. Setting Mode and not ACL (Proposed) . . . . . . . . . 78 128 9.8. Setting ACL and Not Mode . . . . . . . . . . . . . . . . 83 129 9.9. Setting Both ACL and Mode . . . . . . . . . . . . . . . . 84 130 9.10. Retrieving the Mode and/or ACL Attributes . . . . . . . . 84 131 9.11. Creating New Objects . . . . . . . . . . . . . . . . . . 84 132 9.12. Use of Inherited ACL When Creating Objects . . . . . . . 86 133 9.13. Combined Authorization Models for NFSv4.2 . . . . . . . . 86 134 10. Labelled NFS Authorization Model . . . . . . . . . . . . . . 87 135 11. State Modification Authorization . . . . . . . . . . . . . . 87 136 12. Other Uses of Access Control Lists . . . . . . . . . . . . . 88 137 12.1. V4.1 Attribute 59: sacl . . . . . . . . . . . . . . . . 88 138 13. Identification and Authentication . . . . . . . . . . . . . . 89 139 13.1. Identification vs. Authentication . . . . . . . . . . . 89 140 13.2. Items to be Identified . . . . . . . . . . . . . . . . . 89 141 13.3. Authentication Provided by specific RPC Auth Flavors . . 90 142 13.4. Authentication Provided by other RPC Security 143 Services . . . . . . . . . . . . . . . . . . . . . . . . 91 144 14. Security of Data in Flight . . . . . . . . . . . . . . . . . 91 145 14.1. Data Security Provided by Services Associated with Auth 146 Flavors . . . . . . . . . . . . . . . . . . . . . . . . 91 147 14.2. Data Security Provided for a Connection by RPC . . . . . 91 148 15. Security Negotiation . . . . . . . . . . . . . . . . . . . . 92 149 15.1. Dealing with Multiple Connections . . . . . . . . . . . 93 150 16. Future Security Needs . . . . . . . . . . . . . . . . . . . . 94 151 17. Security Considerations . . . . . . . . . . . . . . . . . . . 95 152 17.1. Changes in Security Considerations . . . . . . . . . . . 95 153 17.1.1. Wider View of Threats . . . . . . . . . . . . . . . 96 154 17.1.2. Connection-oriented Security Facilities . . . . . . 97 155 17.1.3. Necessary Security Changes . . . . . . . . . . . . . 97 156 17.1.4. Compatibility and Maturity Issues . . . . . . . . . 98 157 17.1.5. Discussion of AUTH_SYS . . . . . . . . . . . . . . . 98 158 17.2. Security Considerations Scope . . . . . . . . . . . . . 99 159 17.2.1. Discussion of Potential Classification of 160 Environments . . . . . . . . . . . . . . . . . . . . 99 161 17.2.2. Discussion of Environments . . . . . . . . . . . . . 100 162 17.2.3. Insecure Environments . . . . . . . . . . . . . . . 101 163 17.3. Major New Recommendations . . . . . . . . . . . . . . . 101 164 17.3.1. Recommendations Regarding Security of Data in 165 Flight . . . . . . . . . . . . . . . . . . . . . . . 101 166 17.3.2. Recommendations Regarding Client Peer 167 Authentication . . . . . . . . . . . . . . . . . . . 102 168 17.3.3. Recommendations Regarding Superuser Semantics . . . 103 169 17.3.4. Issues Regarding Valid Reasons to Bypass 170 Recommendations . . . . . . . . . . . . . . . . . . . 103 171 17.4. Threat Analysis . . . . . . . . . . . . . . . . . . . . 104 172 17.4.1. Threat Analysis Scope . . . . . . . . . . . . . . . 104 173 17.4.2. Threats based on Credential Compromise . . . . . . . 104 174 17.4.3. Threats Based on Rouge Clients . . . . . . . . . . . 106 175 17.4.4. Threats Based on Rouge Servers . . . . . . . . . . . 107 176 17.4.5. Data Security Threats . . . . . . . . . . . . . . . 108 177 17.4.6. Authentication-based threats . . . . . . . . . . . . 108 178 17.4.7. Disruption and Denial-of-Service Attacks . . . . . . 111 179 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112 180 18.1. New Authstat Values . . . . . . . . . . . . . . . . . . 112 181 18.2. New Authentication Pseudo-Flavors . . . . . . . . . . . 113 182 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 183 19.1. Normative References . . . . . . . . . . . . . . . . . . 114 184 19.2. Informative References . . . . . . . . . . . . . . . . . 115 185 Appendix A. Changes Made . . . . . . . . . . . . . . . . . . . . 115 186 A.1. Motivating Changes . . . . . . . . . . . . . . . . . . . 116 187 A.2. Other Major Changes . . . . . . . . . . . . . . . . . . . 116 188 Appendix B. Issues for which Consensus Needs to be 189 Ascertained . . . . . . . . . . . . . . . . . . . . . . . 117 190 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 128 191 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 129 193 1. Overview 195 This document is intended to form the basis for a new description of 196 NFSv4 security applying to all NFSv4 minor versions. The motivation 197 for this new document and the need for major improvements in NFSv4 198 security are explained in Section 1.1. 200 Because this document anticipates making major changes in material 201 covered in previous standards-track RFCs, extensive working group 202 discussion will be necessary to make sure that there is a working 203 group consensus to make the changes being proposed. These changes 204 include the major improvements mentiontioned above and changes 205 necessary to suitably describe features currently in an 206 unsatisfactory state as described in Section 3.4 208 1.1. Document Motivation 210 A new treatment of security is necessary because: 212 * Previous treatments paid insufficient attention to security issues 213 regarding data in flight. 215 * The presentation of AUTH_SYS as an "'OPTIONAL' means of 216 authentication" obscured the significant security problems that 217 come with its use. 219 * The security considerations sections of existing minor version 220 specifications contain no threat analyses and focus on particular 221 security issues in a way that obscures, rather than clarifying, 222 the security issues that need to be addressed. 224 * The availability of RPC-with-TLS (described in [12]) provides 225 facilities that NFSv4 clients and servers will need to use to 226 provide security for data in flight and mitigate the lack of user 227 authentication when AUTH_SYS is used. 229 1.2. Document Annotation 231 The first version of this preliminary document contained many notes 232 with headers in brackets, requesting comments regarding confusing or 233 otherwise dubious passages in existing documents and noting other 234 choices that need to made. Comments about and working group 235 discussion of these issues will be important in arriving at an 236 adequate RFC candidate. In this version, those specific items have 237 been removed and are replaced by the sorts of items described below 238 which show the troublesome existing text, explain the issues with it, 239 and and provide a proposed replacement. 241 In order to make further progress on these difficult issues, 242 including many whose resolution will probably involve compatibility 243 issues with existing implementations, the author has tried his best 244 to resolve these issues, even though there is no assurance that the 245 resolution adopted by consensus will match the author's current best 246 efforts. To provide a possible resolution that might be the basis of 247 discussion while not foreclosing other possibilities, proposed 248 changes are organized into a series of consensus items, which are 249 listed in Appendix B. 251 For such pending issues, the following annotations will be used: 253 * A paragraph headed "[Author Aside]:", provides the author's 254 comments about possible changes and will probably not appear in an 255 eventual RFC. 257 This paragraph can specify that certain changes within the current 258 section are to be implicitly considered as part of a specific 259 consensus item. 261 The paragraph can indicate that all unannotated material in the 262 current section is to be considered either the previous treatment 263 or the proposed replacement text for a specific consensus item. 265 * A paragraph headed "[Consensus Needed (Item #NNx)]:", provides the 266 author's preferred treatment of the matter and will only appear in 267 the eventual RFC if working group consensus on the matter is 268 obtained allowing the necessary changes to be made permanent, 269 without being conditional on a future consensus. 271 The item id, represented above by "NNx" consists of a number 272 identifying the specific consensus item and letter which is unique 273 to appearance of that consensus item in a particular section. In 274 cases in which a pending item is cited with no part of the 275 discussion appearing in the current section, an item id of the 276 form "#NN" is used. 278 * A paragraph headed "[Previous Treatment]:", indicates text that is 279 provided for context but which the author believes, need not 280 appear in the eventual RFC, because it is expected to be 281 superseded by a corresponding consensus item 283 The corresponding consensus item is often easily inferred, but can 284 be specified explicitly, as it is for items associated with the 285 consensus item itself. 287 Each of the annotations above can be modified by addition of the 288 phrase, "Including List" to indicate that it applies to a following 289 bulleted list as well as the current paragraph or the phase "Entire 290 Bulleted Item" to indicate it applies to all paragraphs within a 291 specific bulleted item. 293 2. Requirements Language 295 2.1. Keyword Definitions 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as specified in BCP 14 [1] [5] when, 300 and only when, they appear in all capitals, as shown here. 302 2.2. Special Considerations 304 Because this document needs to revise previous treatments of its 305 subject, it will need to cite previous treatments of issues that now 306 need to be dealt with in a different way. This will take the form of 307 quotations from documents whose treatment of the subject is being 308 obsoleted, most often direct but sometimes indirect as well. 310 Paragraphs headed "[Previous Treatment] or otherwise annotated as 311 having that status, as described in Section 1, can be considered 312 quotations in this context. 314 Such treatments in quotations will involve use of these BCP14-defined 315 terms in two noteworthy ways: 317 * The term may have been used inappropriately (i.e not in accord 318 with RFC2119 [1]), as has been the case for the "RECOMMENDED" 319 attributes, which are in fact OPTIONAL. 321 In such cases, the surrounding text will make clear that the 322 quoted text does not have a normative effect. 324 Some specific issues relating to this case are described below 325 Section 7.1. 327 * The term may been used in accord with RFC2119 [1], although the 328 resulting normative statement is now felt to be inappropriate. 330 In such cases, the surrounding text will need to make clear that 331 the text quoted is no longer to be considered normative, often by 332 providing new text that conflicts with the quoted, previously 333 normative, text. 335 An important instance of this situation is the description of 336 AUTH_SYS as an "'OPTIONAL' means of authentication". For detailed 337 discussion of this case, see Sections 13 and 17.1.5 339 3. Introduction to this Update 341 There are a number of noteworthy aspects to the updated approach to 342 NFSv4 security presented in this document: 344 * There is a major rework of the security framework to take 345 advantage of work done in RPC-with-TLS, as described in 346 Section 1.1. 348 NFSv4 security is still built on RPC, as had been done previously. 349 However, it is now able to take advantage of security-related 350 facilities provide on a per-connection basis For more information 351 about this transformation, see Section 3.1. 353 For an overview of changes made so far as part of this rework, see 354 Appendix A.1. 356 * This document deals with all minor versions together, although 357 there is a need for exceptions to deal with, for example, pNFS 358 security. 360 For more detail about how minor version differences will be 361 addressed, see Sections 3.2 and 3.3. 363 * There is a new Security Considerations section including a threat 364 analysis. 366 * There has been extensive work to clarify the multiple types of 367 authorization within NFSv4 and deal more completely with the co- 368 ordination of ACL-based and mode-based file access authorization. 370 3.1. Per-connection Security Features 372 There are a number of security-related facilities that can be 373 provided on a per-connection basis, eliminating the need to provide 374 such support on a per-request basis, based on the RPC auth flavor 375 used. 377 These will initially be provided, in mosr cases, by RPC-with-TLS but 378 similar facilities might be provided by new versions of existing 379 transports or new RPC transports. 381 * The transport or a layer above it might provide encryption of 382 requests and replies, eliminating the need for privacy and 383 integrity services to be negotiated later and applied on a per- 384 request basis. 386 While clients might choose to establish connections with such 387 encryption, servers can establish policies allowing access to 388 certain pieces of the namespace using such security facilities, or 389 limiting access to those providing privacy, allowing the use of 390 either per-connection encryption or privacy services provided by 391 RPCSEC_GSS. 393 * The transport or a layer above it might provide mutual 394 authentication of the client and server peers as part of the 395 establishment of the connection This authentication is distinct 396 from the the mutual authentication of the client user and server 397 peer, implemented within the GSSSEC_RPC framework. 399 This form of authentication is of particular importance when when 400 the server allows the use of the auth flavors AUTH_SYS and 401 AUTH_NONE, which have no provision for the authentication of the 402 user requesting the operation. 404 While clients might choose, on their own,to establish connections 405 with such peer authentication, servers can establish policies a 406 limiting access to certain pieces of the namespace without such 407 peer authentication or only allowing it when using RPCSEC_GSS. 409 To enable server policies to be effectively communicated to clients, 410 the security negotiation framework now allows connection 411 characteristics to be specified using pseudo-flavors returned as part 412 of the response to SECINFO and SECINFO_NONAME. See Section 15 for 413 details. 415 3.2. Handling of Multiple Minor Versions 417 In some cases, there are differences between minor versions in that 418 there are security-related features, not present in all minor 419 versions. 421 To deal with this issue, this document will focus on a few major 422 areas listed below which are common to all minor versions. 424 * File access authorization (discussed in Section 7) is the same in 425 all minor versions together with the identification/ 426 authentication infrastructure supporting it (discussed in 427 Section 13) provided by RPC and applying to all of NFS. 429 An exception is made regarding labelled NFS, an optional feature 430 within NFSv4.2, described in RFC7862 [10]. This is discussed as a 431 version-specific feature in this document in Section 10 433 * Features to secure data in-flight, all provided by RPC, together 434 with the negotiation infrastructure to support them are common to 435 all NFSv4 minor versions, are discussed in Section 15 437 However, the use of SECINFO_NONAME, together with changes needed 438 for connection-based encryption, paralleling those proposed here 439 for SECINFO, is treated as a version-specific feature and, while 440 mentioned here, will be fully documented in new NFSv4.1 441 specification documents. 443 * The protection of state data from unauthorized modification is 444 discussed in Section 11) is the same in all minor versions 445 together with the identification/ authentication infrastructure 446 supporting it (discussed in Section 13 by security services such 447 as those provided by RPC-with-TLS. 449 It needs to be noted that state protection based on RPCSEC_GSS is 450 treated as a version-specific feature and will continue to be 451 described by RFC8881[8] or its successors. Also, it needs to be 452 noted that the use of state protection was not discussed in 453 RFC7530 [6]. 455 3.3. Handling of Minor-version-specific features 457 There are a number of areas in which security features differ among 458 minor versions, as discussed below. In some cases, a new feature 459 requires specific security support while in others one version will 460 have a new feature related to enhancing the security infrastructure. 462 How such features are dealt with in this document depends on the 463 specific feature. 465 * In addition to SECINFO, whose enhanced description appears in this 466 document, NFSv4.1 added a new SECINFO_NONAME operation, useful for 467 pNFS file as well as having some non-pNFS uses. 469 While the enhanced description of SECINFO mentions SECINFO_NONAME, 470 this is handled as one of a number of cases in which the 471 description has to indicate that different actions need to be 472 taken for different minor versions. 474 The definitive description of SECINFO_NONAME, now appearing in 475 RFC8881 [8] needs to be modified to match the description of 476 SECINFO appearing in this document. It is expected that this will 477 be done as part of the rfc5661bis process. 479 The security implications of the security negotiation facilities 480 as a whole will be addressed in the security considerations 481 section of this document. 483 * The OPTIONAL pNFS feature added in NFSv4.1 has its own security 484 needs which parallel closely those of non-pNFS access but are 485 distinct, especially when the storage access protocol used are not 486 RPC protocols. As a result, these needs and the means to satisfy 487 them are not discussed in this document. 489 The definitive description of pNFS security will remain in RFC8881 490 [8] and its successors (i.e. the rfc5661bis document suite). 491 However, because pNFS security relies heavily on the 492 infrastructure discussed here, it is anticipated that the new 493 treatment of pNFS security will deal with many matters by 494 referencing the overall NFS security document. 496 The security considerations section of rfc5661bis will deal with 497 pNFS security issues. 499 * In addition to the state protection facilities described in this 500 document, NFS has another set of such facilities that are only 501 implemented in NFSv4.1. 503 While this document will discuss the security implications of 504 protection against state modification, it will not discuss the 505 details of the NFSv4.1-specific features to accomplish it. 507 * The additional NFSv4.1 acl attributes, sacl and dacl, are 508 discussed in this document, together with the ACL inheritance 509 features they enable. 511 As a result, the responsibility for the definitive description of 512 these attributes will move to overall NFS security document, with 513 the fact that they are not available in NFSv4.0 duly noted. While 514 these attributes will continue to be mentioned in NFSv4.1 515 specification documents, the detailed description appearing in 516 RFC8881 [8] will be removed in successor documents. 518 * Both NFSv4.0 and NFSv4.1 specifications discussed the coordination 519 of the values the mode and ACL-related attributes. While the 520 treatment in RFC8881 [8] is more detailed, the differences in the 521 approaches are quite minor. 523 [Consensus Item #25a]: This document will provide a unified 524 treatment of these issues, which will note any differences of 525 treatment that apply to NFSv4.0. Changes applying to NFSv4.2 will 526 also be noted. 528 As a result, this document will override the treatment within 529 RFC7530 [6] and RFC8881 [8]. This material will be removed in the 530 rfc5661bis document suite and replaced by a reference to the 531 treatment in the NFSv4 security RFC. 533 * The protocol extension defined in RFC8257 [15], now part of 534 NFSv4.2, is also related to the issue of co-ordination of acl and 535 mode attributes and will be discussed in that context. 537 Nevertheless, the description in RFC8257 [15] will remain 538 definitive. 540 * The NFSv4.1 attribute set-mode-masked attribute is mentioned 541 together with the other attributes implementing the POSIX 542 authorization model. 544 Because this attribute. while related to security, does not 545 substantively modify the security properties of the protocol, the 546 full description of this attribute, will continue to be the 547 province of the NFSv4.1 specification proper. 549 * There is a brief description of the v4.2 Labelled NFS feature in 550 Section 10. Part of that description discusses the limitations in 551 the description of that feature within RFC7862 [10]. 553 Because of some limitations in the description, it is not possible 554 to provide an appropriate security considerations section for that 555 feature in this document. 557 As a result, the responsibility for providing an appropriate 558 Security Considerations section remains, unrealized for now, with 559 the NFSv4.2 specification document and its possible successors. 561 3.4. Features Needing Extensive Clarification 563 For a number of authorization-related features, the existing 564 descriptions are inadequate for various reasons: 566 * In the description of the the use of the mode attribute in 567 implementing the POSIX-based authorization model, critical pieces 568 of the semantics are not mentioned, while, ironically, the 569 corresponding semantics for ACL-based authorization are discussed. 571 This includes the authorization of file deletion and of 572 modification of the mode, owner and owner-group attributes. For 573 ACL-based authorization, there is a an attempt to provide the 574 description. 576 The situation for authorization of RENAME is similar, although, in 577 this case, the corresponding semantics for the ACL case are also 578 absent. 580 * The description of authorization for ACLs is more complete but it 581 needs further work, because the previous specifications make 582 extensive efforts, in my view misguided, to allow an enormous 583 range of server behaviors, making it hard for a client to know 584 what the effect of many actions, and the corresponding security- 585 related consequences, might be. 587 Troublesome in this connection are the discussion of ACE mask bits 588 which essentially treats every mask bit, as its own OPTIONAL 589 feature, the use of "SHOULD" and "SHOULD NOT" in situations which 590 it is unclear what valid reasons to ignore the recommendation 591 might be, and cases in which it is is simply stated that some 592 servers do some particular thing, leaving the unfortunate 593 implication that clients need to be prepared for a vast range of 594 server behaviors. 596 This approach essentially treated ACLs in a manner appropriate to 597 an experimental feature. 599 * Similar issues apply to descriptions related to the need to co- 600 ordinate the values of the mode attribute and the ACL-related 601 attributes. 603 Although the need for such coordination is recognized. There are 604 multiple modes of mapping an ACL to a corresponding mode together 605 with multiple sources of uncertainty about the reverse mapping. 607 In addition, certain of the mapping algorithms have flaws in that 608 their behavior under unusual circumstances give results that 609 appear erroneous. 611 Dealing with these issues is not straightforward, because the 612 appropriate resolution will depend on: 614 * The actual existence of server implementations with non-preferred 615 semantics. 617 In some cases in which "SHOULD" was used, there may not have been 618 any actual severs choosing to ignore the recommendation, 619 eliminating the possibility of compatibility issues when changing 620 the "SHOULD" to a formulation that restricts the server's choices. 622 * The difficulty of modifying server implementations to eliminate or 623 narrow the effect of non-standard semantics. 625 One aspect of that difficulty might be client or application 626 expectations based on existing server implementations, even if the 627 existing specifications give the client no assurance that that 628 server's behavior is mandated by the standard. 630 * Whether the existing flaw in some existing recommended actions to 631 be performed by the server is sufficiently troublesome to justify 632 changing the specification at this point. 634 This sort of information will be used in deciding whether to: 636 * Narrow the scope of allowable server behavior to those actually 637 used by existing severs. 639 * Limiting the negative effects of unmotivated SHOULDs by limiting 640 valid reasons to ignore the recommendation to the difficulty of 641 changing existing implementations. 643 This would give significant guidance to future implementations, 644 while forcing clients to live with the uncertainty about existing 645 servers 647 * Tie a more restricted set of semantics to nominally unrelated 648 OPTIONAL features such as implementation of dacl and sacl. 650 This would provide a way to allow the development of newer servers 651 to proceed in a way that 653 * Provide means that clients to use to determine, experimentally, 654 what semantics are provided by the server. 656 Would need to be supported by a requirement/assurance that a 657 server behave uniformly, at least within the scope of a single 658 file system. 660 * Allow the provision of other ways for the client to know the 661 semantics choices made by the server. 663 Despite the difficulty of addressing these issues, if the protocol is 664 to be secure and ACLs are to be widely available, these problems have 665 to be addressed. While there has not been significant effort to 666 provide client-side ACL APIs and there might not be for a while, we 667 cannot have a situation if which the security specification makes 668 that development essentially impossible. 670 3.5. Process Going Forward 672 Because of the scope of this document, and the fact that it is 673 necessary to modify previous treatments of the subject previously 674 published as Proposed Standards, it is necessary that the process of 675 determining whether there is Working Group Consensus to submit it for 676 publication be more structured than that used for the antecedent 677 documents. 679 In order to facilitate this process, the necessary changes which need 680 to be made, beyond those clearly editorial in nature, are listed in 681 Appendix B. As working group review and discussion of this document 682 and its successors proceeds, there will be occasion to discuss each 683 of these changes, identified by the annotations described in 684 Section 1.2. 686 Based on working group discussions, successive document versions will 687 do one of the following for some set of consensus items: 689 * Deciding that the replacement text is now part of a new working 690 group consensus. 692 When this happens, future drafts of the document will be modified 693 to remove the previous treatment, treat the proposed text as 694 adopted, and remove Author Asides or replace them by new text 695 explaining why a new treatment of the matter has been adopted or 696 pointing the reader to an explanation in Appendix A. 698 At this point, the consensus item will be removed from Appendix B 699 and an explanation for the change will be added to Appendix A. 701 * Deciding that the general approach to the issue, if not 702 necessarily the specific current text has reached the point of 703 "general acceptance" as defined in Appendix B 705 In this case, to facilitate discussion of remaining issues, the 706 text of the document proper will remain as it is. 708 At this point, the consensus item will be marked within the table 709 in Appendix B as having reached general acceptance, indicating the 710 need to prioritize discussion in the next document cycle, aimed at 711 arriving at final text to address the issue. 713 In addition, an explanation for the change will be added to 714 Appendix A. 716 * Deciding that modification of the existing text is necessary to 717 facilitate eventual consensus, based on the working group's input. 719 In this case, there will be changes to the document proper in the 720 next draft revision. In some cases, because of the need for a 721 coherent description, text outside the consensus item may be 722 affected. 724 The table in Appendix B will be updated to reflect the new item 725 status while Appendix A is not expected to change. 727 * Deciding that the item is best dropped in the next draft. 729 In this case, the changes to the document proper will be the 730 inverse of those when a change is accepted by consensus. The 731 previous treatment will be restored as the current text while the 732 proposed new text will vanish from the document at the next draft 733 revision. The Author Aside will be the basis for an explanation 734 of the consequences of not dealing with the issue. 736 At this point, the consensus item will be removed from Appendix B. 738 The changes that the working group will need to reach consensus on, 739 either to accept (as-is or with significant modifications) or reject 740 can be divided into three groups. 742 * A large set of changes, all addressing issues mentioned in 743 Section 1.1, were already present in the initial I-D so that there 744 has been the opportunity for working group discussion of them, 745 although that discussion has been quite limited so far. 747 As a result, a small set of these changes is marked, in 748 Appendix B, as having reached general acceptance. 750 That subset of these changes changes, together with the 751 organizational changes to support them are described in 752 Appendix A.1. 754 * Another large set of changes were made in draft -02. These mostly 755 concern the issues mentioned in Section 3.4 None of these changes 756 is yet considered to have reached general acceptance. 758 The organizational changes to support these changes are described 759 in Appendix A.2. 761 * There remain a set of potential changes for which a need is 762 expected but for which no text is yet available. 764 Such changes have associated Author Asides and are listed in 765 Appendix B. 767 The text for these changes is expected to be made available in 768 future document revisions and they will be processed then, in the 769 same way as other changes will be processed now. 771 If and when such changes reach general acceptance, they will be 772 explained in the appropriate subsection of Appendix A. 774 4. Introduction to NFSv4 Security 776 Because the basic approach to security issues is so similar for all 777 minor versions, this document applies to all NFSv4 minor versions. 778 The details of the transition to an NFSv4-wide document are discussed 779 in Sections 3.2 and 3.3. 781 NFSv4 security is built on facilities provided by the RPC layer, 782 including various auth flavors and and other security-related 783 services provided by RPC. 785 [Consensus Needed, Including List (Item #1a)}: Support for multiple 786 auth flavors can be provided. Not all of these actually provide 787 authentication, as discussed in Section 13. 789 * Support for RPCSEC_GSS is REQUIRED, although use of other auth 790 flavors is provided for. 792 This auth flavor provides for mutual authentication of the 793 principal making the request and the server performing it. 795 This auth flavor allows the client to request the provision of 796 encryption-based services to provide privacy or integrity for 797 specific requests. Although such services are often provided, on 798 a per-connectio basis, by RPC, this support is useful, when such 799 services are not supported or are otherwise unavailable. 801 * AUTH_SYS, provides identification of the principal making the 802 request but SHOULD NOT be used unless the client peer sending the 803 request can be authenticated and there is protection against the 804 modification of the request in flight. 806 Both of the above require specific RPC support such as that 807 provided by RPC-with-TLS [12]. 809 * AUTH_NONE does not provide identification of the principal making 810 the request so would only be used for requests for which there is 811 no such principal or for which it would irrelevant. 813 The restrictions mentioned above for AUTH_SYS apply to AUTH_NONE 814 as well. 816 [Consensus Needed, Including List (Item #1a)}: There are important 817 services that can be provided by RPC, when RPC-with-TLS or similar 818 transport-level facilities are available. 820 * Such services can provide data security to all requests on the 821 connection. This is to be preferred to data security provided by 822 the RPC auth flavor because it provides protection to the request 823 headers, because it applies to requests using all authentication 824 flavors, and because it is more likely to be offloadable. 826 * These services can authenticate the server to the client peer. 827 This is desirable since that authentication applies even when 828 AUTH_SYS or AUTH_NONE is used. 830 * The client-peer can be authenticated to the server at the time the 831 connection is set up. This is essential to allow AUTH_SYS to be 832 used with a modicum of security, based on the server's level of 833 trust with regard to the client peer. 835 [Consensus Needed (Item #2a)}: Because important security-related 836 services depend on the security services, rather the auth flavor, the 837 process of security negotiation, described in Section 15, has been 838 extended to provide for the negotiation of a appropriate connection 839 characteristics at connection time if the server's policy limits the 840 range of transports being used and also when use of a particular auth 841 flavor on a connection with inappropriate security characteristics 842 causes NFS4ERR_WRONGSEC to be returned, 844 [Consensus Needed (Item #1a)}: The authentication provided by RPC, is 845 used to provide the basis of authorization, which is discussed in 846 general in Section 6. This includes file access authorization, 847 discussed in Sections 7 through 9 and state modification 848 authorization, discussed in Section 11 849 File access is controlled by the server support for and client use of 850 certain recommended attributes, as described in Section 7.1. 851 Multiple file access model are provided for and the considerations 852 discussed in Section 8 apply to all of them. 854 * The mode attribute provides a POSIX-based authorization model, as 855 described in Section 7.3 857 * The ACL-related attributes acl, sacl, and dacl (the last two 858 introduced in NFSv4.1) support a finer grained authorization model 859 and provide additional securiy-related services. The structure of 860 ACLs is described in Section 5. 862 The ACL-based authorization model is described in Section 7.4 864 The additional security-related services are described in 865 Section 12. These also rely on the authentication provided by 866 RPC. 868 * Because there are two different approaches to file-access 869 authorization, servers might implement both, in which case the 870 associated attributes need to be coordinated as described in 871 Section 9. 873 * NFSv4.2 provides an file access authorization model oriented 874 toward Mandatory Access Control. It is described in Section 10. 875 For reasons described there, its security properties are hard to 876 analyze in detail and this document will not consider it as part 877 of the NFSv4 threat analysis. 879 Authorization of locking state modification is discussed in 880 Section 11. This form of authorization relies on the authentication 881 of the client peer as opposed to file access authorization, which 882 relies on authentication of the client principal. 884 4.1. NFSv4 Security Terminology 886 In this section, we will define the security-related terminology used 887 in this document. This is particularly important for NFSv4 because 888 many of the terms terms related to security in previous specification 889 may be hard to understand because their meanings have changed or have 890 been used inconsistently, resulting in confusion. 892 The following terms are listed in alphabetical order: 894 * "Access Control" denotes any control implemented by a server peer 895 to limit or regulate file system access to file system objects. 896 It includes but is not limited to authorization decisions. Access 897 control features can be divided into those wich are "Dicretionary" 898 or "Mandatory" as described below. 900 * "ACL" or "Access Control List" denotes a structure used, like the 901 mode (see below), to defines the privileges that individual users 902 have with respect to a given file. These structures provide more 903 options than modes with regard to the association of privileges 904 with specific users or group and often provide a finer-graned 905 privilege structure as well. This specification will have need to 906 refer to two types of ACLs. 908 The ACLs present in the acl, sacl, and dacl attributes are called 909 "NFSv4 ACLs". This ACL format, was modeled on the the semantics 910 of the SMB ACL format which provide a privilege model 911 substantially finer-grained than that provided by POSIX modes. 913 [Consensus needed (Item #56a)]: Another ACL type derives from an 914 attempt to define, within POSIX, a UNIX-oriented approach to ACLs 915 which was published as a draft (POSIX 1003.1e draft 17), but 916 subsequently withdrawn. Despite the withdrawal of this draft and 917 the working group's decision to adopt a native NFsv4 ACL format 918 based on SMB ACLs, this document will have to discuss these ACLs, 919 which we will term "UNIX ACLs" because many server file systems do 920 not support the finer-grained privilege model needed by the the 921 NFSv4 ACL model and because many clients are built on systems 922 whose only ACL-related API is based on the UNIX ACL model. 924 * "authentication" refers to a reliable determination that one 925 making a request is in fact who he purports to be. Often this 926 involves cryptographic means of demonstrating identity. 928 This is to be distinguished from "identification" which simply 929 provides a specified identity without any evidence to verify that 930 the identification is accurate. 932 In the past, these terms have been confused, most likely because 933 of confusion engendered by th use of the term "authentication 934 flavor" including flavors for which only identification is 935 provided or which do not provide even identification. 937 * "authorization" refers to the process of determining whether a 938 request is authorized, depending on the resources (e.g. files) to 939 be accessed, the identity of the entity on whose behalf the 940 request was issued, and the particular action to be performed. 942 Depending on the type of request, the entity whose identity is 943 referenced can be a user, a peer, or a combination of both. 945 Authorization is distinct from authentication. However, 946 performing authorization based on identities which have not been 947 authenticated makes secure operation impossible since use of 948 unauthenticated identities allows acceptance of requests that are 949 not properly authorized if the sender has the ability, as it 950 typically does, to pretend to be an authorized user/peer. 952 * "client" refers to the entity responsible for setting up a 953 connection. In most cases the client and the requester reside on 954 the same node but this not always the case for NFSv4 because of 955 the possibility of callback requests in which the server makes 956 some request of the client. 958 * "confidentiality" refers to the assurance provided, typically 959 through encryption, that the contents of requests and responses 960 are not inadvertently disclosed to unauthorized parties. 962 * "Discretionary Access Control" denotes forns of acces control, 963 that rely on a user, such as the owner, specifyling the privileges 964 that varous users are to have. 966 * "Mandatory Access Control" denotes forms of access control that 967 reflecct choices made by the server peer and based on its policy 968 and that are typicall based on the identity of the client peer 969 rather than the specfic user making a request. While such access 970 control is discussedin this document, it is important to note that 971 many forms of mandatory access control are discussed by other 972 NFsv4 documents and that there forms that are not standardized. 974 * [Consensus Needed, Entire Bulleted Item (Item #21a)]: "Mode" 975 designates a set of twelve flag bits used by POSIX-based systems 976 to control access to the file with which it is associated. In 977 NFSv4, there are represented by an OPTIONAL attribute, which, in 978 practical terms, is always supported by servers and expected by 979 clients. 981 The three high-order flags are generally accessed only by the 982 client while low-order bits are divided into three three-bit 983 fields, which give, in order of decreasing numeric value, the 984 privileges to be associated with, the owner of the file, other 985 users in the group owning the file, and users not in the above two 986 categories. 988 In most cases, the privileges associated with each successive 989 group are no greater than those for the previous group. Modes 990 whose privileges are of this form are referred to as "forward- 991 slope modes" because the privilege level proceeds downward as 992 successive groups of users are specified. Cases in which the 993 contrary possibility is realized are referred to as "reverse-slope 994 modes". 996 * "peer" refer to the entity which is charged with requesting or 997 performing a specified request as opposed to the entity on whose 998 behalf the request is requested or performed, the principal; 1000 * "principal" refers to the specific entity 9e.g. user) on whose 1001 behalf a request is being made. 1003 * "privacy", has in the past been used to refer, to what is now 1004 referred to as "confidentiality". 1006 over time, this usage has changed so that the word most often 1007 refers to applicability of data to a single individual and 1008 person's right to prevent its unauthorized disclosure 1010 As a result, many references to "privacy" in previous are no 1011 longer appropriate and really refer to confidentiality. 1013 The NFSv4 protocol has no way to determine whether particular data 1014 items raise privacy concerns (In the new sense). NFSv4 provides 1015 confidentiality whatever type of data is being accessed so that 1016 private data is kept private. 1018 * "integrity" refers to the assurance that data in a request has not 1019 been modified in the process of transmission. Such an assurance 1020 is generally provided b means of a cryptographic hash of the 1021 requests or response. 1023 * "requester" is the entity making a request, whether that entity is 1024 on the client-side, as it most often is (forward-direction 1025 request) or the server side, in th case of callback (reverse- 1026 direction requests) 1028 * "responder" is the entity performing a request, whether that 1029 entity is on the server side, as it most often is (forward- 1030 direction request) or the client side, in the case of callbacks 1031 (reverse-direction requests. 1033 * "server" refers to the entity to which the client connects. In 1034 most cases the client and the responder reside on the same node 1035 but this not always the case for NFSv4 because of the possibility 1036 of callback requests in which the server makes some request of the 1037 client. 1039 4.2. NFSv4 Security Scope Limitations 1041 This document describes the security features of the NFSv4 protocol 1042 and is unable to address security threats that are inherently outside 1043 the control of the protocol implementors. Such matters as out of 1044 this document's scope. 1046 As a way of clarifying the threats that this document, and the threat 1047 analysis in Section 17.4 can and cannot deal with, we list below the 1048 potential threats discussed Section 3.1 of [14] and review how, if at 1049 all, it is discussed in the current document. In cases in which the 1050 threat is dealt with in this document, distinctions are to be made 1051 between cases in which the issues have been dealt with directly or 1052 have been delegated to a lower layer on which the protocol is built 1053 and whether the issue has been addressed by the changes to NFSv4 1054 security made by this document. 1056 * Regarding the possibility of "Credential Theft or Compromise", 1057 this is not a matter that the NFSv4 protocols concern themselves 1058 with or can address directly, despite its importance for security. 1059 Depending on the auth flavor chosen, either the client (for 1060 AUTH_SYS) or a third-party (for RPCSEC_GSS), usually Kerberos, 1061 will be responsible for credential verification. 1063 Since experience has shown that credential compromise (e.g. 1064 through "phishing" attacks) is a common occurrence, this problem 1065 cannot be ignored, even though it the NFSv4's reliance on RPC 1066 facilities for authentication might be thought to make it out-of- 1067 scope as it would be RPC if had an effective solution to the 1068 issue. However, that the urgency of the situation this issue is 1069 such that will be discussed in Section 17.4.2, even though no 1070 definitive solutions to this issue are likely before this document 1071 is completed and published. 1073 Regardless of such issues, the likelihood of such compromise has 1074 had a role in decisions made regarding the acceptance and use of 1075 "superuser" credentials. The possibility of such compromise is 1076 also relevant to implementation of means to synchronize 1077 credentials when they are managed by the client, as described in 1078 Section 17.4.6.1 1080 * Regarding the possibility of "Cracking Encryption", prevention of 1081 this is responsibility of the NFSv4 protocols but it is one which 1082 has been delegated to RPC, so that its discussion in Security 1083 Considerations will rely on ..... and ... to manage encryption so 1084 as to limit the possibility of such unwanted encryption key 1085 discovery. 1087 * Regarding the possibility of "Infection of Malware and 1088 Ransomware", NFSv4 has no direct role in preventing such 1089 infection, but does have an important role in limiting its 1090 consequences, by limiting the the ability of Malware to access or 1091 modify data, through the file access authorization model supported 1092 by NFSv4 to limit access to authorized users. Of course, malware 1093 will be able to execute on behalf of the user mistakenly invoking 1094 it but the authorization model will server to limit the potential 1095 damage. 1097 The possibility of vertical privilege escalation is of concern as 1098 regard the possible elevation to "superuser" privileges. For this 1099 reason, this document recommends that any such escalation not be 1100 effective on the server, even if it happens on local clients for 1101 which NFSv4 has no role. 1103 Execution of a ransomeware-based attack requires the attacker to 1104 have the ability to read existing data and replacing it with an 1105 encrypted version together with the ability to temporarily hide 1106 the encryption from ongoing operations by intercepting requests to 1107 read encrypted data and substitute the unencrypted data. 1109 * Regarding the possibility of "Backdoors and Unpatched 1110 Vulnerabilities", it needs to be noted that the NFSv4 protocols do 1111 not specify any backdoors even though it is possible that might 1112 choose to provide such backdoors. Since it is not practical to 1113 specifically prohibit the existence of such backdoors nor would 1114 they be enforceable if written, this document will not attempt to 1115 do so. Instead, Section 17.2.3 will note the possibility of such 1116 backdoors and recommend against any such implementation, and 1117 include implementations containing backdoors in the category of 1118 insecure use that will not be dealt with in Section 17.4. 1120 Although it is expected that vulnerabilities will be due to 1121 incorrect implementations and thus outside the scope of this 1122 document, the possibility of a protocol design errors cannot be 1123 excluded. In dealing with such eventualities, it is likely that 1124 complete remediation would require co-ordinated changes on the 1125 client and server 1127 * Regarding the possibility of "Privilege Escalation", NFSv4 has 1128 dealt with the possibility of vertical escalation by not allowing 1129 a client-local escalation to superuser privileges to be effective 1130 on the server. 1132 With regard to horizontal "escalation", NFSv4 provides for the use 1133 of various means RPC authentication of principals but relies on 1134 the client operating system to make sure that one user principal 1135 cannot masquerade as another. 1137 * Regarding the possibility of "Human Error and Deliberate 1138 Misconfiguration", the approach taken is to limit the need for the 1139 server to make complicated decisions regarding the security 1140 requirements of each section of its namespace, with many 1141 opportunities for misconfiguration, if the chosen security 1142 requirements are insufficiently restrictive. This is in contrast 1143 to previous specifications which made such configuration the 1144 centerpiece of the security approach. 1146 Although it is possible to create configurations where certain 1147 data, generally publicly accessible, are to be made available 1148 without encryption, this is expected to be a rarely used option 1149 with the possibility of in-transit modification kept in mind 1150 before adopting such use. 1152 * Regarding the possibility of "Physical Theft of Storage Media", 1153 this a matter which, while of concern to those deploying NFSv4 1154 server, will be considered out-of-scope since there is nothing 1155 that the protocol could do to deal with this threat. 1157 * Regarding the possibility of "Network Eavesdropping", when the 1158 protocol implementation follows the recommendations in this 1159 document, the protocol's use of RPC facilities is designed, 1160 through the consistent use of encryption to make it difficult for 1161 an attacker to have access to the data being transmitted, to 1162 modify it, or inject requests into an existing data stream. 1164 The possibility of an attacker with access to the network creating 1165 a new connection is best considered as a case of the attacker 1166 pretending to be a client and is addressed in Section 17.4.3. 1168 * Regarding the possibility of "Insecure Images, Software and 1169 Firmware", while attention to such matters is important for those 1170 deploying NFSv4, it is important to note that these are matters 1171 outside the control the NFSv4, which has to assume that the 1172 infrastructure it is built is working properly. As a result, this 1173 document will not deal with the possibility of such threats. 1175 5. Structure of NFSv4 Access Control Lists 1177 NFSv4 Access Control Lists consisting of multiple Access Control 1178 Elements, while originally designed to support a more flexible 1179 authorization model, have multiple uses within NFSv4, with the use of 1180 each element depending on its type, as defined in Section 5.2 1182 * They may be used to provide a more flexible authorization model as 1183 described in Section 7.4. This involves use of Access Control 1184 Entries of the ALLOW and DENY types. 1186 * They may be used to provide the security-related services 1187 described in Section 12. This involves use of Access Control 1188 Entries of the AUDIT and ALARM types. 1190 Subsections of this section define the structure of NFSv4 ACLs and 1191 discuss ACL-related matters that apply to multiple uses of NFSv4 1192 ACLs, including the definitions of the acl and aclsupport attributes. 1194 Matters that relate to only a single one of these use classes, 1195 including the definition of the NFSv4.1-specific attributes dacl and 1196 sacl, are discussed in subsections of Sections 7.4 or 12. 1198 5.1. Access Control Entries 1200 The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each 1201 contain an array of Access Control Entries (ACEs) that are associated 1202 with the file system object. The client can set and get these 1203 attributes attribute, the server is responsible for using the ACL- 1204 related attributes to perform access control. The client can use the 1205 OPEN or ACCESS operations to check access without modifying or 1206 explicitly reading data or metadata. 1208 The NFS ACE structure is defined as follows: 1210 typedef uint32_t acetype4; 1212 typedef uint32_t aceflag4; 1214 typedef uint32_t acemask4; 1216 struct nfsace4 { 1217 acetype4 type; 1218 aceflag4 flag; 1219 acemask4 access_mask; 1220 utf8str_mixed who; 1221 }; 1223 5.2. ACE Type 1225 The constants used for the type field (acetype4) are as follows: 1227 const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; 1228 const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; 1229 const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; 1230 const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; 1232 All four are permitted in the acl attribute. For NFSv4.1 and beyond, 1233 only the ALLOWED and DENIED types may be used in the dacl attribute, 1234 and only the AUDIT and ALARM types.x used in the sacl attribute. 1236 +==============================+==============+====================+ 1237 | Value | Abbreviation | Description | 1238 +==============================+==============+====================+ 1239 | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants | 1240 | | | the ability to | 1241 | | | perform the action | 1242 | | | specified in | 1243 | | | acemask4 to the | 1244 | | | file or directory. | 1245 +------------------------------+--------------+--------------------+ 1246 | ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies | 1247 | | | the ability to | 1248 | | | perform the action | 1249 | | | specified in | 1250 | | | acemask4 to the | 1251 | | | file or directory. | 1252 +------------------------------+--------------+--------------------+ 1253 | ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- | 1254 | | | dependent way) any | 1255 | | | attempt to | 1256 | | | perform, for the | 1257 | | | file or directory, | 1258 | | | any of the actions | 1259 | | | specified in | 1260 | | | acemask4. | 1261 +------------------------------+--------------+--------------------+ 1262 | ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm | 1263 | | | (in a system- | 1264 | | | dependent way) any | 1265 | | | attempt to | 1266 | | | perform, for the | 1267 | | | file or directory, | 1268 | | | any of the actions | 1269 | | | specified in | 1270 | | | acemask4. | 1271 +------------------------------+--------------+--------------------+ 1273 Table 1 1275 The "Abbreviation" column denotes how the types will be referred to 1276 throughout the rest of this document. 1278 5.3. ACE Access Mask 1280 The bitmask constants used for the access mask field of the ACE are 1281 as follows: 1283 const ACE4_READ_DATA = 0x00000001; 1284 const ACE4_LIST_DIRECTORY = 0x00000001; 1285 const ACE4_WRITE_DATA = 0x00000002; 1286 const ACE4_ADD_FILE = 0x00000002; 1287 const ACE4_APPEND_DATA = 0x00000004; 1288 const ACE4_ADD_SUBDIRECTORY = 0x00000004; 1289 const ACE4_READ_NAMED_ATTRS = 0x00000008; 1290 const ACE4_WRITE_NAMED_ATTRS = 0x00000010; 1291 const ACE4_EXECUTE = 0x00000020; 1292 const ACE4_DELETE_CHILD = 0x00000040; 1293 const ACE4_READ_ATTRIBUTES = 0x00000080; 1294 const ACE4_WRITE_ATTRIBUTES = 0x00000100; 1295 const ACE4_WRITE_RETENTION = 0x00000200; 1296 const ACE4_WRITE_RETENTION_HOLD = 0x00000400; 1298 const ACE4_DELETE = 0x00010000; 1299 const ACE4_READ_ACL = 0x00020000; 1300 const ACE4_WRITE_ACL = 0x00040000; 1301 const ACE4_WRITE_OWNER = 0x00080000; 1302 const ACE4_SYNCHRONIZE = 0x00100000; 1304 Note that some masks have coincident values, for example, 1305 ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries 1306 ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are 1307 intended to be used with directory objects, while ACE4_READ_DATA, 1308 ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with 1309 non-directory objects. 1311 5.4. Uses of Mask Bits 1313 [Author Aside]: Because this section has been moved to be part of a 1314 general description of ACEs, not limited to authorization, the 1315 descriptions no longer refer to permissions but rather to actions. 1316 This is best considered a purely editorial change, but, to allow for 1317 possible disagreement on the matter, it will be considered, here and 1318 in Appendix B, as consensus item #3. 1320 [Author Aside]: In a large number of places, SHOULD is used 1321 inappropriately, since there appear to be no valid reasons to allow a 1322 server to ignore what might well be a requirement. Such changes are 1323 not noted individually below. However, they will be considered, here 1324 and in Appendix B, as consensus item #4a. 1326 [Author Aside}: In a significant number of cases the ACCESS operation 1327 is not listed as a operation affected by the mask bit. These 1328 additions are not noted individually below. However, they will be 1329 considered, here and in Appendix B, as consensus item #5a. 1331 [Author Aside, Including List]: In a number of cases, there are 1332 additional changes which go beyond editorial or arguably do so. 1333 These will be marked as their own consensus items usually with an 1334 accompanying author aside but without necessarily citing the previous 1335 treatment. These include: 1337 * Revisions were necessary to clarify the relationship between 1338 READ_DATA and EXECUTE. These are part of consensus item #7a. 1340 * Revisions were necessary to clarify the relationship between 1341 WRITE_DATA and APPEND_DATA. These are part of consensus item #8a. 1343 * Clarification of the handling of RENAME by ADD_SUBDIRECTORY. This 1344 is part of consensus item #9a. 1346 * Revisions in handling of the masks WRITE_RETENTION and 1347 WRITE_RETENTION_HOLD. These are parts of consensus items #10a. 1349 [Author Aside]: Because of the need to address sticky-bit issues as 1350 part of of the ACE mask descriptions, it is appropriate to introduce 1351 the subject here. 1353 [Consensus Item (Item #6a)]: Despite the fact that NFSv4 ACLs and 1354 mode bits are separate means of authorization, it has been necessary, 1355 even if only for the purpose of providing compatibility with earlier 1356 implementations, to introduce the issue here, since reference to this 1357 mode bit are necessary to resolve issues regard directory entry 1358 deletion, as is done in Section 5.6. 1360 [Consensus Item, Including List (Item #6a): The full description of 1361 the role of the sticky-bit appears in Section 7.3.1. In evaluating 1362 and understanding the relationship between the handling of this bit 1363 when NFSv4 ACLs are used and when they are not, the following points 1364 need to be kept in mind: 1366 * This is troublesome in that it combines data normally assigned to 1367 two different authorization models and breaks the overall 1368 architectural arrangement in which the mask bits represent the 1369 mode bits but provide a finer granularity of control. 1371 * It might have been possible to conform to the existing 1372 architectural model if a new mask bit were created to represent to 1373 directory sticky bit. It is probably too late to so now, even 1374 though it would be allowed as an NFSv4.2 extension. 1376 * The new treatment in Section 5.6 is more restrictive than the 1377 previous one appearing in Section 5.6.1. This raises potential 1378 compatibility issues since the new treatment, while designed to 1379 address the same issues was designed to match existing Unix 1380 handling of this bit. 1382 * This handling initially addresses REMOVE and does not address 1383 directory sticky bit semantics with regard to RENAME. Whether it 1384 will do so is still uncertain. 1386 * The handling of this mode bit was not documented in previous 1387 specifications. However, there is a preliminary attempt to do so 1388 in Section 7.3.1. The reason for doing so, is that given the Unix 1389 orientation of the mode attribute, it is likely that servers 1390 currently implement this, even though there is no NFSv4 1391 documentation of this semantics 1393 This treatment needs to be checked for compatibility issues and 1394 also to establish a model that we might adapt to the case of NFSv4 1395 ACLs. 1397 * In the long term, it would make more sense to allow the client 1398 rather than the server to have the primary role in determining the 1399 semantics for things like this. That does not seem possible right 1400 now but it is worth considering. 1402 ACE4_READ_DATA 1404 Operation(s) affected: 1405 READ 1407 OPEN 1409 ACCESS 1411 Discussion: 1412 The action of reading the data to the data of the file. 1414 [Previous Treatment (Item #7a)]: Servers SHOULD allow a user 1415 the ability to read the data of the file when only the 1416 ACE4_EXECUTE access mask bit is allowed. 1418 [Author Aside]: The treatment needs to be clarified to make it 1419 appropriate to all ACE types. 1421 [Consensus Needed (Item #7a)]: When used to handle READ or OPEN 1422 operations, the handling MUST be identical whether this bit, 1423 ACE4_EXECUTE, or both are present, as the server has no way of 1424 determining whether a file is being read for execution are not. 1425 The only occasion for different handling is in construction of 1426 a corresponding mode or in responding to the ACCESS operation. 1428 ACE4_LIST_DIRECTORY 1430 Operation(s) affected: 1431 READDIR 1433 Discussion: 1434 The action of listing the contents of a directory. 1436 ACE4_WRITE_DATA 1438 Operation(s) affected: 1439 WRITE 1441 OPEN 1443 ACCESS 1445 SETATTR of size 1447 Discussion: 1448 [Author Aside]: Needs to be revised to deal with issues related 1449 to the interaction of WRITE_DATA and APPEND_DATA. 1451 [Consensus Needed (Item #8a)]: The action of modifying existing 1452 data bytes within a file's current data. 1454 [Consensus Needed (Item #8a)]: As there is no way for the 1455 server to decide, in processing an OPEN or ACCESS request, 1456 whether subsequent WRITEs will extend the file or not, the 1457 server will, in processing an OPEN treat masks containing only 1458 WRITE_DATA, only APPEND_DATA, or both identically. 1460 [Consensus Needed (Item #8a)]: In processing a WRITE request, 1461 the server is presumed to have the to determine whether the 1462 current request extends the file and whether it modifies bytes 1463 already in the file. 1465 [Consensus Needed (Item #8a)]: ACE4_WRITE_DATA is required to 1466 process a WRITE which spans pre-existing byte in the file, 1467 whether the file is extended or not. 1469 ACE4_ADD_FILE 1471 Operation(s) affected: 1473 CREATE 1475 LINK 1477 OPEN 1479 RENAME 1481 Discussion: 1482 The action of adding a new file in a directory. The CREATE 1483 operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, 1484 NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not included because 1485 it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when 1486 used to create a regular file. LINK and RENAME are always 1487 affected. 1489 ACE4_APPEND_DATA 1491 Operation(s) affected: 1492 WRITE 1494 ACCESS 1496 OPEN 1498 SETATTR of size 1500 Discussion: 1501 [Author Aside]: Also needs to be revised to deal with issues 1502 related to the interaction of WRITE_DATA and APPEND_DATA. 1504 The action of modifying a file's data, but only starting at 1505 EOF. This allows for the specification of append-only files, 1506 by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the 1507 same user or group. 1509 [Consensus Needed (Item #8a)]: As there is no way for the 1510 server to decide, in processing an OPEN or ACCESS request, 1511 whether subsequent WRITEs will extend the file or not, the 1512 server will treat masks containing only WRITE_DATA, only 1513 APPEND_DATA or both, identically. 1515 [Consensus Needed (Item #8a)]: If the server is processing a 1516 WRITE request and the area to be written extends beyond the 1517 existing EOF of the file then the state of APPEND_DATA mask bit 1518 is consulted to determine whether the operation is permitted or 1519 whether alarm or audit activities are to be performed. If a 1520 file has an NFSv4 ACL allowing only APPEND_DATA (and not 1521 WRITE_DATA) and a WRITE request is made at an offset below EOF, 1522 the server MUST return NFS4ERR_ACCESS. 1524 [Consensus Needed (Item #8a)]: If the server is processing a 1525 WRITE request and the area to be written does not extend beyond 1526 the existing EOF of the file then the state of APPEND_DATA mask 1527 bit does not need to be consulted to determine whether the 1528 operation is permitted or whether alarm or audit activities are 1529 to be performed. In this case, only the WRITE_DATA mask bit 1530 needs to be checked to determine whether the WRITE is 1531 authorized. 1533 ACE4_ADD_SUBDIRECTORY 1535 Operation(s) affected: 1536 CREATE 1538 RENAME 1540 Discussion: 1541 [Author Aside]: The RENAME cases need to be limited to the 1542 renaming of directories, rather than saying, "The RENAME 1543 operating is always affected." 1545 [Consensus Needed (Item #9a)]: The action of creating a 1546 subdirectory in a directory. The CREATE operation is affected 1547 when nfs_ftype4 is NF4DIR. The RENAME operation is always 1548 affected when directories are renamed and the target directory 1549 NFSv4 ACL contains the mask ACE4_ADD_SUBDIRECTORY. 1551 ACE4_READ_NAMED_ATTRS 1553 Operation(s) affected: 1554 OPENATTR 1556 Discussion: 1557 The action of reading the named attributes of a file or of 1558 looking up the named attribute directory. OPENATTR is affected 1559 when it is not used to create a named attribute directory. 1560 This is when 1) createdir is TRUE, but a named attribute 1561 directory already exists, or 2) createdir is FALSE. 1563 ACE4_WRITE_NAMED_ATTRS 1565 Operation(s) affected: 1566 OPENATTR 1568 Discussion: 1569 The action of writing the named attributes of a file or 1570 creating a named attribute directory. OPENATTR is affected 1571 when it is used to create a named attribute directory. This is 1572 when createdir is TRUE and no named attribute directory exists. 1573 The ability to check whether or not a named attribute directory 1574 exists depends on the ability to look it up; therefore, users 1575 also need the ACE4_READ_NAMED_ATTRS permission in order to 1576 create a named attribute directory. 1578 ACE4_EXECUTE 1580 Operation(s) affected: 1581 READ 1583 OPEN 1585 ACCESS 1587 REMOVE 1589 RENAME 1591 LINK 1593 CREATE 1595 Discussion: 1596 The action of reading a file in order to execute it. 1598 Servers MUST allow a user the ability to read the data of the 1599 file when only the ACE4_EXECUTE access mask bit is allowed. 1600 This is because there is no way to execute a file without 1601 reading the contents. Though a server may treat ACE4_EXECUTE 1602 and ACE4_READ_DATA bits identically when deciding to permit a 1603 READ or OPEN operation, it MUST still allow the two bits to be 1604 set independently in NFSv4 ACLs, and distinguish between them 1605 when replying to ACCESS operations. In particular, servers 1606 MUST NOT silently turn on one of the two bits when the other is 1607 set, as that would make it impossible for the client to 1608 correctly enforce the distinction between read and execute 1609 permissions. 1611 As an example, following a SETATTR of the following NFSv4 ACL: 1613 nfsuser:ACE4_EXECUTE:ALLOW 1615 A subsequent GETATTR of acl attribute for that file will 1616 return: 1618 nfsuser:ACE4_EXECUTE:ALLOW 1620 and MUST NOT return: 1622 nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW 1624 ACE4_EXECUTE 1626 Operation(s) affected: 1627 LOOKUP 1629 Discussion: 1630 The action of traversing/searching a directory. 1632 ACE4_DELETE_CHILD 1634 Operation(s) affected: 1635 REMOVE 1637 RENAME 1639 Discussion: 1640 The action of deleting a file or directory within a directory. 1641 See Section 5.6 for information on now ACE4_DELETE and 1642 ACE4_DELETE_CHILD are to interact. 1644 ACE4_READ_ATTRIBUTES 1646 Operation(s) affected: 1647 GETATTR of file system object attributes 1649 VERIFY 1651 NVERIFY 1653 READDIR 1655 Discussion: 1656 The action of reading basic attributes (non-ACLs) of a file. 1657 On a UNIX system, such basic attributes can be thought of as 1658 the stat-level attributes. Allowing this access mask bit would 1659 mean that the entity can execute "ls -l" and stat. If a 1660 READDIR operation requests attributes, this mask need s to be 1661 be allowed for the READDIR to succeed. 1663 ACE4_WRITE_ATTRIBUTES 1665 Operation(s) affected: 1666 SETATTR of time_access_set, time_backup, time_create, 1667 time_modify_set, mimetype, hidden, system. 1669 Discussion: 1670 The action of changing the times associated with a file or 1671 directory to an arbitrary value. Also permission to change the 1672 mimetype, hidden, and system attributes. A user having 1673 ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set 1674 the times associated with a file to the current server time. 1676 ACE4_WRITE_RETENTION 1678 Operation(s) affected: 1679 SETATTR of retention_set, retentevt_set. 1681 Discussion: 1682 The action of modifying the durations for event and non-event- 1683 based retention. Also includes enabling event and non-event- 1684 based retention. 1686 [Author Aside]: The use of "MAY" here ignores the potential for 1687 harm which unexpected modification of the associated attributes 1688 might cause for security/compliance. 1690 [Previous Treatment]: A server MAY behave such that setting 1691 ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION. 1693 [Consensus Needed (Items #10a, #11a)]: Options for coarser- 1694 grained treatment involving this mask bit are discussed in 1695 Section 5.5 1697 ACE4_WRITE_RETENTION_HOLD 1699 Operation(s) affected: 1700 SETATTR of retention_hold. 1702 Discussion: 1703 The action of modifying the administration retention holds. 1705 [Previous Treatment]: A server MAY map ACE4_WRITE_ATTRIBUTES to 1706 ACE_WRITE_RETENTION_HOLD. 1708 [Author Aside]: The use of "MAY" here ignores the potential for 1709 harm which unexpected modification of the associated attributes 1710 might cause for security/compliance. 1712 [Consensus Needed (Items #10a, #11a)]: Options for coarser- 1713 grained treatment of this mask bit are discussed in Section 5.5 1715 ACE4_DELETE 1717 Operation(s) affected: 1718 REMOVE 1720 Discussion: 1721 The action of deleting the associated file or directory. See 1722 Section 5.6 for information on how ACE4_DELETE and 1723 ACE4_DELETE_CHILD are to interact. 1725 ACE4_READ_ACL 1727 Operation(s) affected: 1728 GETATTR of acl, dacl, or sacl 1730 NVERIFY 1732 VERIFY 1734 Discussion: 1735 The action of reading the NFSv4 ACL. 1737 ACE4_WRITE_ACL 1739 Operation(s) affected: 1740 SETATTR of acl and mode 1742 Discussion: 1743 The action of modifying the acl or mode attributes. 1745 ACE4_WRITE_OWNER 1747 Operation(s) affected: 1748 SETATTR of owner and owner_group 1750 Discussion: 1751 The action of modifying the owner or owner_group attributes. 1752 On UNIX systems, this done by executing chown() and chgrp(). 1754 ACE4_SYNCHRONIZE 1755 Operation(s) affected: 1756 NONE 1758 Discussion: 1759 Permission to use the file object as a synchronization 1760 primitive for interprocess communication. This permission is 1761 not enforced or interpreted by the NFSv4.1 server on behalf of 1762 the client. 1764 Typically, the ACE4_SYNCHRONIZE permission is only meaningful 1765 on local file systems, i.e., file systems not accessed via 1766 NFSv4.1. The reason that the permission bit exists is that 1767 some operating environments, such as Windows, use 1768 ACE4_SYNCHRONIZE. 1770 For example, if a client copies a file that has 1771 ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 1772 server, and then later copies the file from the NFSv4.1 server 1773 to a local file system, it is likely that if ACE4_SYNCHRONIZE 1774 was set in the original file, the client will want it set in 1775 the second copy. The first copy will not have the permission 1776 set unless the NFSv4.1 server has the means to set the 1777 ACE4_SYNCHRONIZE bit. The second copy will not have the 1778 permission set unless the NFSv4.1 server has the means to 1779 retrieve the ACE4_SYNCHRONIZE bit. 1781 5.5. Requirements and Recommendations Regarding Mask Granularity 1783 This is new section which replaces material formerly in the previous 1784 section, cited here as "Previous Treatment. The new material, 1785 constituting the remainder of the section is proposed to replace it. 1786 All such unannotated material is to be considered as part of 1787 consensus item #11b. 1789 [Previous Treatment (Item #11b)]: Server implementations need not 1790 provide the granularity of control that is implied by this list of 1791 masks. For example, POSIX-based systems might not distinguish 1792 ACE4_APPEND_DATA (the ability to append to a file) from 1793 ACE4_WRITE_DATA (the ability to modify existing contents); both masks 1794 would be tied to a single "write" permission bit. When such a server 1795 returns attributes to the client that contain such masks, it would 1796 show ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the the 1797 write permission bit is enabled. 1799 [Previous Treatment (Item #11b)]: If a server receives a SETATTR 1800 request that it cannot accurately implement, it should err in the 1801 direction of more restricted access, except in the previously 1802 discussed cases of execute and read. For example, suppose a server 1803 cannot distinguish overwriting data from appending new data, as 1804 described in the previous paragraph. If a client submits an ALLOW 1805 ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice 1806 versa), the server should either turn off ACE4_APPEND_DATA or reject 1807 the request with NFS4ERR_ATTRNOTSUPP. 1809 [Author Aside]: Giving servers a general freedom to to not support 1810 the masks defined in this section creates an unacceptable level of 1811 potential interoperability problems. With regard to the specific 1812 example given, it is hard to imagine a server incapable of 1813 distinguishing a write to an offset within existing file and one 1814 beyond it. This applies whether the server in question is 1815 implemented within a POSIX-based system or not. It is true that a 1816 server that used the unmodified POSIX interface to interact with the 1817 file system, rather than a purpose-built VFS, would face this 1818 difficulty, but it not clear that that fact justifies the client 1819 compatibility issues that accommodating this behavior in the protocol 1820 would generate. A further difficulty with the previous treatment is 1821 that it at variance with the approach to other cases in which ACEs 1822 are stored with the understanding that implementations of other 1823 protocols might be responsible for enforcement. 1825 [Author Aside]: A replacement clearly needs to be based on the idea 1826 that these mask bits were included in NFSv4 for a reason, and that 1827 exceptions need to be justified, and take interoperability issues 1828 into account. The treatment below attempts to do that. 1830 All implementations of the acl, dacl, and sacl attributes SHOULD 1831 follow the definitions provided above in Section 5.4, which allow 1832 finer-grained control of the actions allowed to specific users than 1833 is provided by the mode attribute. Valid reasons to bypass this 1834 guidance include the need for compatibility with clients expecting a 1835 coarser-grained implementation. 1837 The specific cases in which servers may validly provide coarser- 1838 grained implementations are discussed below. 1840 Servers not providing the mask granularity described in Section 5.4 1841 MUST NOT treat masks other than described in that section except as 1842 listed below. 1844 * Servers that do not distinguish between WRITE_DATA and APPEND_DATA 1845 need to make it clear to clients that support for append-only 1846 files is not present. To do that, requests to set NFSv4 ACLs 1847 where the handling for these two masks are different for any 1848 specified user or group are to be rejected with 1849 NFS4ERR_ATTRNOTSUPP. 1851 * [Consensus Needed (Items #10b, #11b)]: Servers that combine either 1852 of the masks WRITE_RETENTION or WRITE_RETENTION_HOLD with 1853 WRITE_ATTRIBUTES need to make it clear to clients that the finer- 1854 grained treatment normally expected is not available. To do that, 1855 requests to set NFSv4 ACLs in which the two combined masks are 1856 explicitly assigned different permission states (i.e. one is 1857 ALLOWED while the other is DENIED) for any specific user or group 1858 are to be rejected with NFS4ERR_ATTRNOTSUPP. 1860 The above are in line with the requirement that attempts to set NFSv4 1861 ACLs that the server cannot enforce, it needs to be clear that there 1862 are cases in which such ACLs need to be set with the expectation that 1863 enforcement will be done by the local file system or by another file 1864 access protocol. In particular, 1866 * In handling the mask bit SYNCHRONIZE, the server is not 1867 responsible for enforcement and so can accept NFSv4 ACLs it has no 1868 way of enforcing. 1870 * When mask bits refers to an OPTIONAL feature that the server does 1871 not support such as named attributes or retention attributes, the 1872 server is allowed to accept NFSv4 ACLs containing mask bits 1873 associated with the unimplemented feature, even though there is no 1874 way these cold be enforced. The expectation is that the files 1875 might be accessed by other protocols having such support or might 1876 be copied, together with associated ACLs to servers capable of 1877 enforcing them. 1879 5.6. Handling of Deletion 1881 [Author Aside]: This section, exclusive of subsections contains a 1882 proposal for the revision of the ACL-based handling of requests to 1883 delete directory entries. All unannotated material within it is to 1884 be considered part of consensus item #12a. 1886 [Author Aside]: The associated previous treatment is to be found in 1887 Section 5.6.1 1889 This section describes the handling requests of that involve deletion 1890 of a directory entry. It needs to be noted that: 1892 * Modification or transfer of a directory, as happens in RENAME is 1893 not covered. 1895 * The deletion of the file's data is dealt with separately as this, 1896 like a truncation to length zero, requires ACE4_WRITE_DATA. 1898 In general, the recognition of such an operation for 1899 authorization/auditing/alarm depends on either of two bits mask bits 1900 being set: ACE4_MASK_DELETE on the file being deleted and 1901 ACE4_MASK_DELETE_CHILD on the directory from which the entry is being 1902 deleted. 1904 In the case of authorization, the above applies even when one of the 1905 bits is allowed and the other is explicitly denied. 1907 [Consensus Items, Including List (#6b, #12a): When neither of the 1908 mask bits is set, the result is normally negative. That is, 1909 permission is denied and no audit or alarm event is recognized. 1910 However, in the case of authorization, the server MAY make permission 1911 dependent on the setting of MODE4_SVTX if the mode attribute is 1912 supported, as follows: 1914 * If that bit not set, allow the removal if and only if 1915 ACE4_ADD_FILE is permitted. 1917 * If that bit is set, allow the removal if and only if ACE4_ADD_FILE 1918 is permitted and the requester is the owner of the target. 1920 5.6.1. Previous Handling of Deletion 1922 [Author Aside]: This section contains the former content of 1923 Section 5.6. All unannotated paragraphs within it are to be 1924 considered the Previous Treatment associated with consensus item 1925 #12b. 1927 [Author Aside, Including List]: Listed below are some of the reasons 1928 that I have tried to replace the existing treatment rather than 1929 address the specific issues mentioned here and in later asides. 1931 * The fact that there is no clear message about what servers are to 1932 do and about whether behavior clients might rely rely on. This 1933 derives in turn from the use of "SHOULD" in contexts in which it 1934 is clearly not appropriate, combined with non-normative reports of 1935 what some systems do, and the statement that the approach 1936 suggested is a way of providing "something like traditional UNIX- 1937 like semantics". 1939 * The complexity of the approach without any indication that there 1940 is a need for such complexity makes me doubtful that anything was 1941 actually implemented, especially since the text is so wishy-washy 1942 about the need for server implementation. The probability that it 1943 would be implemented so widely that clients might depend on it is 1944 even more remote. 1946 * The fact that how audit and alarm issues are to be dealt with is 1947 not addressed at all. 1949 * The fact that this treatment combines ACL data with mode bit 1950 information in a confused way without any consideration of the 1951 fact that the mode attribute is OPTIONAL. 1953 Two access mask bits govern the ability to delete a directory entry: 1954 ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD 1955 on the containing directory (the "parent"). 1957 Many systems also take the "sticky bit" (MODE4_SVTX) on a directory 1958 to allow unlink only to a user that owns either the target or the 1959 parent; on some such systems the decision also depends on whether the 1960 target is writable. 1962 Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the 1963 target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that 1964 this is true even if the parent or target explicitly denies one of 1965 these permissions.) 1967 If the ACLs in question neither explicitly ALLOW nor DENY either of 1968 the above, and if MODE4_SVTX is not set on the parent, then the 1969 server SHOULD allow the removal if and only if ACE4_ADD_FILE is 1970 permitted. In the case where MODE4_SVTX is set, the server may also 1971 require the remover to own either the parent or the target, or may 1972 require the target to be writable. 1974 This allows servers to support something close to traditional UNIX- 1975 like semantics, with ACE4_ADD_FILE taking the place of the write bit. 1977 5.7. ACE flag bits 1979 The bitmask constants used for the flag field are as follows: 1981 const ACE4_FILE_INHERIT_ACE = 0x00000001; 1982 const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; 1983 const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; 1984 const ACE4_INHERIT_ONLY_ACE = 0x00000008; 1985 const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; 1986 const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; 1987 const ACE4_IDENTIFIER_GROUP = 0x00000040; 1988 const ACE4_INHERITED_ACE = 0x00000080; 1990 [Author Aside]: Although there are multiple distinct issues that 1991 might need to be changed, in the interest of simplifying the review, 1992 all such issues within this section will be considered part of 1993 Consensus Item #13a with a single revised treatment addressing all 1994 the issues noted. 1996 [Previous Treatment]: A server need not support any of these flags. 1998 [Author Aside]: It is hard to understand why such broad license is 1999 granted to the server, leaving the client to deal, without an 2000 explicit non-support indication, with 256 possible combinations of 2001 supported and unsupported flags. If there were specific issues with 2002 some flags that makes it reasonable for a server not to support them, 2003 then these need to be specifically noted. Also problematic is the 2004 use of the term "need not", suggesting that the server does not need 2005 any justification for choosing these flags, defined by the protocol. 2006 At least it needs to be said that the server SHOULD support the 2007 defined ACE flags. After all they were included in the protocol for 2008 a reason. 2010 [Previous Treatment]: If the server supports flags that are similar 2011 to, but not exactly the same as, these flags, the implementation may 2012 define a mapping between the protocol-defined flags and the 2013 implementation-defined flags. 2015 [Author Aside]: The above dealing how an implementation might store 2016 the bits it supports, while valid, is out-of-scope and need to be 2017 deleted. 2019 [Previous Treatment]: For example, suppose a client tries to set an 2020 ACE with ACE4_FILE_INHERIT_ACE set but not 2021 ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form 2022 of ACL inheritance, the server should reject the request with 2023 NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE" 2024 flag that applies to both files and directories, the server may 2025 reject the request (i.e., requiring the client to set both the file 2026 and directory inheritance flags). The server may also accept the 2027 request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag. 2029 ]Author Aside]: What is the possible for justification for accepting 2030 a request asking you do something and then, without notice to the 2031 client do, something else. I believe there is none. 2033 Consensus Needed (Item #13a)]: Servers SHOULD support the flag bits 2034 defined above as described in Section 5.8. When a server which does 2035 not support all the flags bits receives a request to set an NFSv4 ACL 2036 containing an ACE with an unsupported flag bit set the server MUST 2037 reject the request with NFS4ERR_ATTRNOTSUPP. 2039 Consensus Needed (Item #13a)]: The case of servers which do not 2040 provide support for particular flag combinations is to be treated 2041 similarly. If a server supports a single "inherit ACE" flag that 2042 applies to both files and directories, receives a request set an 2043 NFSv4 ACL with ACE ACE4_FILE_INHERIT_ACE set but 2044 ACE4_DIRECTORY_INHERIT_ACE not set, it MUST reject the request with 2045 NFS4ERR_ATTRNOTSUPP. 2047 5.8. Details Regarding ACE Flag Bits 2049 ACE4_FILE_INHERIT_ACE 2050 Any non-directory file in any sub-directory will get this ACE 2051 inherited. 2053 ACE4_DIRECTORY_INHERIT_ACE 2054 Can be placed on a directory and indicates that this ACE is to be 2055 added to each new directory created. 2057 If this flag is set in an ACE in an NFSv4 ACL attribute to be set 2058 on a non-directory file system object, the operation attempting to 2059 set the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP. 2061 ACE4_NO_PROPAGATE_INHERIT_ACE 2062 Can be placed on a directory. This flag tells the server that 2063 inheritance of this ACE is to stop at newly created child 2064 directories. 2066 ACE4_INHERIT_ONLY_ACE 2067 Can be placed on a directory but does not apply to the directory; 2068 ALLOW and DENY ACEs with this bit set do not affect access to the 2069 directory, and AUDIT and ALARM ACEs with this bit set do not 2070 trigger log or alarm events. Such ACEs only take effect once they 2071 are applied (with this bit cleared) to newly created files and 2072 directories as specified by the ACE4_FILE_INHERIT_ACE and 2073 ACE4_DIRECTORY_INHERIT_ACE flags. 2075 If this flag is present on an ACE, but neither 2076 ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, 2077 then an operation attempting to set such an attribute SHOULD fail 2078 with NFS4ERR_ATTRNOTSUPP. 2080 ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG 2081 The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and 2082 ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on 2083 ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE 2084 (ALARM) ACE types. If during the processing of the file's NFSv4 2085 ACL, the server encounters an AUDIT or ALARM ACE that matches the 2086 principal attempting the OPEN, the server notes that fact, and the 2087 presence, if any, of the SUCCESS and FAILED flags encountered in 2088 the AUDIT or ALARM ACE. Once the server completes the ACL 2089 processing, it then notes if the operation succeeded or failed. 2090 If the operation succeeded, and if the SUCCESS flag was set for a 2091 matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM 2092 event occurs. If the operation failed, and if the FAILED flag was 2093 set for the matching AUDIT or ALARM ACE, then the appropriate 2094 AUDIT or ALARM event occurs. Either or both of the SUCCESS or 2095 FAILED can be set, but if neither is set, the AUDIT or ALARM ACE 2096 is not useful. 2098 The previously described processing applies to ACCESS operations 2099 even when they return NFS4_OK. For the purposes of AUDIT and 2100 ALARM, we consider an ACCESS operation to be a "failure" if it 2101 fails to return a bit that was requested and supported. 2103 ACE4_IDENTIFIER_GROUP 2104 Indicates that the "who" refers to a GROUP as defined under UNIX 2105 or a GROUP ACCOUNT as defined under Windows. Clients and servers 2106 MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who 2107 value equal to one of the special identifiers outlined in 2108 Section 5.9. 2110 ACE4_INHERITED_ACE 2111 Indicates that this ACE is inherited from a parent directory. A 2112 server that supports automatic inheritance will place this flag on 2113 any ACEs inherited from the parent directory when creating a new 2114 object. Client applications will use this to perform automatic 2115 inheritance. Clients and servers MUST clear this bit in the acl 2116 attribute; it may only be used in the dacl and sacl attributes. 2118 5.9. ACE Who 2120 The "who" field of an ACE is an identifier that specifies the 2121 principal or principals to whom the ACE applies. It may refer to a 2122 user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying 2123 which. 2125 There are several special identifiers that need to be understood 2126 universally, rather than in the context of a particular DNS domain. 2128 [Author Aside, including list]: so far, so good, but the following 2129 problems need to be addressed: 2131 * Lack of clarity about which special identifiers can be understood 2132 by NFSv4. 2134 * Confusion of "authentication" and "identification". 2136 [Previous treatment (Item #50a)]: Some of these identifiers cannot be 2137 understood when an NFS client accesses the server, but have meaning 2138 when a local process accesses the file. The ability to display and 2139 modify these permissions is permitted over NFS, even if none of the 2140 access methods on the server understands the identifiers. 2142 [Consensus Needed (Item #50a)]: These identifiers, except for OWNER@, 2143 GROUP@, EVERONE@, cannot be reliably understood when an NFS client 2144 accesses the server, but might have meaning when a local process 2145 accesses the file or when protocols other than NFSv4 are used As a 2146 result, when ACEs containing these who values are encountered, the 2147 server is free to make its own judgment as to whether any particular 2148 request will be treated as matching. 2150 [Consensus Needed (Item #50a)]: The ability to display and modify 2151 these permissions is provide for by NFSv4, even though they are not 2152 useful when processing NFSv4 requests, 2153 +===============+==============================================+ 2154 | Who | Description | 2155 +===============+==============================================+ 2156 | OWNER | The owner of the file. | 2157 +---------------+----------------------------------------------+ 2158 | GROUP | The group associated with the file. | 2159 +---------------+----------------------------------------------+ 2160 | EVERYONE | [Previous treatment (Item #50a)]: The world, | 2161 | | including the owner and owning group. | 2162 | | | 2163 | | [Consensus Needed (Item #50a)]: All | 2164 | | requesters, including the owner, members of | 2165 | | the owning group, and requests for which no | 2166 | | user information is available. | 2167 +---------------+----------------------------------------------+ 2168 | INTERACTIVE | Accessed from an interactive terminal. | 2169 +---------------+----------------------------------------------+ 2170 | NETWORK | Accessed via the network. | 2171 +---------------+----------------------------------------------+ 2172 | DIALUP | Accessed as a dialup user to the server. | 2173 +---------------+----------------------------------------------+ 2174 | BATCH | Accessed from a batch job. | 2175 +---------------+----------------------------------------------+ 2176 | ANONYMOUS | [Consensus Needed (Item #50a)]: Accessed | 2177 | | without any authentication of the user | 2178 | | principal. | 2179 +---------------+----------------------------------------------+ 2180 | AUTHENTICATED | [Consensus Needed (Item #50a)]: Any | 2181 | | authenticated user (opposite of ANONYMOUS). | 2182 +---------------+----------------------------------------------+ 2183 | SERVICE | Accessed from a system service. | 2184 +---------------+----------------------------------------------+ 2186 Table 2 2188 To avoid conflict, these special identifiers are distinguished by an 2189 appended "@" and will appear in the form "xxxx@" (with no domain name 2190 after the "@"), for example, ANONYMOUS@. 2192 {Previous treatment (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST 2193 be ignored on entries with these special identifiers. When encoding 2194 entries with these special identifiers, the ACE4_IDENTIFIER_GROUP 2195 flag SHOULD be set to zero. 2197 [Author Aside]: I don't understand what might be valid reasons to 2198 ignore this or how a server would respond in the case the that it was 2199 ignored. 2201 [Consensus Needed (Item #51a)]: The ACE4_IDENTIFIER_GROUP flag MUST 2202 be ignored on entries with these special identifiers. When encoding 2203 entries with these special identifiers, the ACE4_IDENTIFIER_GROUP 2204 flag MUST be set to zero. 2206 It is important to note that "EVERYONE@" is not equivalent to the 2207 UNIX "other" entity. This is because, by definition, UNIX "other" 2208 does not include the owner or owning group of a file. "EVERYONE@" 2209 means literally everyone, including the owner or owning group. 2211 5.10. Automatic Inheritance Features 2213 The acl attribute consists only of an array of ACEs, but the sacl 2214 (Section 12.1) and dacl (Section 7.4.2) attributes also include an 2215 additional flag field. 2217 struct nfsacl41 { 2218 aclflag4 na41_flag; 2219 nfsace4 na41_aces<>; 2220 }; 2222 The flag field applies to the entire sacl or dacl; three flag values 2223 are defined: 2225 const ACL4_AUTO_INHERIT = 0x00000001; 2226 const ACL4_PROTECTED = 0x00000002; 2227 const ACL4_DEFAULTED = 0x00000004; 2229 and all other bits are to be cleared. The ACE4_INHERITED_ACE flag 2230 can be set in the ACEs of the sacl or dacl (whereas it always needs 2231 to be cleared in the acl). 2233 Together these features allow a server to support automatic 2234 inheritance, which we now explain in more detail. 2236 Inheritable ACEs are normally inherited by child objects only at the 2237 time that the child objects are created; later modifications to 2238 inheritable ACEs do not result in modifications to inherited ACEs on 2239 descendants. 2241 However, the dacl and sacl provide an OPTIONAL mechanism that allows 2242 a client application to propagate changes to inheritable ACEs to an 2243 entire directory hierarchy. 2245 A server that supports this feature performs inheritance at object 2246 creation time in the normal way, and SHOULD set the 2247 ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to 2248 the new object. 2250 A client application such as an ACL editor may then propagate changes 2251 to inheritable ACEs on a directory by recursively traversing that 2252 directory's descendants and modifying each NFSv4 ACL encountered to 2253 remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them 2254 by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag 2255 set). It uses the existing ACE inheritance flags in the obvious way 2256 to decide which ACEs to propagate. (Note that it may encounter 2257 further inheritable ACEs when descending the directory hierarchy and 2258 that those will also need to be taken into account when propagating 2259 inheritable ACEs to further descendants.) 2261 The reach of this propagation may be limited in two ways: first, 2262 automatic inheritance is not performed from any directory ACL that 2263 has the ACL4_AUTO_INHERIT flag cleared; and second, automatic 2264 inheritance stops wherever an ACL with the ACL4_PROTECTED flag is 2265 set, preventing modification of that ACL and also (if the ACL is set 2266 on a directory) of the ACL on any of the object's descendants. 2268 This propagation is performed independently for the sacl and the dacl 2269 attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may 2270 be independently set for the sacl and the dacl, and propagation of 2271 one type of acl may continue down a hierarchy even where propagation 2272 of the other acl has stopped. 2274 New objects are to be created with a dacl and a sacl that both have 2275 the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to 2276 the same value as that on, respectively, the sacl or dacl of the 2277 parent object. 2279 Both the dacl and sacl attributes are Recommended, and a server MAY 2280 support one without supporting the other. 2282 A server that supports both the old acl attribute and one or both of 2283 the new dacl or sacl attributes MUST do so in such a way as to keep 2284 all three attributes consistent with each other. Thus, the ACEs 2285 reported in the acl attribute will be the union of the ACEs reported 2286 in the dacl and sacl attributes, except that the ACE4_INHERITED_ACE 2287 flag will be cleared from the ACEs in the acl. And of course a 2288 client that queries only the acl will be unable to determine the 2289 values of the sacl or dacl flag fields. 2291 When a client performs a SETATTR for the acl attribute, the server 2292 SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the 2293 dacl. By using the acl attribute, as opposed to the dacl or sacl 2294 attributes, the client signals that it may not understand automatic 2295 inheritance, and thus cannot be trusted to set an ACL for which 2296 automatic inheritance would make sense. 2298 When a client application queries an NFSv4 ACL, modifies it, and sets 2299 it again, it needs to leave any ACEs marked with ACE4_INHERITED_ACE 2300 unchanged, in their original order, at the end of the NFSv4 ACL. If 2301 the application is unable to do this, it needs to set the 2302 ACL4_PROTECTED flag. This behavior is not enforced by servers, but 2303 violations of this rule may lead to unexpected results when 2304 applications perform automatic inheritance. 2306 If a server also supports the mode attribute, it SHOULD set the mode 2307 in such a way that leaves inherited ACEs unchanged, in their original 2308 order, at the end of the ACL. If it is unable to do so, it SHOULD 2309 set the ACL4_PROTECTED flag on the file's dacl. 2311 Finally, in the case where the request that creates a new file or 2312 directory does not also set permissions for that file or directory, 2313 and there are also no ACEs to inherit from the parent's directory, 2314 then the server's choice of ACL for the new object is implementation- 2315 dependent. In this case, the server SHOULD set the ACL4_DEFAULTED 2316 flag on the ACL it chooses for the new object. An application 2317 performing automatic inheritance takes the ACL4_DEFAULTED flag as a 2318 sign that the ACL is to be completely replaced by one generated using 2319 the automatic inheritance rules. 2321 5.11. Attribute 13: aclsupport 2323 A server need not support all of the above ACE types. This attribute 2324 indicates which ACE types are supported for the current file system. 2325 The bit mask constants used to represent the above definitions within 2326 the aclsupport attribute are as follows: 2328 const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; 2329 const ACL4_SUPPORT_DENY_ACL = 0x00000002; 2330 const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; 2331 const ACL4_SUPPORT_ALARM_ACL = 0x00000008; 2333 [Author Aside]: Even though support aclsupport is OPTIONAL, there has 2334 been no mention of the possibility of it not being supported. 2336 [Consensus Needed (Item #14a)]: If this attribute is not supported 2337 for a server, the client is entitled to assume that if the acl 2338 attribute is supported, support for ALLOW and DENY ACEs is present. 2339 Thus, if such a server supports the the sacl attribute, clients are 2340 not likely to use it if aclsupport is not supported by the server. 2342 [Previous Treatment]: Servers that support either the ALLOW or DENY 2343 ACE type SHOULD support both ALLOW and DENY ACE types. 2345 [Author Aside]: It needs to be made clearer what the harm is that is 2346 to be prevented by this. Further if such harm exists, it is not 2347 clear what are the valid reasons not do this? 2349 [Consensus Needed (Item #15a)]: There is little point in implementing 2350 a server which supports either ALLOW or DENY ACE types without 2351 supporting both. For reasons explained in Section 7.1 the ACL-based 2352 authorization cannot be used if only a single ACE type is available. 2354 Clients are not to attempt to set an ACE unless the server claims 2355 support for that ACE type. If the server receives a request to set 2356 an ACE that it cannot store, it MUST reject the request with 2357 NFS4ERR_ATTRNOTSUPP. 2359 [Previous Treatment (Item #12c)]: If the server receives a request to 2360 set an ACE that it can store but cannot enforce, the server SHOULD 2361 reject the request with NFS4ERR_ATTRNOTSUPP. 2363 [Author Aside]: Beyond the issues with the use of SHOULD, it is 2364 better to centralize this material and be clearer about the whole 2365 issue of ACL enforcement. 2367 [Consensus Needed (Item #12c)]: The case of ACEs that cannot be 2368 enforced is similar, with the details of enforcement discussed in 2369 Section 5.5. 2371 Support for any of the ACL attributes is OPTIONAL, although 2372 Recommended. However, a server (NFSv4.1 and above) that supports 2373 either of the new ACL attributes (dacl or sacl) MUST allow use of the 2374 new ACL attributes to access all of the ACE types that it supports. 2375 In other words, if a server which supports sacl or dacl supports 2376 ALLOW or DENY ACEs, then it MUST support the dacl attribute, and if 2377 it supports AUDIT or ALARM ACEs, then it MUST support the sacl 2378 attribute. 2380 5.12. Attribute 12: acl 2382 The acl attribute, as opposed to the sacl and dacl attributes, 2383 consists only of an ACE array and does not support automatic 2384 inheritance. 2386 The acl attribute is recommended and there is no requirement that a 2387 server support it. However, when the dacl attribute is supported, it 2388 is a good idea to provide support for the acl attribute as well, in 2389 order to accommodate clients that have not been upgraded to use the 2390 dacl attribute. 2392 [Author Aside]: Although it has generally been assumed that changes 2393 to sacl and dacl attributes are to be visible in the acl and vice 2394 versa, NFSv4.1 specification do not appear to document this fact. 2396 [Consensus Item, Including List (Item #16a)]: For NFSv4.1 servers 2397 that support Both the acl attribute and one or more of the sacl and 2398 dacl attributes, changes to the ACE's need to be immediately 2399 reflected in the other supported attributes: 2401 * The result of reading the dacl attribute MUST consist of a set of 2402 ACEs that are exactly the same as the ACEs ALLOW and DENY ACEs 2403 within the the acl attribute, in the same order. 2405 * The result of reading the sacl attribute MUST consist of a set of 2406 ACEs that are exactly the same as the ACEs AUDIT and ALARM ACEs 2407 within the the acl attribute, in the same order. 2409 * The result of reading the acl attribute MUST consist of a set of 2410 ACEs that are exactly the same as the union of ACEs within the 2411 sacl and dacl attributes. Two ACEs that both appear in one of the 2412 sacl or dacl attributes will appear in the same order in the acl 2413 attribute. 2415 6. Authorization in General 2417 There are three distinct methods of checking whether NFSv4 requests 2418 are authorized: 2420 * The most important methods of authorization is used to effect 2421 user-based file access control, as described in Section 7. These 2422 methods are often termed "Discretionary access control" because 2423 they rely on attributes set by particular users, to control 2424 acceptable file access. 2426 This requires the identification of the user making the request. 2427 Because of the central role of such access control in providing 2428 NFSv4 security, server implementations SHOULD NOT use such 2429 identifications when they are not authenticated. In this context, 2430 valid reasons to do otherwise are limited to the compatibility and 2431 maturity issues discussed in Section 17.1.4 2433 * NFSv4.2, via the labelled NFS feature, provides an additional 2434 potential requirement for request authorization. The labelled NFS 2435 provides "Mandatory access control" not under the control of 2436 individual users. 2438 For reasons made clear in Section 10, there is no realistic 2439 possibility of the server using the data defined by existing 2440 specifications of this feature to effect request authorization. 2441 While it is possible for clients to provide this authorization, 2442 the lack of detailed specifications makes it impossible to 2443 determine the nature of the identification used and whether it can 2444 appropriately be described as "authentication". 2446 * Since undesired changes to server-maintained locking state (and, 2447 for NFSv4.1, session state) can result in denial of service 2448 attacks (see Section 17.4.7), server implementations SHOULD take 2449 steps to prevent unauthorized state changes. This can be done by 2450 implementing the state authorization restrictions discussed in 2451 Section 11. Because these restrictions apply on a per-peer basis 2452 rather than being affected by the identity of the user making the 2453 request, it is better to consider them as part of "Mandatory 2454 access control". 2456 7. User-based File Access Authorization 2458 7.1. Attributes for User-based File Access Authorization 2460 NFSv4.1 provides for multiple authentication models, controlled by 2461 the support for particular recommended attributes implemented by the 2462 server, as discussed below: 2464 * Consensus Needed (Item #18a)]: The attributes owner, owning_group, 2465 and mode enable use of a POSIX-based authorization model, as 2466 described in Section 7.3. When all of these attributes are 2467 supported, this authorization model can be implemented. 2469 Consensus Needed (Item #18a)]:When none of these attributes or 2470 only a proper subset of them are supported, this authorization 2471 model is unavailable. 2473 * [Consensus Needed (Item #17a)]: The acl attribute (or the 2474 attribute dacl in NFSv4.1) can provide an ACL-based authorization 2475 model as described in Section 7.4 as long as support for ALLOW and 2476 DENY ACEs is provided. 2478 [Consensus Needed (Items #17a, #18a)]: When some of these ACE 2479 types are not supported or the owner or owning_group attribute is 2480 not supported, this authorization model is unavailable, since 2481 there are some modes that cannot be represented as a corresponding 2482 NFSv4 ACL, when using only a single ACE type. See Section 9.2 for 2483 details. 2485 7.2. Handling of Multiple Parallel File Access Authorization Models 2487 NFSv4 ACLs and modes represent two well-established models for 2488 specifying user-based file access permissions. NFSv4 provides 2489 support for either or both depending on the attributes supported by 2490 the server and, in cases in which both NFSv4 ACLs and the mode 2491 attribute are supported, the actual attributes set for a particular 2492 object. 2494 * [Consensus Needed (item #18b)]: When the attributes mode, owner, 2495 owner group are all supported, the posix-based authorization 2496 model, described in Section 7.3 can be used. 2498 * [Consensus Needed (Items #17b, #18b)]: When the acl (or dacl) 2499 attribute is supported together with both of the ACE types ALLOW 2500 and DENY, the acl based authorization model, described in 2501 Section 7.4 can be used as long as the attributes owner and 2502 owner_group are also supported. 2504 [Consensus Needed (item #18b)]: While formally recommended 2505 (essentially OPTIONAL) attributes, it appears that the owner and 2506 owner_group attributes need to be available to support any file 2507 access authorization model. As a result, this document will not 2508 discuss the possibility of servers that do not support both of these 2509 attributes and clients have no need to support such servers. 2511 When both authorization models can be used, there are difficulties 2512 that can arise because the ACL-based model provides finer-grained 2513 access control than the POSIX model. The ways of dealing with these 2514 difficulties appear later in this section while more detail on the 2515 appropriate handling of this situation, which might depend on the 2516 minor version used, appears in Section 9. 2518 The following describe NFSv4's handling in supporting multiple 2519 authorization models for file access. 2521 * If a server supports the mode attribute, it needs to provide the 2522 appropriate POSIX semantics if no ACL-based attributes have ever 2523 been assigned to object. These semantics include the restriction 2524 of the ability to modify the mode, owner and owner-group to the 2525 current owner of the file. 2527 * If a server supports ACL attributes, it needs to provide NFSv4 ACL 2528 semantics as described in this document for all objects for which 2529 the ACL attributes have actually been set. This includes the ACL- 2530 based restrictions on the authorization to modify the mode, owner 2531 and owner_group attributes. 2533 * On servers that support the mode attribute, if ACL attributes have 2534 never been set on an object, via inheritance or explicitly, the 2535 behavior is to be the behavior mandated by POSIX, including the 2536 those provisions that restrict the setting of authorization- 2537 related attributes. 2539 * On servers that support the mode attribute, if the ACL attributes 2540 have been previously set on an object, either explicitly or via 2541 inheritance: 2543 - [Previous Treatment]: Setting only the mode attribute should 2544 effectively control the traditional UNIX-like permissions of 2545 read, write, and execute on owner, owner_group, and other. 2547 [Author Aside]: It isn't really clear what the above paragraph 2548 means, especially as it governs the handling of aces 2549 designating specific users and groups which are not the owner 2550 and have no overlap with the owning group 2552 {Consensus Needed (Item #19a)]: Setting only the mode 2553 attribute, will result in the access of the file being 2554 controlled just it would be if the existing acl did not exist, 2555 with file access decisions as to read made in accordance with 2556 the mode set. The ALLOW and DENY aces in the ACL will reflect 2557 the modified security although there is no need to modify AUDIT 2558 and ALARM aces or mask bits not affected by the mode bits, such 2559 as SYNCHRONIZE. 2561 [Author Aside]: the above may need to modified to reflect the 2562 resolution of Consensus Item #??. 2564 - [Previous Treatment]: Setting only the mode attribute should 2565 provide reasonable security. For example, setting a mode of 2566 000 should be enough to ensure that future OPEN operations for 2567 OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any 2568 principal fail, regardless of a previously existing or 2569 inherited ACL. 2571 [Author Aside]: We need to get rid of or provide some some 2572 replacement for the subjective first sentence. While the 2573 specific example give is unexceptionable, it raises questions 2574 in other cases as to what would constitutes "reasonable 2575 semantics". While the resolution of such questions would be 2576 subject to dispute, the author believes that consensus item 2577 #19a deals with the matter adequately. As a result he 2578 proposes, that the that this bullet be removed and the second- 2579 level list collapsed to single paragraph. 2581 * Although RFCs 7530 [6] and 8881 [8] present different descriptions 2582 of the specific semantic requirements relating to the interaction 2583 of mode and ACL attributes, the difference are quite small, with 2584 the most important ones deriving from the absence of the 2585 set_mode_masked attribute. The unified treatment in Section 9 2586 will indicate where version-specific differences exist. 2588 7.3. Posix Authorization Model 2590 7.3.1. Attribute 33: mode 2592 The NFSv4.1 mode attribute is based on the UNIX mode bits. The 2593 following bits are defined: 2595 const MODE4_SUID = 0x800; /* set user id on execution */ 2596 const MODE4_SGID = 0x400; /* set group id on execution */ 2597 const MODE4_SVTX = 0x200; /* save text even after use */ 2598 const MODE4_RUSR = 0x100; /* read permission: owner */ 2599 const MODE4_WUSR = 0x080; /* write permission: owner */ 2600 const MODE4_XUSR = 0x040; /* execute permission: owner */ 2601 const MODE4_RGRP = 0x020; /* read permission: group */ 2602 const MODE4_WGRP = 0x010; /* write permission: group */ 2603 const MODE4_XGRP = 0x008; /* execute permission: group */ 2604 const MODE4_ROTH = 0x004; /* read permission: other */ 2605 const MODE4_WOTH = 0x002; /* write permission: other */ 2606 const MODE4_XOTH = 0x001; /* execute permission: other */ 2608 Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal 2609 identified by the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and 2610 MODE4_XGRP apply to principals belonging to the group identified in 2611 the owner_group attribute but who are not identified by the owner 2612 attribute. Bits MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any 2613 principal that does not match that in the owner attribute and does 2614 not belong to a group matching that of the owner_group attribute. 2615 These nine bits are used in providing authorization information. 2617 [Previous Treatment]: The bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX 2618 do not provide authorization information and do not affect server 2619 behavior. Instead, they are acted on by the client just as they 2620 would be for corresponding mode bits obtained from local file 2621 systems. 2623 [Consensus needed (Item #6c)]: For objects which are not directories, 2624 the bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX do not provide 2625 authorization information and do not affect server behavior. 2626 Instead, they are acted on by the client just as they would be for 2627 corresponding mode bits obtained from local file systems. 2629 [Consensus needed (Item #6c)]: For directories, the bits MODE4_SUID 2630 and MODE4_SGID, do not provide authorization information and do not 2631 affect server behavior. Instead, they are acted on by the client 2632 just as they would be for corresponding mode bits obtained from local 2633 file systems. The mode bit MODE_SVTX does have an authorization- 2634 related role as described later in this section 2636 [Consensus Needed, Including List (Item #6c]): When handling RENAME 2637 and REMOVE operations the check for authorization depends on the 2638 setting of MODE_SVTX for the directory. 2640 * When MODE_SVTX is not set on the directory, authorization requires 2641 write permission on both the file being renamed and the source 2642 directory. 2644 * When MODE_SVTX is not on the directory, authorization requires, in 2645 addition that the requesting principal be the owner of the file to 2646 be named or removed. 2648 [Consensus needed (Item #6c)]: It needs to be noted that this 2649 approach is similar to the ACL-based approach documented in 2650 Section 5.6. However there are some semantic differences whose 2651 motivation remains unclear and the specification does not mention 2652 RENAME, as it needs to. 2654 [Author Aside]: Bringing the above into more alignment with the ACL- 2655 based semantics is certainly desirable but the necessary work has not 2656 been done yet. For tracking purposes, that realignment will be 2657 considered Consensus Item #20. 2659 Bits within a mode other than those specified above are not defined 2660 by this protocol. A server MUST NOT return bits other than those 2661 defined above in a GETATTR or READDIR operation, and it MUST return 2662 NFS4ERR_INVAL if bits other than those defined above are set in a 2663 SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation. 2665 [Consensus Needed (Item #21b)]: As will be seen in Sections 9.3 and 2666 9.7, many straightforward ways of dealing with mode that work well 2667 with forward-slope modes need adjustment to properly deal with 2668 reverse-slope modes, as defined in Section 4.1 2670 7.3.2. NFSv4.1 Attribute 74: mode_set_masked 2672 The mode_set_masked attribute is a write-only attribute that allows 2673 individual bits in the mode attribute to be set or reset, without 2674 changing others. It allows, for example, the bits MODE4_SUID, 2675 MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified 2676 any of the nine low-order mode bits devoted to permissions. 2678 When minor versions other than NFSv4.0 are used, instances of use of 2679 the set_mode_masked attribute such that none of the nine low-order 2680 bits are subject to modification, then neither the acl nor the dacl 2681 attribute needs to be automatically modified as discussed in Sections 2682 9.7 and 9.9. 2684 The mode_set_masked attribute consists of two words, each in the form 2685 of a mode4. The first consists of the value to be applied to the 2686 current mode value and the second is a mask. Only bits set to one in 2687 the mask word are changed (set or reset) in the file's mode. All 2688 other bits in the mode remain unchanged. Bits in the first word that 2689 correspond to bits that are zero in the mask are ignored, except that 2690 undefined bits are checked for validity and can result in 2691 NFS4ERR_INVAL as described below. 2693 The mode_set_masked attribute is only valid in a SETATTR operation. 2694 If it is used in a CREATE or OPEN operation, the server MUST return 2695 NFS4ERR_INVAL. 2697 Bits not defined as valid in the mode attribute are not valid in 2698 either word of the mode_set_masked attribute. The server MUST return 2699 NFS4ERR_INVAL if any such bits are set to one in a SETATTR. If the 2700 mode and mode_set_masked attributes are both specified in the same 2701 SETATTR, the server MUST also return NFS4ERR_INVAL. 2703 7.4. ACL-based Authorization Model 2705 7.4.1. Processing Access Control Entries 2707 To determine if a request succeeds, the server processes each nfsace4 2708 entry of type ALLOW or DENY in turn as ordered in the array. Only 2709 ACEs that have a "who" that matches the requester are considered. An 2710 ACE is considered to match a given requester if at least one of the 2711 following is true: 2713 * The "who' designates a specific user which is the user making the 2714 request. 2716 * The "who" specifies "OWNER@" and the user making the request is 2717 the owner of the file. 2719 * The "who" designates a specific group and the user making the 2720 request is a member of that group. 2722 * The "who" specifies "GROUP@" and the user making the request is a 2723 member of the group owning the file. 2725 * The "who" specifies "EVERYONE@". 2727 * The "who" specifies "INTERACTIVE@", "NETWORK@", "DIALUP@", 2728 "BATCH@", or "SERVICE@" and the requester, in the judgment of the 2729 server, feels that designation appropriately describes the 2730 requester. 2732 * The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the 2733 requestor's authentication status matches the who, using the 2734 definitions in Section 5.9 2736 Each ACE is processed until all of the bits of the requester's access 2737 have been ALLOWED. Once a bit (see below) has been ALLOWED by an 2738 ACCESS_ALLOWED_ACE, it is no longer considered in the processing of 2739 later ACEs. If an ACCESS_DENIED_ACE is encountered where the 2740 requester's access still has unALLOWED bits in common with the 2741 "access_mask" of the ACE, the request is denied. When the ACL is 2742 fully processed, if there are bits in the requester's mask that have 2743 not been ALLOWED or DENIED, access is denied. 2745 Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do 2746 not affect a requester's access, and instead are for triggering 2747 events as a result of a requester's access attempt. AUDIT and ALARM 2748 ACEs are processed only after processing ALLOW and DENY ACEs if any 2749 exist. This is necessary since the handling of AUDIT and ALARM ACEs 2750 are affected by whether the access attempt is successful. 2752 [Previous Treatment]: The NFSv4.1 ACL model is quite rich. Some 2753 server platforms may provide access-control functionality that goes 2754 beyond the UNIX-style mode attribute, but that is not as rich as the 2755 NFS ACL model. So that users can take advantage of this more limited 2756 functionality, the server may support the acl attributes by mapping 2757 between its ACL model and the NFSv4.1 ACL model. Servers must ensure 2758 that the ACL they actually store or enforce is at least as strict as 2759 the NFSv4 ACL that was set. It is tempting to accomplish this by 2760 rejecting any ACL that falls outside the small set that can be 2761 represented accurately. However, such an approach can render ACLs 2762 unusable without special client-side knowledge of the server's 2763 mapping, which defeats the purpose of having a common NFSv4 ACL 2764 protocol. Therefore, servers should accept every ACL that they can 2765 without compromising security. To help accomplish this, servers may 2766 make a special exception, in the case of unsupported permission bits, 2767 to the rule that bits not ALLOWED or DENIED by an ACL must be denied. 2768 For example, a UNIX-style server might choose to silently allow read 2769 attribute permissions even though an ACL does not explicitly allow 2770 those permissions. (An ACL that explicitly denies permission to read 2771 attributes should still be rejected.) 2773 [Author Aside]: While the NFSv4.1 provides that many might not need 2774 or use, it is the one that the working group adopted by the working 2775 group, and I have to assume that alternatives, such as the withdrawn 2776 POSIX ACL proposal were considered but not adopted. The phrase 2777 "unsupported permission bits" with no definition of the bit whose 2778 support might be dispensed with, implies that the server is free to 2779 support whatever subset of these bits it chooses. As a result, 2780 clients would not be able to rely on a functioning server 2781 implementation of this OPTIONAL attribute. If there are specific 2782 compatibility issues that make it necessary to allow non-support of 2783 specific mask bits, then these need to be limited and the client 2784 needs guidance about determining the set of unsupported mask bits. 2786 [Previous Treatment]: The situation is complicated by the fact that a 2787 server may have multiple modules that enforce ACLs. For example, the 2788 enforcement for NFSv4.1 access may be different from, but not weaker 2789 than, the enforcement for local access, and both may be different 2790 from the enforcement for access through other protocols such as SMB 2791 (Server Message Block). So it may be useful for a server to accept 2792 an ACL even if not all of its modules are able to support it. 2794 [Author Aside]: The following paragraph does not provide helpful 2795 guidance and takes no account of the need of the the client to be 2796 able to rely on the server implementing protocol-specifying semantics 2797 and giving notice in those cases in which it is unable to so 2799 [Previous Treatment]: The guiding principle with regard to NFSv4 2800 access is that the server must not accept ACLs that appear to make 2801 access to the file more restrictive than it really is. 2803 7.4.2. V4.1 Attribute 58: dacl 2805 The dacl attribute is like the acl attribute, but dacl allows only 2806 ALLOW and DENY ACEs. The dacl attribute supports automatic 2807 inheritance (see Section 5.10). 2809 8. Common Considerations for Both File access Models 2811 [Author Aside, Including List]: This subsections within this section 2812 are derived from Section 6.3 of 8881, entitled "Common Methods. 2813 However, its content is different because it has been rewritten to 2814 deal with issues common to both file access models, which now appears 2815 to have not been the original intention. Nevertheless, the following 2816 changes have been made: 2818 * The section "Server Considerations" has been revised to deal with 2819 both the mode and acl attributes, since the points being made 2820 apply, in almost all cases, to both attributes. 2822 * The section "Client Considerations" has been heavily revised, 2823 since what had been there did not make any sense to me. 2825 * The section "Computing a Mode Attribute from an ACL" has been 2826 moved to Section 9.3 since it deals with the co-ordination of the 2827 posix and acl authorization models. 2829 8.1. Server Considerations 2831 The server uses the mode attribute or the acl attribute applying the 2832 algorithm described in Section 7.4.1 to determine whether an ACL 2833 allows access to an object. 2835 [Author Aside, Including List]: The list previously in this section 2836 (now described as "Previous Treatment" combines two related issues in 2837 a way which obscures the very different security-related consequences 2838 of two distinct issues: 2840 * In some cases an operation will be authorized but is not allowed 2841 for reasons unrelated to authorization. 2843 This has no negative effect on security. 2845 * The converse case does have troubling effects on security which 2846 are mentioned in this section and discussed in more detail in 2847 Section 17 2849 [Author Aside, Including List]: The items in that list have been 2850 dealt with as follows: 2852 * The first and sixth items fit under the first (i.e. less 2853 troublesome) of these issues. They have have been transferred 2854 into an appropriate replacement list. 2856 * The third item is to be deleted since it does not manifest either 2857 of these issues. In fact, it refers to the semantics already 2858 described in Section 5.4. is already described in ... 2860 * The second, fourth and fifth items need to be addressed in a new 2861 list dealing with the potentially troublesome issues arising from 2862 occasions in which the access semantics previously described are 2863 relaxed, for various reasons. 2865 Included are cases in which previous specifications explicitly 2866 allowed this by using the term "MAY" and others in which the 2867 existence of servers manifesting such behavior was reported, with 2868 the implication that clients need to prepared for such behavior. 2870 [Previous Treatment, Including List (Items #22a, #41a, #52a)]: 2871 However, these attributes might not be the sole determiner of access. 2872 For example: 2874 * In the case of a file system exported as read-only, the server 2875 will deny write access even though an object's file access 2876 attributes would grant it. 2878 * Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL 2879 permissions to prevent a situation from arising in which there is 2880 no valid way to ever modify the ACL. 2882 * All servers will allow a user the ability to read the data of the 2883 file when only the execute permission is granted (e.g., if the ACL 2884 denies the user the ACE4_READ_DATA access and allows the user 2885 ACE4_EXECUTE, the server will allow the user to read the data of 2886 the file). 2888 * Many servers implement owner-override semantics in which the owner 2889 of the object is allowed to override accesses that are denied by 2890 the ACL. This may be helpful, for example, to allow users 2891 continued access to open files on which the permissions have 2892 changed. 2894 * Many servers provide for the existence of a "superuser" that has 2895 privileges beyond an ordinary user. The superuser may be able to 2896 read or write data or metadata in ways that would not be permitted 2897 by the ACL or mode attributes. 2899 * A retention attribute might also block access otherwise allowed by 2900 ACLs (see Section 5.13 of RFC8881 [8]). 2902 [Consensus Needed, Including List (Item #22a)]: It needs to be noted 2903 that, even when an operation is authorized, it may be denied for 2904 reasons unrelated to authorization. For example: 2906 * In the case of a file system exported as read-only, the server 2907 will deny write access even though an object's file access 2908 attributes would authorize it. 2910 * A retention attribute might also block access otherwise allowed by 2911 ACLs (see Section 5.13 of RFC8881 [8]). 2913 [Consensus Needed, (Item #22a)]: There are also cases in which the 2914 converse issue arises, so that an operation which is not authorized 2915 as specified by the mode and ACL attributes is, nevertheless, 2916 executed as if it were authorized. Because previous NFSv4 2917 specifications have cited the cases listed below without reference to 2918 the security problems that they create, it is necessary to discuss 2919 them here to provide clarification of the security implications of 2920 following this guidance, which is now superseded. These cases are 2921 listed below and discussed in more detail in Section 17.1.3. 2923 [Consensus Needed, Including List (Item #22a, #41a, #52a)]: In the 2924 following list, the treatment used in RFC8881 [8] is quoted, while 2925 the corresponding text in RFC7530 [6]is essentially identical. 2927 * RFC8881 [8] contains the following, which is now superseded: 2929 Server implementations MAY grant ACE4_WRITE_ACL and 2930 ACE4_READ_ACL permissions to prevent a situation from arising 2931 in which there is no valid way to ever modify the ACL. 2933 While, as a practical matter, there do need to be provisions to 2934 deal with this issue, the "MAY" above is too broad,in that it 2935 describes the motivation without any limits providing appropriate 2936 restriction on the steps that might be taken to deal with the 2937 issue. See Section 17.1.3 for the updated treatment of this 2938 issue. 2940 * RFC8881 [8] contains the following, which is now superseded: 2942 Many servers implement owner-override semantics in which the 2943 owner of the object is allowed to override accesses that are 2944 denied by the ACL. This may be helpful, for example, to allow 2945 users continued access to open files on which the permissions 2946 have changed. 2948 Regardless of the truth of the first sentence above, either when 2949 it was written or today, it needs to be stressed that the fact 2950 that a server manifests a particular behavior does not imply that 2951 it is valid according to the protocol specification. In this 2952 case, the supposed "owner-override semantics" clearly are not 2953 valid, since they contradict the specification of both the mode- 2954 based and ACL-based approaches to file access authorization. 2956 With regard to the second sentence of the quotation above, it is 2957 not clear whether it is helpful or hurtful to allow continued 2958 access to open files which have become inaccessible due to changes 2959 in security and it is not clear that the working group will make a 2960 decision on the matter in this document, despite the obvious 2961 security implications. In any case, the resolution is unlikely to 2962 depend on whether the owner is involved. 2964 * RFC8881 [8] contains the following, which is now superseded: 2966 Many servers have the notion of a "superuser" that has 2967 privileges beyond an ordinary user. The superuser may be able 2968 to read or write data or metadata in ways that would not be 2969 permitted by the ACL or mode attributes. 2971 While many (or almost all) systems in which NFSv4 servers are 2972 embedded, have provisions for such privileged access to be 2973 provided, it does not follow that NFSv4 servers, as such, need to 2974 have provision for such access. 2976 Providing such access as part of the NFSv4 protocols, would 2977 necessitate a major revision of the semantics of ACL including 2978 such troublesome matters as the proper handling of AUDIT and ALARM 2979 ACEs in the face of such privileged access. 2981 Because of the effect such unrestricted access might have in 2982 facilitating and perpetuating attacks, Section 17.1.3 will the new 2983 approach to this issue, while Section 17.4.1, will explain how 2984 such access is addressed in the threat analysis. 2986 8.2. Client Considerations 2988 [Previous Treatment]: Clients SHOULD NOT do their own access checks 2989 based on their interpretation of the ACL, but rather use the OPEN and 2990 ACCESS operations to do access checks. This allows the client to act 2991 on the results of having the server determine whether or not access 2992 is to be granted based on its interpretation of the ACL. 2994 [Author Aside]: With regard to the use of "SHOULD NOT" in the 2995 paragraph above, it is not clear what might be valid reasons to 2996 bypass this recommendation. Perhaps "MUST NOT" or "are not advised 2997 to" would be more appropriate. 2999 [Consensus Needed (Item #23a)]: Clients are not expected to do their 3000 own access checks based on their interpretation of the ACL, but 3001 instead use the OPEN and ACCESS operations to do access checks. This 3002 allows the client to act on the results of having the server 3003 determine whether or not access is to be granted based on its 3004 interpretation of the ACL. 3006 [Previous Treatment]: Clients must be aware of situations in which an 3007 object's ACL will define a certain access even though the server will 3008 not enforce it. In general, but especially in these situations, the 3009 client needs to do its part in the enforcement of access as defined 3010 by the ACL. 3012 [Author Aside]: Despite what is said later, the only such case I know 3013 of is the use of READ and EXECUTE where the client, but not the 3014 server, has any means of distinguishing these. I don't know of any 3015 others. If there were, how could ACCESS or OPEN be used to verify 3016 access? 3018 [Consensus Needed (Item #23a)]; Clients need to be aware of 3019 situations in which an object's ACL will define a certain access even 3020 though the server is not in position to enforce it because the server 3021 does not have the relevant information, such as knowing whether a 3022 READ is for the purpose of executing a file. Because of such 3023 situations, the client needs to do be prepared to do its part in the 3024 enforcement of access as defined by the ACL. 3026 To do this, the client will send the appropriate ACCESS operation 3027 prior to servicing the request of the user or application in order to 3028 determine whether the user or application is to be granted the access 3029 requested. 3031 [Previous Treatment (Item #24a)]: For examples in which the ACL may 3032 define accesses that the server doesn't enforce, see Section 8.1. 3034 [Author Aside]: The sentence above is clearly wrong since that 3035 section is about enforcement the server does do. The expectation is 3036 that it will be deleted as part of Consensus Item #24a. 3038 9. Combining Authorization Models 3040 9.1. Background for Combined Authorization Model 3042 Both RFCs 7530 [6] and 8881 [8] contain material relating to the 3043 need, when both mode and ACL attributes are supported, to make sure 3044 that the values are appropriately co-ordinated. Despite the fact 3045 that these discussions are different, they are compatible and differ 3046 in only a small number of areas relating to the existence absence of 3047 the set-mode-masked attribute. 3049 Such co-ordination is necessary is necessary since it is expected 3050 that servers providing both sets of attributes will encounter users 3051 who have no or very limited knowledge of one and need to work 3052 effectively when other users changes that attribute. As a result, 3053 these attributes cannot each be applied independently since that 3054 would create an untenable situation in which some users who have the 3055 right to control file access would find themselves unable to do so. 3057 [Author Aside]: From this point on, all paragraphs in this section, 3058 not other annotated are to be considered part of Consensus Item #25b. 3059 The description in this section of changes to be made reflects the 3060 author's proposal to address this issue and related issues. It might 3061 have to be adjusted based on working group decisions. 3063 As a result, in this document, we will have a single treatment of 3064 this issue, in Sections 9.2 through 9.12. In addition, an 3065 NFSv4.2-based extension related to attribute co-ordination will be 3066 described in Section 9.13. 3068 The current NFSv4.0 and NFSv4.1 descriptions of this co-ordination 3069 share an unfortunate characteristic in that they are both written to 3070 give server implementations a broad latitude in implementation 3071 choices while neglecting entirely the need for clients and users to 3072 have a reliable description of what servers are to do in this area. 3074 As a result, one of the goals of this new combined treatment will be 3075 to limit the uncertainty that the previous approach created for 3076 clients, while still taking proper account of the possibility of 3077 compatibility issues that a more tightly drawn specification might 3078 give rise to. 3080 The various ways in which these kinds of issues have been dealt with 3081 are listed below together with a description of the needed changes 3082 proposed to address each issue. 3084 * In some cases, the term "MAY" is used in contexts where it is 3085 inappropriate, since the allowed variation has the potential to 3086 cause harm in that it leaves the client unsure exactly what 3087 security-related action will be performed by the server. 3089 The new treatment will limit use use of MAY to cases in which it 3090 is truly necessary, in order to give clients proper notice of 3091 cases in which server behavior cannot be determined and limit the 3092 work necessary to deal with a large array of possible behaviors. 3094 * There are also cases in which no RFC2119-defined keywords are used 3095 but it is stated that certain server implementations do a 3096 particular thing, leaving the impression that that action is to be 3097 allowed, just as if "MAY" had been used. 3099 If the flexibility is necessary, MAY will be used. In other 3100 cases, SHOULD will be used with the understanding that maintaining 3101 compatibility with clients that have adapted to a particular 3102 approach to this issue is a valid reason to bypass the 3103 recommendation. However, in no case will it be implied, as it is 3104 in the current specifications, that the server MAY do whatever it 3105 chooses, with the client having no option but to adapt to that 3106 choice. 3108 * There was a case, in Section 9.2, in which the term "SHOULD" was 3109 explicitly used intentionally, without it being made clear what 3110 the valid reasons to ignore the guidance might be, although there 3111 was a reference to servers built to support the now-withdrawn 3112 draft definition of POSIX ACLs, which are referred to in this 3113 document as "UNIX ACLs", ass described in Section 4.1. A 3114 discussion of the issues for support of for these ACLs appears in 3115 Section 9.5. 3117 [Author Aside]: Despite the statement, now cited in Section 9.2, 3118 that this was to accommodate implementations "POSIX" ACLs, it now 3119 appears that this was not complete. I've been given to understand 3120 that this was the result of two groups disagreeing on the 3121 appropriate mapping from ACLs, and specifying both, using the 3122 "intentional" "SHOULD" essentially as a MAY, with the text now in 3123 Section 9.2 discouraging such use as potentially confusing, not 3124 intended to be taken seriously. Since the above information might 3125 not be appropriate in a standards-track RFC, we intend to retain 3126 this as an Author Aside which the working group might consider as 3127 it discusses how to navigate our way out of this situation. 3129 The new approach will use the term "RECOMMENDED" without use of 3130 the confusing term "intentional". The valid reasons to bypass the 3131 recommendation will be clearly explained as will be the 3132 consequences of choosing to do other than what is recommended. 3134 * There are many case in which the terms "SHOULD" and "SHOULD NOT" 3135 are used without any clear indication why they were used. In this 3136 situation it is possible that the "SHOULD" was essentially treated 3137 as a "MAY" but also possible that servers chose to follow the 3138 recommendation. 3140 In order to deal with the many uses of these terms in Section 9 3141 and included subsections, which have no clear motivation, it is to 3142 be assumed that the valid reasons to act contrary to the 3143 recommendation given are the difficulty of changing 3144 implementations based on previous analogous guidance, which may 3145 have given the impression that the server was free to ignore the 3146 guidance for any reason the implementer chose. This allows the 3147 possibility of more individualized treatment of these instances 3148 once compatibility issues have been adequately discussed. 3150 [Author Aside]: In each subsection in which the the interpretation 3151 of these term in the previous paragraph applies there will be an 3152 explicit reference to Consensus Item #25, to draw attention to 3153 this change, even in the absence of modified text. 3155 9.2. Needed Attribute Coordination 3157 On servers that support both the mode and the acl or dacl attributes, 3158 the server needs to keep the two consistent with each other. The 3159 value of the mode attribute (with the exception of the high-order 3160 bits reserved for client use as described in Section 7.3.1) are to be 3161 determined entirely by the value of the ACL, so that use of the mode 3162 is never required for anything other than setting and interrogating 3163 the three high-order bits. See Sections 9.7 through 9.9 for detailed 3164 discussion. 3166 [Previous Treatment (Item #25c)]: When a mode attribute is set on an 3167 object, the ACL attributes may need to be modified in order to not 3168 conflict with the new mode. In such cases, it is desirable that the 3169 ACL keep as much information as possible. This includes information 3170 about inheritance, AUDIT and ALARM ACEs, and permissions granted and 3171 denied that do not conflict with the new mode. 3173 [Author Aside]: one the things that this formulation leaves 3174 uncertain, is whether, if the ACL specifies permission for a named 3175 user group or group, it "conflicts" with the node. Ordinarily, one 3176 might think it does not, unless the specified user is the owner of 3177 the file or a member of the owning group, or the specified group is 3178 the owning group. However, while some parts of the existing 3179 treatment seem to agree with this, other parts, while unclear, seem 3180 to suggest otherwise, while the treatment in Section 9.7 is directly 3181 in conflict. 3183 [Previous Treatment (Item #26a)]: The server that supports both mode 3184 and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and 3185 MODE4_*OTH bits with the ACEs that have respective who fields of 3186 "OWNER@", "GROUP@", and "EVERYONE@". 3188 [Author Aside]: This sentence ignores named owners and group, giving 3189 the impressions that there is no need to change them. 3191 [Previous Treatment (Item #26a)]: This way, the client can see if 3192 semantically equivalent access permissions exist whether the client 3193 asks for the owner, owner_group, and mode attributes or for just the 3194 ACL. 3196 [Author Aside, Including List:] The above sentence, while hard to 3197 interpret for a number a reasons, is worth looking at in detail 3198 because it might suggest an approach different from the one in the 3199 previous sentence from the initial paragraph for The Previous 3200 Treatment of Item #26a. 3202 * The introductory phrase "this way" adds confusion because it 3203 suggests that there are other valid ways of doing this, while not 3204 giving any hint about what these might be. 3206 * It is hard to understand the intention of "client can see if 3207 semantically equivalent access permissions" especially as the 3208 client is told elsewhere that he is not to interpret the ACL 3209 himself. 3211 * If this sentence is to have any effect at all it, it would be to 3212 suggest that the result be the same "whether the client asks for 3213 the owner, owner_group, and mode attributes or for just the ACL." 3215 If these are to be semantically equivalent it would be necessary 3216 to delete ACEs for named users, which requires a different 3217 approach form the first sentence of the original paragraph. 3219 {Consensus Needed, Including List (Items #26a, #28a)]: A server that 3220 supports both mode and ACL attributes needs to take care to 3221 synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the 3222 ACEs that have respective who fields of "OWNER@", "GROUP@", and 3223 "EVERYONE@". This requires: 3225 * When the mode is changed, in most cases, the ACL attributes will 3226 need to be modified as described in Section 9.7. 3228 * When the ACL is changed, the corresponding mode is determined and 3229 used to set the nine low-oder bits of the mode attribute. 3231 This is relatively straightforward in the case of forward-slope 3232 modes, but the case of reverse-slope modes needs to be addressed 3233 as well. It is RECOMMENDED that the procedure presented in 3234 Section 9.3 be used or another one that provides the same results. 3236 The valid reasons to bypass this recommendation together with a 3237 alternate procedures to be used are discussed in Section 9.4. 3239 {Consensus Needed (Item #26a)]: How other ACEs are dealt with when 3240 setting mode is described in Section 9.7. This includes ACEs with 3241 other who values, all AUDIT and ALARM ACEs, and all ACES that affect 3242 ACL inheritance. 3244 [Previous Treatment (Item #27a)]: In this section, much depends on 3245 the method in specified Section 9.3. Many requirements refer to this 3246 section. It needs to be noted that the methods have behaviors 3247 specified with "SHOULD" and that alternate approaches are discussed 3248 in Section 9.4. This is intentional, to avoid invalidating existing 3249 implementations that compute the mode according to the withdrawn 3250 POSIX ACL draft (1003.1e draft 17), rather than by actual permissions 3251 on owner, group, and other. 3253 [Consensus (Item #27a)]: In performing the co-ordinarion discussed in 3254 this section, the method used to compute the mode from the ACL has an 3255 important role. While the approach specified in Section 9.3 is 3256 RECOMMENDED, it needs to be noted that the alternate approaches 3257 discussed in Section 9.4 are valid in some cases. As discussed in 3258 that section, an important reason for allowing multiple ways of doing 3259 this is to accommodate server implementations that compute the mode 3260 according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather 3261 than by actual permissions on owner, group, and other. While, this 3262 means that a client, having no way of determining the method the 3263 server uses may face interoperability difficulties in moving between 3264 servers which approach this matter differently, these problems need 3265 to be accepted for the time being. A more complete discussion of 3266 handling of the UNIX ACLs is to be found in Section 9.5. 3268 [Consensus Needed, Including List (Items #27a, #28a)]: All valid 3269 methods of computing the mode from an ACL use the following procedure 3270 to derive a set of mode bits from a set of three ACL masks, with the 3271 only difference being in how the set of ACL masks is constructed. 3272 The calculated mask for for each set of bits in mode are derived from 3273 the ACL mask for owner, group, other are derived as follows: 3275 1. Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and 3276 only if ACE4_READ_DATA is set in the corresponding mask. 3278 2. Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and 3279 only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the 3280 corresponding mask. 3282 3. Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if 3283 and only if ACE4_EXECUTE is set in the corresponding mask. 3285 9.3. Computing a Mode Attribute from an ACL 3287 [Previous Treatment (Item #27b)]: The following method can be used to 3288 calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode 3289 attribute, based upon an ACL. 3291 [Author Aside]: "can be used" says essentially "do whatever you 3292 choose" and would make Section 9 essentially pointless. Would prefer 3293 "is to be used" or "MUST", with "SHOULD" available if valid reasons 3294 to do otherwise can be found. 3296 [Consensus Needed (Items #27b, #28b)}: The following method (or 3297 another one providing exactly the same results) SHOULD be used to 3298 calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode 3299 attribute, based upon an ACL. In this case, one of the valid reasons 3300 to bypass the recommendation includes implementor reliance on 3301 previous specifications which ignored the cases of the owner having 3302 less access than the owning group or the owning group having less 3303 access than others. Further, in implementing or the maintaining an 3304 implementation previously believed to be valid, the implementor needs 3305 to be aware that this will result invalid values in some uncommon 3306 cases. Other reasons to bypass the recommendation are discussed in 3307 Section 9.4. 3309 [Author Aside, Including List]: The algorithm specified below, now 3310 considered the Previous Treatment associated with Item #24a, has an 3311 important flaw in does not deal with the (admittedly uncommon) case 3312 in which the owner_group has less access than the owner or others 3313 have less access than the owner-group. In essence, this algorithm 3314 ignores the following facts: 3316 * That GROUP@ includes the owning user while group bits in the mode 3317 do not affect the owning user. 3319 * That EVERYONE includes the owning group while other bits in the 3320 mode do not affect users within the owning group. 3322 [Previous Treatment (Item #28b)]: First, for each of the special 3323 identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, 3324 considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and 3325 for the identifier under consideration. The result of the evaluation 3326 will be an NFSv4 ACL mask showing exactly which bits are permitted to 3327 that identifier. 3329 [Previous Treatment (Item #28b)]: Then translate the calculated mask 3330 for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively, 3331 the user, group, and other, as follows: 3333 [Consensus Needed, including List(Item #28b)]: First, for each of the 3334 sets of mode bits (i.e., user, group other, evaluate the ACL in 3335 order, with a specific evaluation procedure depending on the specific 3336 set of mode bits being determined. For each set there will be one or 3337 more special identifiers considered in a positive sense so that ALLOW 3338 and DENY ACE's are considered in arriving at the mode bit. In 3339 addition, for some sets of bits, there will be one or more special 3340 identifiers to be considered only in a negative sense, so that only 3341 DENY ACE's are considered in arriving at the mode it. The users to 3342 be considered are as follows: 3344 * For the owner bits, "OWNER@" and "EVERYONE@" are to be considered, 3345 both in a positive sense. 3347 * For the group bits, "GROUP@" and "EVERYONE@" are to be considered, 3348 both in a positive sense, while "OWNER@" is to be considered in a 3349 negative sense. 3351 * For the other bit, "EVERYONE@" is to be considered in a positive 3352 sense, while "OWNER@" and "GROUP@" are to be considered in a 3353 negative sense. 3355 [Consensus Needed (Item #28b)]: Once these ACL masks are constructed, 3356 the mode bits for, user, group, and other can be obtained as 3357 described in Section 9.2 above. 3359 9.4. Alternatives in Computing Mode Bits 3361 [Author Aside]: All unannotated paragraphs within this section are to 3362 be considered the Previous Treatment corresponding to Consensus Item 3363 #27c. 3365 Some server implementations also add bits permitted to named users 3366 and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and 3367 MODE4_XGRP). 3369 Implementations are discouraged from doing this, because it has been 3370 found to cause confusion for users who see members of a file's group 3371 denied access that the mode bits appear to allow. (The presence of 3372 DENY ACEs may also lead to such behavior, but DENY ACEs are expected 3373 to be more rarely used.) 3375 [Author Aside]: The text does not seem to really discourage this 3376 practice and makes no reference to the need to standardize behavior 3377 so the clients know what to expect or any other reason for providing 3378 standardization of server behavior. 3380 The same user confusion seen when fetching the mode also results if 3381 setting the mode does not effectively control permissions for the 3382 owner, group, and other users; this motivates some of the 3383 requirements that follow. 3385 [Author Aside]: The part before the semicolon appears to be relevant 3386 to Consensus Item #23 but does not point us to a clear conclusion. 3387 The statement certainly suggests that the 512-ACL approach is more 3388 desirable but the absence of a more direct statement to that effect 3389 suggest that this is a server implementer choice. 3391 [Author Aside]: The part after the semicolon is hard to interpret in 3392 that it is not clear what "this" refers to or which which 3393 requirements are referred to by "some of the requirements that 3394 follow". The author would appreciate hearing from anyone who has 3395 insight about what might have been intended here. 3397 [Consensus Needed, Including List (Item #27c)]: In cases in which the 3398 mode is not computed as described in Section 9.3, one of the 3399 following analogous procedures or their equivalents, MUST be used. 3401 * First, for each of the special identifiers OWNER@ and EVERYONE@, 3402 evaluate the ACL in order, considering only ALLOW and DENY ACEs 3403 for the identifier EVERYONE@ and for the identifier under 3404 consideration. 3406 For the special identifier GROUP@, ALLOW and DENY ACEs for GROUP@ 3407 and EVERYONE@ are to be considered, together with ALLOW ACEs for 3408 named users and groups. 3410 This represents the approach previously recommended to compute 3411 mode in previous specification, as modified to reflect the UNIX 3412 ACL practice of reflecting permissions for named users and groups. 3413 It does not deal properly with reverse-slope modes. 3415 * Compute a set of ACL mask according to the procedure in 3416 Section 9.3 and then, for the mask associated with GROUP@, or in 3417 the masks for all ALLOW ACEs for named users and groups. 3419 This represents the approach currently recommended to compute mode 3420 in Section 9.3 as modified to reflect the UNIX ACL practice of 3421 reflecting permissions for named users and groups. 3423 [Consensus Needed, Including List (Item #27c)]: In both cases, The 3424 results of the evaluation will be a set of NFSv4 ACL masks which can 3425 be converted to the set on nine low-order mode bits using the 3426 procedure appearing in Section 9.2 above. 3428 [Consensus Needed, Including List (Item #27c)]: When the 3429 recommendation to use Section 9.3 is bypassed, it needs to be 3430 understood, that the modes derived will differ from the expected 3431 values and might cause interoperability issues. This is particularly 3432 the case when clients have no way to determine that the server's 3433 behavior is other than standard. 3435 9.5. Handling of UNIX ACLs 3437 [Author Aside]: All paragraphs in this section are consider part of 3438 Consensus Item #56b. 3440 Although the working group did not adopt the acls in the withdrawn 3441 POSIX draft, their continued existence in UNIX contexts has created 3442 protocol difficulties that need to be resolved. In many cases these 3443 ACLS and their associated semantics are the basis for ACL support in 3444 UNIX client APIs and in UNIX file systems supported by NFSv4 3446 Although the semantic range of UNIX ACLs is a subset of that for 3447 NFSv4 ACLs, expecting clients to perform that mapping on their own 3448 has not worked well, leading to the following issues which will, at 3449 some point, need to be addressed: 3451 * There is a considerable uncertainty about the proper mapping from 3452 ACLs to modes. 3454 * The corresponding mapping from modes to ACLs is dealt with 3455 different ways by different sections of the spec. 3457 * These individual uncertainties are compounded since it is 3458 difficult, in this environment, to ensure that these independently 3459 chosen mappings are inverses of one another, as they are intended 3460 to be. 3462 Some possible approaches to these issues are discussed in Section 16, 3464 9.6. Setting Multiple ACL Attributes 3466 In the case where a server supports the sacl or dacl attribute, in 3467 addition to the acl attribute, the server MUST fail a request to set 3468 the acl attribute simultaneously with a dacl or sacl attribute. The 3469 error to be given is NFS4ERR_ATTRNOTSUPP. 3471 9.7. Setting Mode and not ACL (overall) 3472 9.7.1. Setting Mode and not ACL (vestigial) 3474 [Author Aside]: All unannotated paragraphs are to be considered the 3475 Previous treatment of Consensus Item #30a. 3477 [Previous Treatment (Item #?a)]: When any of the nine low-order mode 3478 bits are subject to change, either because the mode attribute was set 3479 or because the mode_set_masked attribute was set and the mask 3480 included one or more bits from the nine low-order mode bits, and no 3481 ACL attribute is explicitly set, the acl and dacl attributes must be 3482 modified in accordance with the updated value of those bits. This 3483 must happen even if the value of the low-order bits is the same after 3484 the mode is set as before. 3486 Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl 3487 attribute) are unaffected by changes to the mode. 3489 In cases in which the permissions bits are subject to change, the acl 3490 and dacl attributes MUST be modified such that the mode computed via 3491 the method in Section 9.3 yields the low-order nine bits (MODE4_R*, 3492 MODE4_W*, MODE4_X*) of the mode attribute as modified by the 3493 attribute change. The ACL attributes SHOULD also be modified such 3494 that: 3496 1. If MODE4_RGRP is not set, entities explicitly listed in the ACL 3497 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3498 ACE4_READ_DATA. 3500 2. If MODE4_WGRP is not set, entities explicitly listed in the ACL 3501 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3502 ACE4_WRITE_DATA or ACE4_APPEND_DATA. 3504 3. If MODE4_XGRP is not set, entities explicitly listed in the ACL 3505 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3506 ACE4_EXECUTE. 3508 Access mask bits other than those listed above, appearing in ALLOW 3509 ACEs, MAY also be disabled. 3511 Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect 3512 the permissions of the ACL itself, nor do ACEs of the type AUDIT and 3513 ALARM. As such, it is desirable to leave these ACEs unmodified when 3514 modifying the ACL attributes. 3516 Also note that the requirement may be met by discarding the acl and 3517 dacl, in favor of an ACL that represents the mode and only the mode. 3518 This is permitted, but it is preferable for a server to preserve as 3519 much of the ACL as possible without violating the above requirements. 3520 Discarding the ACL makes it effectively impossible for a file created 3521 with a mode attribute to inherit an ACL (see Section 9.11). 3523 9.7.2. Setting Mode and not ACL (Discussion) 3525 [Author Aside]: All unannotated paragraphs are to be considered 3526 Author Asides relating to Consensus Item #30b. 3528 Existing documents are unclear about the changes to be made to an 3529 existing ACL when the nine low-order bits of the mode attribute are 3530 subject to modification using SETATTR. 3532 A new treatment needs to apply to all minor versions. It will be 3533 necessary to specify that, for all minor versions, setting of the 3534 mode attribute, subjects the low-order nine bits to modification. 3536 One important source of this lack of clarity is the following 3537 paragraph from Section 9.7.1, which we refer to later as the trivial- 3538 implementation-remark". 3540 Also note that the requirement may be met by discarding the acl 3541 and dacl, in favor of an ACL that represents the mode and only the 3542 mode. This is permitted, but it is preferable for a server to 3543 preserve as much of the ACL as possible without violating the 3544 above requirements. Discarding the ACL makes it effectively 3545 impossible for a file created with a mode attribute to inherit an 3546 ACL (see Section 9.11). 3548 The only "requirement" which might be met by the procedure mentioned 3549 above is the text quoted below. 3551 In cases in which the permissions bits are subject to change, the 3552 acl and dacl attributes MUST be modified such that the mode 3553 computed via the method in Section 9.3 yields the low-order nine 3554 bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as 3555 modified by the attribute change. 3557 While it is true that this requirement could be met by the specified 3558 treatment, this fact does not, in itself, affect the numerous 3559 recommendations that appear between the above requirement and the 3560 trivial-implementation-remark. 3562 It may well be that there are are implementations that have treated 3563 the trivial-implementation-remark as essentially allowing them to 3564 essentially ignore all of those recommendations, resulting in a 3565 situation in which were treated as if it were a trivial- 3566 implementation-ok indication. How that issue will be dealt with in a 3567 replacement for Section 9.7.1 will be affected by the working group's 3568 examination of compatibility issues. 3570 The following specific issues need to be addressed: 3572 * Handling of inheritance. 3574 Beyond the possible issues that arise from the trivial- 3575 implementation-ok interpretation, the treatment in Section 9.7.1, 3576 by pointing specifically to existing INHERIT_ONLY ACEs obscures 3577 the corresponding need to convert ACE's that specify both 3578 inheritance and access permissions to be converted to INHERIT_ONLY 3579 ACEs. 3581 * Reverse-slope modes 3583 * Named users and groups. 3585 * The exact bounds of what within the ACL is covered by the low- 3586 order bits of the mode. 3588 It appears that for many of the issues, there are many possible 3589 readings of the existing specs, leading to the possibility of 3590 multiple inconsistent server behaviors. Furthermore, there are cases 3591 in which none of the possible behaviors described in existing 3592 specifications meets the needs. 3594 As a result of these issues, the existing specifications do not 3595 provide a reliable basis for client-side implementations of the ACL 3596 feature which a Proposed Standard is normally expected to provide. 3598 9.7.3. Setting Mode and not ACL (Proposed) 3600 [Author Aside]: This proposed section is part of Consensus Item #30c 3601 and all unannotated paragraphs within it are to be considered part of 3602 that Item. Since the proposed text includes support for reverse- 3603 slope modes, treats all minor versions together and assumes decisions 3604 about handling of ACEs for named users and groups, the relevance of 3605 consensus items #26, #28, and #29 needs to be noted. 3607 [Author Aside]: As with all such Consensus Items, it is expected that 3608 the eventual text in a published RFC might be substantially different 3609 based on working group discussion of client and server needs and 3610 possible compatibility issues. In this particular case, that 3611 divergence can be expected to be larger, because the author was 3612 forced to guess about compatibility issues and because earlier 3613 material, on which it is based left such a wide range of matters to 3614 the discretion of server implementers. It is the author's hope that, 3615 as the working group discusses matters, sufficient attention is 3616 placed on the need for client-side implementations to have reliable 3617 information about expected server-side actions. 3619 This section describes how ACLs are to be updated in response to 3620 actual or potential changes in the mode attribute, when the 3621 attributes needed by both of the file access authorization models are 3622 supported. It supersedes the discussions of the subject in RFCs 7530 3623 [6] and 8881 [8], each of which appeared in Section 6.4.1.1 of the 3624 corresponding document. 3626 It is necessary to approach the matter differently than in the past 3627 because: 3629 * Organizational changes are necessary to address all minor versions 3630 together. 3632 * Those previous discussions are often internally inconsistent 3633 leaving it unclear what specification-mandated actions were being 3634 specified.. 3636 * In many cases, servers were granted an extraordinary degree of 3637 freedom to choose the action to take, either explicitly or via an 3638 apparently unmotivated use of "SHOULD", leaving it unclear what 3639 might be considered "valid" reasons to ignore the recommendation. 3641 * There appears to have been no concern for the problems that 3642 clients and applications might encounter dealing ACLs in such an 3643 uncertain environment. 3645 * Cases involving reverse-slope modes were not adequately addressed. 3647 * The security-related effects of SVTX were not addressed. 3649 While that sort of approach might have been workable at one time, it 3650 made it difficult to devise client-side ACL implementations, even if 3651 there had been any interest in doing so. In order to enable this 3652 situation to eventually be rectified, we will define the preferred 3653 implementation here, but in order to provide temporary compatibility 3654 with existing implementations based on reasonable interpretations of 3655 RFCs 7530 [6] and 8881 [8]. To enable such compatibility the term 3656 "SHOULD" will be used, with the understanding that valid reasons to 3657 bypass the recommendation, are limited to implementers' previous 3658 reliance on these earlier specifications and the difficulty of 3659 changing them now. 3661 When the recommendation is bypassed in this way, it is necessary to 3662 understand, that, until the divergence is rectified, or the client is 3663 given a way to determine the detail of the server's non-standard 3664 behavior, client-side implementations may find it difficult to 3665 implement a client-side implementation that correctly interoperates 3666 with the existing server. 3668 When mode bits involved in determining file access authorization are 3669 subject to modification, the server MUST, when ACL-related attributes 3670 have been set, modify the associated ACEs so as not to conflict with 3671 the new value of the mode attribute. 3673 The occasions to which this requirement applies, vary with the 3674 attribute being set and the type of object being dealt with: 3676 * For all minor versions, any change to the mode attribute, triggers 3677 this requirement 3679 * When the set_mode_masked attribute is being set on an object which 3680 is not a directory, whether this requirement is triggered depends 3681 on whether any of the nine low-order bits of the mode is included 3682 in the mask. 3684 * When the set_mode_masked attribute is being set on a directory, 3685 whether this requirement is triggered depends on whether any of 3686 the nine low-order bits of the mode or the SVTX bit is included in 3687 the mask of bit whose values are to be set. 3689 When the requirement is triggered, ACEs need to be updated to be 3690 consistent with the new mode attribute. In the case of AUDIT and 3691 ALARM ACEs, which are outside of file access authorization, no change 3692 is to be made. 3694 For ALLOW and DENY ACEs, changes are necessary to avoid conflicts 3695 with the mode in a number of areas: 3697 * The handling of ACEs that have consequences relating to ACL 3698 inheritance. 3700 * The handling of ACEs with a who-value of OWNER@, GROUP@, or 3701 EVERYONE@ need to be adapted to the new mode. 3703 * ACEs whose who-value is a named user or group, are to be retained 3704 or not based on the mode being set as described below. 3706 * ACEs whose who-value is one of the other special values defined in 3707 Section 5.9 are to be left unmodified. 3709 In order to deal with inheritance issues, the following SHOULD be 3710 done: 3712 * ACEs that specify inheritance-only need to be retained, regardless 3713 of the value of who specified, since inheritance issues are 3714 outside of the semantic range of the mode attribute. 3716 * ACEs that specify inheritance, in addition to allowing or denying 3717 authorization for the current object need to be converted into 3718 inheritance-only ACEs. This needs to occur irrespective of the 3719 value of who appearing in the ACE. 3721 For NFSv4 servers that support the dacl attribute, at least the first 3722 of the above MUST be done. 3724 Other ACEs are to be treated are classified based on the ACE's who- 3725 value: 3727 * ACEs whose who-value is OWNER@, GROUP@, or EVERYONE@ are referred 3728 to as mode-directed ACEs and are subject to extensive 3729 modification. 3731 * ACEs whose who-value is a named user or group are either left 3732 alone or subject to extensive modification, as described below. 3734 * ACEs whose who-value is one of the other special values defined in 3735 Section 5.9 are left as they are. 3737 Mode-directed ACEs need to be modified so that they reflect the mode 3738 being set. 3740 In effecting this modification, the server will need to distinguish 3741 mask bits deriving from mode attributes from those that have no such 3742 connection. The former can be categorized as follows: 3744 * For non-directory objects, the mask bits ACE4_READ_DATA (from the 3745 read bit in the mode), ACE4_EXECUTE (from the execute bit in the 3746 mode), and ACE4_WRITE_DATA together with ACE4_APPEND_DATA (from 3747 the write bit in the mode) are all derived from the set of three 3748 mode bits appropriate to the current who-value. 3750 * For directories, analogous mask bits are included: 3751 ACE4_LIST_DIRECTORY (from the read in the mode), ACE4_EXECUTE 3752 (from the execute bit in the mode), and ACE4_ADD_FILE together 3753 with ACE4_ADD_SUBDIRECTORY and ACE4_DELETE_CHILD> (from the write 3754 bit in the mode) are all included based on the set of three mode 3755 bits appropriate to the current who-value. 3757 When the SVTX bit is set, ACE4_DELETE_CHILD is set, regardless of 3758 the values of the low-order nine bit of the mode. 3760 * When named attributes are supported for the object whose mode is 3761 subject to change, ACE4_READ_NAMED_ATTRIBUTES is set based on the 3762 read bit and ACE4_WRITE_NAMED_ATTRIBUTES is set based on the write 3763 bit based on the set of three mode bits appropriate to the current 3764 who-value. 3766 * In the case of OWNER@, ACE4_WRITE_ACL, ACE4_WRITE_ATTRIBUTES 3767 ACE4_WRITE_ACL, ACE4_WRITE_OWNER are all set. 3769 The union of these groups of mode bit are referred to as the mode- 3770 relevant mask bits. 3772 [Author Aside]: Except for the case of ACE4_SYNCHRONIZE, the handling 3773 of mask bits which are not mode-relevant is yet to be clarified. For 3774 tracking purposes, the handling of mask bits ACE4_READ_ATTRIBUTES, 3775 ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD, ACE4_READ_ACL will 3776 be dealt with as Consensus Item #31. 3778 If the mode is of forward-slope, then each set of three bits is 3779 translated into a corresponding set of mode bits. Then, for each 3780 ALLOW ACE with one of these who values, all mask bits in this class 3781 are deleted and the computed mode bits for that who-value 3782 substituted. For DENY ACEs, all mask bits in this class are reset, 3783 and, if none remain, the ACE MAY be deleted. 3785 In the case of reverse-slope modes, the following SHOULD be done: 3787 * For mode-directed ACEs all mode-relevant mask bits are reset, and, 3788 if none remain, the ACE MAY be deleted. 3790 * Then, proceeding from owner to others, ALLOW ACEs are generated 3791 based on the computed mode-relevant mask bits. 3793 At each stage, if the mode-relevant mask bits for the current 3794 stage includes mask bits not set for the previous stage, then a 3795 DENY ACE needs to be added before the new ALLOW ACE. That ACE 3796 will have a who-value based on the previous stage and a mask 3797 consisting of the bit included in the current stage that were not 3798 included in the previous stage. 3800 In cases in which the above recommendation is not followed, the 3801 server MUST follow a procedure which arrives at an ACL which behaves 3802 identically for all cases involving forward-slope mode values. 3804 When dealing with ACEs whose who-value is a named user or group, they 3805 SHOULD be processed as follows: 3807 * DENY ACEs are left as they are. 3809 * ALLOW ACES are subject to filtering to effect mode changes that 3810 deny access to any principal other than the owner. 3812 To determine the set of mode bits to which this filtering applies, 3813 the mode bits for group are combined with those for others, to get 3814 a set of three mode bits to determine which of the mode privileges 3815 (read, write, execute) are denied to all principals other than the 3816 owner, i.e. the set of bits not present in either the bits for 3817 group or the bits for others. 3819 Those three bits are converted to the corresponding set of mask 3820 bits, according to the rules above. 3822 All such mask bits are reset in the ACE, and, if none remain, the 3823 ACE MAY be deleted. 3825 In cases in which the above recommendation is not followed, the 3826 server MUST follow a procedure which arrives at an ACL which behaves 3827 identically for all cases involving forward-slope mode values. This 3828 would be accomplished if the mask bits were reset based on the group 3829 bits alone, as had been recommended in earlier specifications. 3831 9.8. Setting ACL and Not Mode 3833 [Author Aside]: The handling of SHOULD in this section is considered 3834 as part of Consensus Item #25d. 3836 When setting the acl or dacl and not setting the mode or 3837 mode_set_masked attributes, the permission bits of the mode need to 3838 be derived from the ACL. In this case, the ACL attribute SHOULD be 3839 set as given. The nine low-order bits of the mode attribute 3840 (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result 3841 of the method in Section 9.3. The three high-order bits of the mode 3842 (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged. 3844 9.9. Setting Both ACL and Mode 3846 When setting both the mode (includes use of either the mode attribute 3847 or the mode_set_masked attribute) and the acl or dacl attributes in 3848 the same operation, the attributes MUST be applied in the following 3849 order order: mode (or mode_set_masked), then ACL. The mode-related 3850 attribute is set as given, then the ACL attribute is set as given, 3851 possibly changing the final mode, as described above in Section 9.8. 3853 9.10. Retrieving the Mode and/or ACL Attributes 3855 [Author Aside]: The handling of SHOULD in this section is considered 3856 as part of Consensus Item #25e. 3858 Some server implementations may provide for the existence of "objects 3859 without ACLs", meaning that all permissions are granted and denied 3860 according to the mode attribute and that no ACL attribute is stored 3861 for that object. If an ACL attribute is requested of such a server, 3862 the server SHOULD return an ACL that does not conflict with the mode; 3863 that is to say, the ACL returned SHOULD represent the nine low-order 3864 bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as 3865 described in Section 9.3. 3867 For other server implementations, the ACL attribute is always present 3868 for every object. Such servers SHOULD store at least the three high- 3869 order bits of the mode attribute (MODE4_SUID, MODE4_SGID, 3870 MODE4_SVTX). The server SHOULD return a mode attribute if one is 3871 requested, and the low-order nine bits of the mode (MODE4_R*, 3872 MODE4_W*, MODE4_X*) MUST match the result of applying the method in 3873 Section 9.3 to the ACL attribute. 3875 9.11. Creating New Objects 3877 [Author Aside]: The handling of SHOULD in this section is considered 3878 as part of Consensus Item #25f. 3880 If a server supports any ACL attributes, it may use the ACL 3881 attributes on the parent directory to compute an initial ACL 3882 attribute for a newly created object. This will be referred to as 3883 the inherited ACL within this section. The act of adding one or more 3884 ACEs to the inherited ACL that are based upon ACEs in the parent 3885 directory's ACL will be referred to as inheriting an ACE within this 3886 section. 3888 Implementors need to base the behavior of CREATE and OPEN depending 3889 on the presence or absence of the mode and ACL attributes by 3890 following the directions below: 3892 1. If just the mode is given in the call: 3894 In this case, inheritance SHOULD take place, but the mode MUST be 3895 applied to the inherited ACL as described in Section 9.7, thereby 3896 modifying the ACL. 3898 2. If just the ACL is given in the call: 3900 In this case, inheritance SHOULD NOT take place, and the ACL as 3901 defined in the CREATE or OPEN will be set without modification, 3902 and the mode modified as in Section 9.8. 3904 3. If both mode and ACL are given in the call: 3906 In this case, inheritance SHOULD NOT take place, and both 3907 attributes will be set as described in Section 9.9. 3909 4. If neither mode nor ACL is given in the call: 3911 In the case where an object is being created without any initial 3912 attributes at all, e.g., an OPEN operation with an opentype4 of 3913 OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD 3914 NOT take place (note that EXCLUSIVE4_1 is a better choice of 3915 createmode4, since it does permit initial attributes). Instead, 3916 the server SHOULD set permissions to deny all access to the newly 3917 created object. It is expected that the appropriate client will 3918 set the desired attributes in a subsequent SETATTR operation, and 3919 the server SHOULD allow that operation to succeed, regardless of 3920 what permissions the object is created with. For example, an 3921 empty ACL denies all permissions, but the server need to allow 3922 the owner's SETATTR to succeed even though WRITE_ACL is 3923 implicitly denied. 3925 In other cases, inheritance SHOULD take place, and no 3926 modifications to the ACL will happen. The mode attribute, if 3927 supported, MUST be as computed in Section 9.3, with the 3928 MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no 3929 inheritable ACEs exist on the parent directory, the rules for 3930 creating acl, dacl, or sacl attributes are implementation 3931 defined. If either the dacl or sacl attribute is supported, then 3932 the ACL4_DEFAULTED flag SHOULD be set on the newly created 3933 attributes. 3935 9.12. Use of Inherited ACL When Creating Objects 3937 [Author Aside]: The handling of SHOULD in this section is considered 3938 as part of Consensus Item #25g. 3940 If the object being created is not a directory, the inherited ACL 3941 SHOULD NOT inherit ACEs from the parent directory ACL unless the 3942 ACE4_FILE_INHERIT_ACE flag is set. 3944 If the object being created is a directory, the inherited ACL is to 3945 inherit all inheritable ACEs from the parent directory, that is, 3946 those that have the ACE4_FILE_INHERIT_ACE or 3947 ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has 3948 ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear, 3949 the inherited ACE on the newly created directory MUST have the 3950 ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being 3951 affected by ACEs meant for non-directories. 3953 When a new directory is created, the server MAY split any inherited 3954 ACE that is both inheritable and effective (in other words, that has 3955 neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set), 3956 into two ACEs, one with no inheritance flags and one with 3957 ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute, 3958 both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.) 3959 This makes it simpler to modify the effective permissions on the 3960 directory without modifying the ACE that is to be inherited to the 3961 new directory's children. 3963 9.13. Combined Authorization Models for NFSv4.2 3965 The NFSv4 server implementation requirements described in the 3966 subsections above apply to NFSv4.2 as well and NFSv4.2 clients can 3967 assume that the server follows them. 3969 NFSv4.2 contains an OPTIONAL extension, defined in RFC8257 [15], 3970 which is intended to reduce the interference of modes, restricted by 3971 the umask mechanism, with the acl inheritance mechanism. The 3972 extension allows the client to specify the umask separately from the 3973 mask attribute. 3975 10. Labelled NFS Authorization Model 3977 The labelled NFS feature of NFSv4.2 is designed to support Mandatory 3978 Access control. 3980 The attribute sec_label enables an authorization model focused on 3981 Mandatory Access Control and is described in Section 10. 3983 Not much can be said about this feature because the specification, in 3984 the interest of flexibility, has left important features undefined in 3985 order to allow future extension. As a result, we have something that 3986 is a framework to allow Mandatory Access Control rather than one to 3987 provide it. In particular, 3989 * The sec_label attribute, which provides the objects label has no 3990 existing specification. 3992 * There is no specification of the of the format of the subject 3993 label or way to authenticate them. 3995 * As a result, all authorization takes place on the client, and the 3996 server simply accepts the client's determination. 3998 This arrangements shares important similarities with AUTH_SYS. As 3999 such it makes sense: 4001 * To require/recommend that an encrypted connection be used. 4003 * To require/recommend that client and server peers mutually 4004 authenticate as part of connection establishment. 4006 * That work be devoted to providing a replacement without the above 4007 issues. 4009 11. State Modification Authorization 4011 Modification of locking and session state data are not be done by a 4012 client other than the one that created the lock. For this form of 4013 authorization, the server needs to identify and authenticate client 4014 peers rather than client users. 4016 Such authentication is not directly provided by any RPC auth flavor. 4017 However, RPC can, when suitably configured, provide this 4018 authentication on a per-connection basis. 4020 NFSv4.1 defines a number of ways to provide appropriate authorization 4021 facilities. These will not be discussed in detail here but the 4022 following points need to be noted: 4024 * NFSv4.1 defines the MACHCRED mechanism which uses the RPCSEC_GSS 4025 infrastructure to provide authentication of the clients peer. 4026 However, this is of no value when AUTH_SYS is being used. 4028 * NFSv4.1 also defines the SSV mechanism which uses the RPCSEC_GSS 4029 infrastructure to enable it to be reliably determined whether two 4030 different client connections are connected to the same client. It 4031 is unclear whether the word "authentication" is appropriate in 4032 this case. As with MACHCRED, this is of no value when AUTH_SYS is 4033 being used. 4035 * Because of the lack of support for AUTH_SYS and for NFSv4.0, it is 4036 quite desirable for clients to use and for servers to require the 4037 use of client-peer authentication as part of connection 4038 establishment. 4040 When unauthenticated clients are allowed, their state is exposed to 4041 unwanted modification as part of disruption or denial-of-service 4042 attacks. As a result, the potential burdens of such attacks are felt 4043 principally by clients who choose not to provide such authentication. 4045 12. Other Uses of Access Control Lists 4047 Whether the acl or sacl attributes are used, AUDIT and ALARM ACEs 4048 provide security-related facilities separate from the the file access 4049 authorization provide by ALLOW and DENY ACEs 4051 * AUDIT ACEs provide a means to audit attempts to access a specified 4052 file by specified sets of principals. 4054 * ALARM ACEs provide a means to draw special attention to attempts 4055 to access specified files by specified sets of principals. 4057 12.1. V4.1 Attribute 59: sacl 4059 The sacl attribute is like the acl attribute, but sacl allows only 4060 AUDIT and ALARM ACEs. The sacl attribute supports automatic 4061 inheritance (see Section 5.10). 4063 13. Identification and Authentication 4065 Various objects and subjects need to be identified for a protocol to 4066 function. For it to be secure, many of these need to be 4067 authenticated so that incorrect identification is not the basis for 4068 attacks. 4070 13.1. Identification vs. Authentication 4072 It is necessary to be clear about this distinction which has been 4073 obscured in the past, by the use of the term "RPC Authentication 4074 Flavor" in connection with situation in which identification without 4075 authentication occurred or in which there was neither identification 4076 nor authentication involved. As a result, we will use the term "Auth 4077 Flavors" instead 4079 13.2. Items to be Identified 4081 Some identifier are not security-relevant and can used be used 4082 without authentication, given that, in the authorization decision, 4083 the object acted upon needs only to be properly identified 4085 * File names are of this type. 4087 Unlike the case for some other protocols, confusion of names that 4088 result from internationalization issues, while an annoyance, are 4089 not relevant to security. If the confusion between LATIN CAPITAL 4090 LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file 4091 being accessed, the mechanisms described in Section 7 prevent in 4092 appropriate access being granted. 4094 Despite the above, it is desirable if file names together with 4095 similar are not transferred in the clear as the information 4096 exposed may give attackers useful information helpful in planning 4097 and executing attacks. 4099 * The case of file handles is similar. 4101 Identifiers that refer to state shared between client and server can 4102 be the basis of disruption attacks since clients and server 4103 necessarily assume that neither side will change the state corpus 4104 without appropriate notice. 4106 While these identifiers do not need to be authenticated, they are 4107 associated with higher-level entities for which change of the state 4108 represented by those entities is subject to peer authentication. 4110 * Unexpected closure of stateids or changes in state sequence values 4111 can disrupt client access as no clients have provision to deal 4112 with this source of interference. 4114 While encryption may make it more difficult to execute such 4115 attacks attackers can often guess stateid's since server generally 4116 not randomize them. 4118 * Similarly, modification to NFSv4.1 session state information can 4119 result in confusion if an attacker changes the slot sequence by 4120 assuring spurious requests. Even if the request is rejected, the 4121 slot sequence is changed and clients may a difficult time getting 4122 back in sync with the server. 4124 While encryption may make it more difficult to execute such 4125 attacks attackers can often guess slot id's and obtain sessinid's 4126 since server generally do not randomize them. 4128 it is necessary that modification of the higher-levell entities be 4129 restricted to the client that created them. 4131 * For NFSv4.0, the relevant entity is the clientid. 4133 * for NFSv4.1, the relevant entity is the sessionid. 4135 Identifiers describing the issuer of the request, whether in numeric 4136 or string form always require authentication. 4138 13.3. Authentication Provided by specific RPC Auth Flavors 4140 Different auth flavors differ quite considerably, as discussed below; 4142 * When AUTH_NONE is used, the user making the request is neither 4143 authenticated nor identified to the server. 4145 Also, the server is not authenticated to the client and has no way 4146 to determine whether the server it is communicating with is an 4147 imposter. 4149 * When AUTH_SYS is used, the user making is the request identified 4150 but there no authentication of that identification. 4152 As in the previous case, the server is not authenticated to the 4153 client and has no way to determine whether the server it is 4154 communicating with is an imposter. 4156 * When RPCSEC_GSS is used, the user making the request is 4157 authenticated as is the server peer responding. 4159 13.4. Authentication Provided by other RPC Security Services 4161 Depending on the connection type used, RPC may provide additional 4162 means of authentication. In contrast with the case of RPC auth 4163 flavors, any authentication happens once, at connection 4164 establishment, rather than on each RPC request. As a result, it is 4165 the client and server peers, rather than individual users that are 4166 authenticated. 4168 * For many types of connections such as those created TCP without 4169 RPC-with-TLS and RPC-over-RDMA version 1, there is no provision 4170 for peer authentication. 4172 As a result use of AUTH_SYS using such connections is inherently 4173 problematic. 4175 * Some connection types provide for the possibility of mutual peer 4176 authentication. These currently include only those established by 4177 RPC-with-TLS. However, given the value of peer authentication, 4178 there is reason to believe further means of providing such 4179 services will be defined. 4181 14. Security of Data in Flight 4183 14.1. Data Security Provided by Services Associated with Auth Flavors 4185 The only auth flavor providing these facilities is RPCSEC_GSS. When 4186 this auth flavor is used, data security can be negotiated between 4187 client and server as described in Section 15. However, when data 4188 security is provided for the connection level, as described in 4189 Section 14.2, the negotiation of privacy and integrity support, 4190 provided by the auth flavor, is unnecessary, 4192 Other auth flavors, such as AUTH_SYS and AUTH_NONE have no such data 4193 security facilities. When these auth flavors are used, the only data 4194 security is provided on a per-connection basis. 4196 14.2. Data Security Provided for a Connection by RPC 4198 RPC, in many case, provide data security for all transactions 4199 performed on a connection, eliminating the need for that security to 4200 be provided or negotiated by the selection of particular auth 4201 flavors, mechanisms, or auth-flavor-associated services. 4203 15. Security Negotiation 4205 [Author Aside]: All unannotated paragraphs in this section are 4206 considered part of Consensus Item #32a. 4208 Because of the availability of security-related services associated 4209 with the transport layer, the security negotiation process needs to 4210 be enhanced so that the server can indicate the services needed, 4211 rather than, as previously, depending on the specification of 4212 acceptable auth flavors and services provided by RPCSEC_GSS. 4214 The situations listed below needed to be provided for. In each of 4215 them, there is a possibility that a new connection will be needed for 4216 new requests since the security issue might not be resolvable only by 4217 using a new auth flavor on an existing connection. The possible 4218 existence of multiple connections with different security 4219 characteristics makes it necessary that clients direct requests to 4220 the correct connection and that servers be aware of the security 4221 characteristics of te connection on which requests were received. 4222 This issue id discussed in Section 15.1. 4224 * When one or more of the auth flavors AUTH_NONE and and AUTH_SYS is 4225 accepted by a server, there is often a server policy requirement 4226 that it be used with encryption or peer authentication provided as 4227 a transport layer service. In such cases, the pseudo-flavors 4228 defined in [13] can be used to indicate that the corresponding 4229 auth flavor may be validly used, but only when the connection's 4230 characteristics meet the requirements of the pseudo-flavor. 4232 As a result, when NFS4ERR_WRONGSEC is received as a result of 4233 using one of these auth flavors, the client will, if it wishes to 4234 continue using one of these flavors, establish a new connection, 4235 with the appropriate security characteristics. 4237 * When the server's policy requirement is that encryption by used to 4238 access a region of the namespace, a secinfo entry will be returned 4239 identifying RPCSEC_GSS as an appropriate auth flavor to use while 4240 indicating that privacy/confidentiality is also needed. 4242 In that case, the client MAY obtain the necessary confidentiality 4243 either by sending requests requesting that confidentiality be 4244 provided by RPCSEC_GSS, or by making the requests on a connection 4245 for which confidentiality is provided at the transport layer. 4247 * When the server's policy requirement is that transport-level 4248 encryption be used, and a subsequent entry indicates that 4249 RPCSEC_GSS is an acceptable auth flavor, a section entry of type 4250 FL_GSS_CRYPT (described in Section 18.2) indicates that this auth 4251 flavor is only to be used on connections that provide this 4252 facility. 4254 Unlike the previous case, the client has no choice as to how 4255 confidentiality is to be provided as server has indicated, by 4256 using FL_GSS_CRYPT that transport-provide encryption required. 4257 Also, in this case, the information in the RPCSEC_GSS secinfo 4258 entry regarding regarding services to be provided by the auth 4259 flavor, is to be ignored. 4261 * When the server's policy requirement is that mutual peer 4262 authentication be provided and the secinfo entry indicates that 4263 RPCSEC_GSS is an acceptable auth flavor, a previous section entry 4264 of type FL_GSS_MPA (described in Section 18.2) indicates that this 4265 auth flavor is only to be used on connections that provide this 4266 facility. 4268 Unlike the previous case, the information in the RPCSEC_GSS 4269 secinfo entry regarding regarding services to be provided by the 4270 auth flavor, is to be consulted and might be relevant if the 4271 transport provides mutual peer authentication without encryption. 4273 15.1. Dealing with Multiple Connections 4275 [Author Aside]: All unannotated paragraphs in this section are 4276 considered part of Consensus Item #32b. 4278 Because effective security will require both an appropriate auth 4279 flavor (and possibly services provide by the auth flavor) together 4280 with appropriate connection characteristics, it is often necessary 4281 that clients and server be aware of connection characteristics: 4283 * When multiple connections with different security-related 4284 characteristics, are used to access a server, the clients needs to 4285 ensure that each request is issued on a an appropriate connection. 4287 * Similarly, in such situations, the server needs to be aware of the 4288 security-related characteristics for the connection pn which each 4289 request is received, in order to enforce its security policy. 4291 Depending on how the client and server implementations are 4292 structured, implementations may have to be changed to accomplish the 4293 above. 4295 In the case of NFSv4.1 and above, the protocol requires that requests 4296 associated with a given session only be issued on connections bound 4297 to that session and accepted by the server only when that binding is 4298 present. This makes it likely that clients or servers will be able 4299 to correctly associate requests with the appropriate connections 4300 although additional work might be necessary to enable them to 4301 determine, for any given connection, its security characteristics. 4303 In the case of NFSv4.0, no such binding is present in the protocol so 4304 that, depending on existing implementations' layering, channel 4305 binding functionality might have to be added. 4307 This subject is discussed, in the context of pseudo-flavors 4308 associated with the auth flavors AUTH_SYS and AUTH_NONE in Section 4 4309 of [13]. That treatment is equally applicable to the pseudo-flavor 4310 defined in this document. 4312 16. Future Security Needs 4314 [Author Aside]: All unannotated paragraphs in this section are to be 4315 considered part of Consensus Item #35a. 4317 [Author Aside]: This section is basically an outline for now, to be 4318 filled out later based on Working Group input, particularly from 4319 Chuck Lever who suggested this section and has ideas about many of 4320 the items in it. 4322 * Security for data-at-rest, most probably based on facilities 4323 defined within SAN. 4325 * Support for content signing. 4327 * Revision/extension of labelled NFS to provide true 4328 interoperability and server-based authorization. 4330 * Work to provide more security for RDMA-based transports. This 4331 would include the peer authentication infrastructure now being 4332 developed as part of RPC-over-RDMA version 2. In addition, there 4333 is a need for an RDMA-based transport that provides for 4334 encryption, which might be provided in number of ways. 4336 * Work, via extensions, to provide attributes describing server 4337 behavior to the client. This is likely to have an important role 4338 in resolving security issues connected with ACLs where there is 4339 both a new preferred approach together with legacy implementations 4340 built when the specifications wither offered no preferred approach 4341 or treated that preference as easily dispensed with. 4343 * [Consensus Needed (Item #56c)]: Potential support for an optional 4344 attribute to provide a UNIX ACL attribute as an NFSv4 extension. 4346 17. Security Considerations 4348 17.1. Changes in Security Considerations 4350 Beyond the needed inclusion of a threat analysis as Section 17.4 and 4351 the fact that all minor versions are dealt with together, the 4352 Security Considerations in this section differ substantially from 4353 those in RFCs 7530 [6] and 8881 [8]. These differences derive from a 4354 number of substantive changes in the approach to NFSv4 security 4355 presented in RFCs 7530 [6] and 8881 [8] and that appearing in this 4356 document. 4358 These changes were made in order to improve the security of the NFSv4 4359 protocols because it had been concluded that the previous treatment 4360 of these matters was in error, leading to a situation in which 4361 NFSv4's security goals were not met. As a result, this document 4362 supersedes the treatment of security in earlier documents, now viewed 4363 as incorrect. However, it will, for the benefit of those familiar 4364 with the previous treatment of these matters, draw attention to the 4365 important changes listed here. 4367 * There is a vastly expanded range of threats being considered as 4368 described in Section 17.1.1 4370 * New facilities provided by RPC on a per-connection basis can be 4371 used to deal with security issues, as described in Section 17.1.2. 4372 These include the use encryption on a per-connection basis, and 4373 the use of peer mutual authentication, to mitigate the security 4374 problems that come with the use of AUTH_SYS. 4376 * The handling of identities with superuser privileges is no longer 4377 part of NFSv4 semantics, even though many platforms on which NFSv4 4378 servers are implemented continue to depend, for local operation, 4379 on the existence of such identities. 4381 NFSv4 servers SHOULD NOT provide for such unrestricted access 4382 since doing so would provide a means by which an escalation-of- 4383 privilege on a client could be used to compromise a server to 4384 which it was connected, affecting all clients of that server. 4386 In connection with the use of "SHOULD NOT" above, and similar uses 4387 elsewhere, it is to be understood that valid reasons to do other 4388 than recommended are limited to the difficulty of promptly 4389 changing existing server implementations and the need to 4390 accommodate clients that have become dependent upon the existing 4391 handling. Further, those maintaining or using such 4392 implementations need to be aware of the security consequences of 4393 such use as well as the fact that clients who become aware of this 4394 characteristic may not be inclined to store their data on such a 4395 system. 4397 * The appropriate handling of ACL-based authorization and necessary 4398 interactions between ACLs and modes is now specified in this 4399 standards-track document rather it being assumed that the behavior 4400 of server implementations needs to be accepted and deferred to. 4402 17.1.1. Wider View of Threats 4404 Although the absence of a threat analysis in previous treatments 4405 makes comparison most difficult, the security-related features 4406 described in previous specifications and the associated discussion in 4407 their security considerations sections makes it clear that earlier 4408 specifications took a quite narrow view of threats to be protected 4409 against and placed the burden of providing for secure use on those 4410 deploying such systems with very limited guidance as to how such 4411 secure use could be provided. 4413 One aspect of that narrow view that merits special attention is the 4414 handling of AUTH_SYS, at that time in the clear, with no client peer 4415 authentication. 4417 With regard to specific threats, there is no mention in existing 4418 security considerations sections of: 4420 * Denial-of-service attacks. 4422 * Client-impersonation attacks. 4424 * Server-impersonation attacks. 4426 The handling of data security in-flight is even more troubling. 4428 * Although there was considerable work in the protocol to allow use 4429 of encryption to be negotiated when using RPCSEC_GSS. The 4430 existing security considerations do not mention the potential need 4431 for encryption at all. 4433 It is not clear why this was omitted but it is a pattern that 4434 cannot repeated in this document. 4436 * The case of negotiation of integrity services is similar and uses 4437 the same negotiation infrastructure. 4439 In this case, use of integrity is recommended but not to prevent 4440 the corruption of user data being read or written. 4442 The use of integrity services is recommended in connection with 4443 issuing SECINFO (and for NFSv4.1, SECINFO_NONAME). The presence 4444 of this recommendation in the associated security considerations 4445 sections has the unfortunate effect of suggesting that the 4446 protection of user data is of relatively low importance. 4448 17.1.2. Connection-oriented Security Facilities 4450 Such RPC facilities as RPC-with-TLS provide important ways of 4451 providing better security for all the NFSv4 minor versions. 4453 In particular: 4455 * The presence of encryption by default deals with security issues 4456 regarding data-in-flight, whether RPCSEC_GSS or AUTH_SYS is used 4457 for client principal identification. 4459 * Peer authentication provided by the server eliminates the 4460 possibility of a server-impersonation attack, even when AUTH_SYS 4461 or AUTH_NONE is used to issue requests 4463 * When mutual authentication is part of connection establishment, 4464 there is a possibility, where an appropriate trust relationship 4465 exists, of treating the uids and gids presented in AUTH_SYS 4466 requests, as effectively authenticated, based on the 4467 authentication of the client peer. 4469 17.1.3. Necessary Security Changes 4471 [Consensus Needed (Items #36a, #37a)]: For a variety of reasons, 4472 there are many cases in which a change to the security approach has 4473 been adopted but for which provisions have been made in order to give 4474 implementers time to adapt to the new approach. In such cases the 4475 words "SHOULD", "SHOULD NOT", and "RECOMMENDED" are used to introduce 4476 the new approach while use of the previous approach is allowed on a 4477 temporary basis, by limiting the valid reasons to bypass the 4478 recommendation. Such instances fall into two classes: 4480 * [Consensus Needed (Item #36a)]: In adapting to the availability of 4481 security services provided by RPC on a per-connection basis, 4482 allowance has been made for implementations for which these new 4483 facilities are not available and for which, based on previous 4484 standards-track guidance, AUTH_SYS was used, in the clear, without 4485 client-peer authentication. 4487 * [Consensus Needed (Item #37a)]: In dealing with server 4488 implementations that support both ACLs and the mode attribute, 4489 previous specifications have allowed a wide range of possible 4490 server behavior in coordinating these attributes. While this 4491 document now clearly defines the recommended behavior in dealing 4492 with these issues, allowance has been made to provide time for 4493 implementations to conform to the new recommendations. 4495 [Consensus Needed (Items #36a, #37a)]: The threat analysis within 4496 this Security Considerations section will not deal with older servers 4497 for which allowance has been made but will explore the consequences 4498 of the recommendations made in this document. 4500 17.1.4. Compatibility and Maturity Issues 4502 [Author Aside]: All unannotated paragraphs within this section are 4503 considered part of Consensus Item #38a. 4505 Given the need to drastically change the NFSv4 security approach from 4506 that specified previously, it is necessary for us to be mindful of: 4508 * The difficulty that might be faced in adapting to the newer 4509 guidance because the delays involved in designing, developing, and 4510 testing new connection-oriented security facilities such as RPC- 4511 with-TLS. 4513 * The difficulty in discarding or substantially modifying previous 4514 existing deployments and practices, developed on the basis of 4515 previous normative guidance. 4517 For these reasons, we will not use the term "MUST NOT" in some 4518 situations in which the use of that term might have been justified 4519 earlier. In such cases, previous guidance together with the passage 4520 of time may have created a situation in which the considerations 4521 mentioned above in this section may be valid reasons to defer, for a 4522 limited time, correction of the current situation making the term 4523 "SHOULD NOT" appropriate, since the difficulties cited would 4524 constitute a valid reason to not allow what had been recommended 4525 against. 4527 17.1.5. Discussion of AUTH_SYS 4529 [Author Aside]: All unannotated paragraphs within this section are 4530 considered part of Consensus Item #39a. 4532 An important change concerns the treatment of AUTH_SYS which is now 4533 divided into two distinct cases given the possible availability of 4534 connection-oriented support from RPC. 4536 When such support is not available, AUTH_SYS SHOULD NOT be used, 4537 since it makes the following attacks quite easy to execute: 4539 * The absence of authentication of the server to the client allow 4540 server impersonation in which an imposter server can obtain data 4541 to be written by the user and supply corrupted data to read 4542 requests. 4544 * The absence of authentication of the client user to the server 4545 allow client impersonation in which an imposter client can issue 4546 requests and have them executed as a user designated by imposter 4547 client, vitiating the server's authorization policy. 4549 With no authentication of the client peer, common approaches, such 4550 as using the source IP address can be easily defeated, allowing 4551 unauthenticated execution of requests made by the pseudo-clients 4553 * The absence of any support to protect data-in-flight when AUTH_SYS 4554 is used result in further serious security weaknesses. 4556 In connection with the use of the term "SHOULD NOT" above, it is 4557 understood that the "valid reasons" to use this form of access 4558 reflect the Compatibility and Maturity Issue discussed above in 4559 Section 17.1.4 and that it is expected that, over time, these will 4560 become less applicable. 4562 17.2. Security Considerations Scope 4564 17.2.1. Discussion of Potential Classification of Environments 4566 [Author Aside]: All unannotated paragraphs within this section are 4567 considered part of Consensus Item #40a. 4569 This document will not consider different security policies for 4570 different sorts of environments. This is because, 4572 * Doing so would add considerable complexity to this document. 4574 * The additional complexity would undercut our main goal here, which 4575 is to discuss secure use on the internet, which remain an 4576 important NFSv4 goal. 4578 * The ubiquity of internet access makes it hard to treat corporate 4579 networks separately from the internet per se. 4581 * While small networks might be sufficiently isolated to make it 4582 reasonable use NFSv4 without serious attention to security issues, 4583 the complexity of characterizing the necessary isolation makes it 4584 impractical to deal with such cases in this document. 4586 17.2.2. Discussion of Environments 4588 [Author Aside]: All unannotated paragraphs within this section are 4589 considered part of Consensus Item #40b. 4591 Although the security goal for Nfsv4 has been and remains "secure use 4592 on the internet", much use of NFSv4 occurs on more restricted IP 4593 corporate networks with NFS access from outside the owning 4594 organization prevented by firewalls. 4596 This security considerations section will not deal separately with 4597 such environments since the threats that need to be discussed are 4598 essentially the same, despite the assumption by many that the 4599 restricted network access would eliminate the possibility of attacks 4600 originating inside the network by attackers who have some legitimate 4601 NFSv4 access within it. 4603 In organizations of significant size, this sort of assumption of 4604 trusted access is usually not valid and this document will not deal 4605 with them explicitly. In any case, there is little point in doing 4606 so, since, if everyone can be trusted, there can be no attackers, 4607 rendering threat analysis superfluous. 4609 In corporate networks, as opposed to the Internet, there is good 4610 reason to be less concerned about denial-of-service attacks, since 4611 there is no tangible benefit to attackers inside the organization, 4612 and the anonymity that makes such attacks attractive to outside 4613 attackers will not be present. 4615 The above does not mean that NFSv4 use cannot, as a practical matter, 4616 be made secure through means outside the scope of this document 4617 including strict administrative controls on all software running 4618 within it, frequent polygraph tests, and threats of prosecution. 4619 However, this document is not prepared to discuss the details of such 4620 policies, their implementation, or legal issues associated with them 4621 and treats such matters as out-of-scope. 4623 Nfsv4 can be used in very restrictive IP network environments where 4624 outside access is quite restricted and there is sufficient trust to 4625 allow, for example, every node to have the same root password. The 4626 case of a simple network only accessible by a single user is similar. 4627 In such networks, many thing that this document says "SHOULD NOT" be 4628 done are unexceptionable but the responsibility for making that 4629 determination is one for those creating such networks to take on. 4630 This document will not deal further with NFSv4 use on such networks. 4632 17.2.3. Insecure Environments 4634 As noted in Section 17.2.2, NFSv4 is often used in environments of 4635 much smaller scope than the internet, with the assumption often being 4636 made, that the prevention of NFSv4 access from outside the 4637 organization makes the attention to security recommended by this 4638 document unnecessary, the possibility of insider attacks being 4639 explicitly or implicitly disregarded. 4641 As a result, there will be implementations that do not conform to 4642 these recommendations, many of which because the implementations were 4643 based on RFCs 3530 [6], 7530 [6], 5661 [16], or 8881 [8]. In 4644 addition to these cases in which the disregard of the recommendations 4645 is considered valid because implementors relied on existing normative 4646 guidance, there will be other cases in which implementors choose to 4647 ignore these recommendations, 4649 Despite the original focus of RFC2119 [1] on interoperability, many 4650 such implementations will interoperate, albeit without effective 4651 security, whether the reasons that the recommendations are not 4652 adhered to are considered valid or not. 4654 When such insecure use is mentioned in this Security Considerations 4655 section it will only be in explaining the need for the 4656 recommendations, by explaining the likely consequences of not 4657 following them. The threat analysis, in Section 17.4 and included 4658 subsections, will not consider such insecure use and will concern 4659 itself with situation in which these recommendations are followed. 4661 17.3. Major New Recommendations 4663 17.3.1. Recommendations Regarding Security of Data in Flight 4665 [Author Aside]: All unannotated paragraphs within this section are 4666 considered part of Consensus Item #41b. 4668 It is RECOMMENDED that requesters always issue requests with data 4669 security (i.e. with protection from disclosure or modification in 4670 flight) whether provided at the RPC request level or on a per- 4671 connection basis, irrespective of the responder's requirements. 4673 It is RECOMMENDED that implementers provide servers the ability to 4674 configure policies in which requests without data security will be 4675 rejected as having insufficient security. 4677 It is RECOMMENDED that servers use such policies over either their 4678 entire local namespace or for all file systems except those clearly 4679 designed for the general dissemination of non-sensitive data. 4681 When these recommendations are not followed, data, including data for 4682 which disclosure is a severe [problem is exposed to unwanted 4683 disclosure or modification in flight. Depending on the server to be 4684 aware of the need for confidentiality or integrity, as expected by 4685 previous specifications, has not proved workable, making encryption 4686 by default as provided uniformly by RPC (e.g. through RPC-with-TLS) 4687 necessary. 4689 17.3.2. Recommendations Regarding Client Peer Authentication 4691 [Author Aside]: All unannotated paragraphs within this section are 4692 considered part of Consensus Item #41c. 4694 It is RECOMMENDED that clients provide authentication material 4695 whenever a connection is established with a server capable of using 4696 it to provide client peer authentication. 4698 It is RECOMMENDED that implementers provide servers the ability to 4699 configure policies in which attempts to establish connections without 4700 client peer authentication will be rejected. 4702 It is RECOMMENDED that servers adopt such policies whenever requests 4703 not using RPCSEC_GSS (i.e. AUTH_NONE Or AUTH_SYS) are allowed to be 4704 executed. 4706 When these recommendations are not followed, it is possible for 4707 connections to be established between servers and client peers that 4708 have not been authenticated with the following consequences: 4710 * The server will be in the position of executing requests where the 4711 identity used in the authorization of operations is not 4712 authenticated, including cases in which the identification has 4713 been fabricated by an attacker. 4715 * When no identification of a specific user is needed or present 4716 (i.e AUTH_NO is used) there is no way of verifying that the 4717 request was issued by the appropriate client peer. 4719 When the recommendations are followed, use of AUTH_SYS can be valid 4720 means of user authentication, so long as due attention is paid to the 4721 discussion in Section 17.4.6.1. Despite this fact, the description 4722 of AUTH_SYS as an "OPTIONAL means of authentication"is no longer 4723 appropriate since choosing to use it requires heightened attention to 4724 security as discussed later in this document. 4726 17.3.3. Recommendations Regarding Superuser Semantics 4728 [Author Aside]: All unannotated paragraphs within this section are 4729 considered part of Consensus Item #52b. 4731 It is RECOMMENDED that servers adhere to the ACL semantics defined in 4732 this document and avoid granting to any remote user, however 4733 authenticated, unrestricted access capable of authorizing access 4734 where the file/directory ACL would deny it. 4736 Servers are free to conform to this recommendation either by 4737 implementing authorization semantics without provisions for 4738 superusers or by mapping authenticated users that would have 4739 superuser privileges to users with with more limited privileges (e.g. 4740 "nobody"). 4742 It needs to b e understood that the second of these choices is 4743 preferable when there are NFsv4-accessible files owned by a special 4744 users (e.g. root) whose compromise might be taken advantage of by 4745 attackers to enable permanent unauthorized access to a server. 4747 17.3.4. Issues Regarding Valid Reasons to Bypass Recommendations 4749 [Author Aside]: All unannotated paragraphs within this section are 4750 considered part of Consensus Item #41d. 4752 Clearly, the maturity and compatibility issues mentioned in 4753 Section 17.1.4 are valid reasons to bypass the proposed 4754 recommendations requiring pervasive use of encryption, as long as 4755 these issues continue to exist. 4757 [Author Aside]: The question the working group needs to address is 4758 whether other valid reasons exist. 4760 [Author Aside]: In particular, some members of the group might feel 4761 that the performance cost of conection-based encryption constitutes, 4762 in itself, a valid reason to ignore the above recommendations. 4764 [Author Aside]: I cannot agree and feel that accepting that as a 4765 valid reason would undercut Nfsv4 security improvement, and probably 4766 would not be acceptable to the security directorate. However, I do 4767 want to work out an a generally acceptable compromise. I propose 4768 something along the following lines: 4770 In dealing with recommendations requiring pervasive use of 4771 connection-based encryption, it needs to be understood that the 4772 connection-based encryption facilities are designed to be compatible 4773 with facilities to offload the work of encryption and decryption. 4774 When such facilities are not available, at a reasonable cost, to 4775 NFSv4 servers and clients anticipating heavy use of NFSv4, then the 4776 lack of such facilities can be considered a valid reason to bypass 4777 the above recommendations, as long as that situation continues. 4779 17.4. Threat Analysis 4781 17.4.1. Threat Analysis Scope 4783 Because of the changes that have been made in NFSv4 security, it 4784 needs to be made clear that the primary goal of this threat analysis 4785 is to explore the threats that would be faced by implementations that 4786 follow the recommendations in this document. 4788 When the possibility is raised of implementations that do not conform 4789 to these recommendations, the intention is to explain why these 4790 recommendations were made rather that to expand the the scope of the 4791 threat analysis to include implementations that bypass/ignore the 4792 recommendations. 4794 The typical audience for threat analyses is client and server 4795 implementers, to enable implementations to be developed that are 4796 resistant to possible threats. While much of the material in 4797 Section 17.4 is of that form, it also contains material that relates 4798 to threats whose success depends primarily on the ways in which the 4799 implementation is deployed, such as the threats discussed in Sections 4800 17.4.2, 17.4.4 and 17.4.3. While it is not anticipated that those 4801 deploying implementations will be aware of the detail of this threat 4802 analysis, it is expected that implementors could use this material to 4803 properly set expectations and provide guidance helpful to making 4804 deployments secure. 4806 17.4.2. Threats based on Credential Compromise 4808 In the past, it had been assumed that a user-selected password could 4809 serve as a credential, the knowledge of which was adequate to 4810 authenticate users and provide a basis for authorization. 4812 That assumption is no longer valid for a number of reasons: 4814 * The inability or unwillingness of users to remember multiple 4815 passwords has meant that the single password they will remember 4816 controls access to large set of resources, increasing the value of 4817 this knowledge to attackers and the effort that will be expended 4818 to obtain it. 4820 In addition, the common use of a single password for applying to 4821 all of a user's data has resulted in a situation in which the 4822 client is aware of user passwords (since they are used for client 4823 login) that apply to data on many servers. As will be seen later, 4824 this has the effect of changing the considerations appropriate to 4825 comparing the security of AUTH_SYS and RPCSEC_GSS. 4827 * CPU developments have made exhaustive search possible for larger 4828 classes of passwords. 4830 * The success of "phishing" attacks taking advantage of user 4831 gullibility provides an additional path to credential compromise 4832 which need to be addressed in the near-term by those deploying 4833 NFSv4, and will eventually need work in the security 4834 infrastructure on which NFSv4 is built. 4836 In the near term, there are a number of steps, listed below that 4837 those deploying NFSv4 servers can take to mitigate these weaknesses. 4838 These steps are outside the scope of the NFSv4 protocols and 4839 implementors only role with regard to them is to make it clear that 4840 these weaknesses exist and generally require mitigation. 4842 * Limitations on password choice to eliminate weak passwords. 4844 * Requirements to change passwords periodically. 4846 * User education about "phishing" attacks including ways to report 4847 them and effective ways of replacing a compromised password. 4849 From a longer-term perspective, it appears that password-based 4850 credentials need to be either replaced or supplemented by some form 4851 of multi-factor authentication. Since NFSv4's approach to security 4852 relies on RPC, that work would most probably be done within the RPC 4853 layer, limiting the work that implementations and the NFSv4 protocols 4854 would have to do to adapt to these changes once they are available. 4855 While the precise form of these changes is not predictable, the 4856 following points need to be kept in mind. 4858 * [Verification Needed (Item #53a)]: For those using RPCSEC_GSS 4859 authentication of principals, it appears that RPCSEC_GSS interface 4860 is flexible enough that the addition of a second credential 4861 element, in the form of a one-time code could be added. 4863 [Elaboration/Verification Needed (Item #53a)]: Enhancement of 4864 Kerberos is one possibility to provide multi-factor 4865 authentication. However, work on this is not far enough along to 4866 enable deployment to be discussed now. 4868 If this approach were taken, rogue servers would still have access 4869 to user passwords but their value would be reduced since the 4870 second credential element would have a very limited lifetime. 4872 * For those using AUTH_SYS to identify principals, the client 4873 operating system's authentication of user at login would need to 4874 be enhanced to use multi-factor authentication. 4876 If this were done, the client would retain responsibility for 4877 credential verification with the server needing to trust the 4878 client, as discussed in Section 17.4.6.1. 4880 Although there is need for protocol standardization to enable this 4881 approach to be commonly used, it is not likely to be widely used 4882 until some operating system adopts it for user login. 4884 * One important variant of AUTH_SYS use concerns clients used by a 4885 single user, when, as recommended, client-peer authentication is 4886 in effect For such clients, it is possible for the authentication 4887 of that specific client peer to effectively become the second 4888 factor, in a multi-factor authentication scheme. 4890 Despite the fact that the the RPC-with-TLS specification [12]) 4891 does not allow TLS to used for user authentication, this 4892 arrangement in which the user identity is inferred from the peer 4893 authentication, could be used to negate the effects of credential 4894 compromise since an attacker would need both the user password, 4895 and the physical client to gain access. 4897 17.4.3. Threats Based on Rouge Clients 4899 When client peers are not authenticated, it is possible to a node on 4900 the network to pretend to be a client. In the past, in which servers 4901 only checked the from-IP address for correctness, address spoofing 4902 would allow unauthenticated request to be executed, allowing 4903 confidential data to be read or modified. 4905 Now that such use of AUTH_SYS is recommended against, this cannot 4906 happen. The recommended practice is to always authenticate client 4907 peers making this sort of imposture easily detectable by the server. 4909 Despite this protection, it is possible that an attacker, through a 4910 client vulnerability unrelated to NFSv4, or the installation of 4911 malware, could effectively control the client peer and act as 4912 imposter client would, effectively undercutting the authentication of 4913 the client. This possibility makes it necessary, as discussed in 4914 Section 17.4.6.1 that those deploying NFSv4 clients using AUTH_SYS 4915 takes steps to limit the set of user identifications accepted by a 4916 server and to limit the ability of rogue code running on the server 4917 to present itself as a client entitled to use AUTH_SYS. 4919 17.4.4. Threats Based on Rouge Servers 4921 When server peers are not authenticated, it is possible for a node on 4922 the network to act as if it were an NFSv4 server, with the ability to 4923 save data sent to it and use it or pass it to other, rather than 4924 saving it in the file system, as it needs to do.. 4926 When current recommendations are adhered to, this is be prevented as 4927 follows: 4929 * When RPCSEC_GSS is used, the mutual authentication of the server 4930 and client principal provides assurance the server is not an 4931 imposter. 4933 * When AUTH_SYS or AUTH_NONE is used, the mutual authentication of 4934 client and server peers provides assurance the server is not an 4935 imposter. 4937 Despite this protection, it is possible that an attacker, through a 4938 operating system vulnerability unrelated to NFSv4, or the 4939 installation of malware, could effectively control the server peer 4940 and act as an imposter server would, effectively undercutting the 4941 authentication of the server. 4943 The above possibility makes it necessary, that those deploying NFSv4 4944 servers take the following steps, particularly in cases in cases in 4945 which the server has access to user credentials, including, but not 4946 limited to, cases in which AUTH_SYS is supported 4948 When an NFSv4 is implemented as part of a general-purpose operating 4949 system, as it often is, steps need to be taken to limit the ability 4950 of attackers to take advantage of operating system vulnerabilities 4951 that might allow the attacker to obtain privileged access and subvert 4952 the servers operation, turning it, effectively, into a rogue server. 4954 Such steps include controls on the software installed on the machine 4955 acting as the server, and limitation of the network access to 4956 potentially dangerous sites. 4958 17.4.5. Data Security Threats 4960 When file data is transferred in the clear, it is exposed to unwanted 4961 exposure. As a result, this document recommends that encryption 4962 always be used to transfer NFSv4 requests and responses. 4964 That encryption, whether done on encrypted connections, or on a per- 4965 request basis, using RPCSEC_GSS security services, provides the 4966 necessary confidentiality. In addition, it contributes to security 4967 in other ways as well: 4969 * The ability of an attacker to plan and execute attacks is enhanced 4970 by the monitoring of client-server traffic, even if none of the 4971 data intercepted is actually confidentiality. 4973 An attacker can deduce which users are allowed to read or write a 4974 specific file by examining the results of OPEN and ACCESS 4975 operations allowing later attacks to impersonate users with the 4976 appropriate access. 4978 * All the methods on encryption used with NFS4 provide a checksum, 4979 to enable the detection of unwanted modifications to data being 4980 read or written. 4982 17.4.6. Authentication-based threats 4984 17.4.6.1. Attacks based on the use of AUTH_SYS 4986 Servers, when they allow access using AUTH_SYS, to a specific client 4987 machines using AUTH_SYS are responsible for ensuring that the 4988 principal identifications presented to the server can be relied upon. 4990 The existence of client-peer authentication as recommended in 4991 Section 17.1.5 means that imposter servers can be detected and not 4992 allowed to use AUTH_SYS. However there are an additional number of 4993 issues that need to be addressed to adequately protect against use of 4994 AUTH_SYS enabling attacks: 4996 * The server accepting requests using AUTH_SYS needs to determine 4997 that the authenticated client-peer can be trusted to properly 4998 authenticate the principals that it identifies in requests. 5000 The specific standards for trustworthiness are up to the server 5001 but they need to take account of the controls in place to prevent 5002 malware from pretending to be a client and thus taking advantage 5003 of the fact that the request is from the expected client machine. 5005 This server MUST NOT accept AUTH_SYS requests from unknown clients 5006 or from unauthenticated clients. 5008 * [Elaboration Needed (Item #54a)]: The client verification 5009 procedure needs to take steps to prevent code on a compromised 5010 client to presenting itself as the successor to a legitimate 5011 client, taking advantage of the fact that the machine is the same. 5013 * Given the inherent vulnerabilities of client operating systems, it 5014 is desirable, to limit the set of users whose identification will 5015 be accepted. The elimination of particular users such as "root' 5016 is one long-standing approach to the issue but it probably isn't 5017 sufficient in most environments. More helpful would be the 5018 ability to exclude multiple sensitive users or group of users or 5019 to limit the user identifications accepted to a user group or a 5020 single user. 5022 Another important that issue that arises when AUTH_SYS is used 5023 concerns the storage of credentials on the clients. While it is 5024 theoretically possible for these not to be of use elsewhere, the 5025 reluctance/inability of users to remember multiple passwords means 5026 that these credentials will be used by many clients and will need to 5027 be updated as users are added or deleted or when passwords are 5028 changed. The propagation of these credentials and their storage on 5029 clients could be the basis for attacks if appropriate step are not 5030 taken to secure this data. 5032 While it is helpful to store a cryptographic hash of the password 5033 rather than the password itself, this does not dispose of the issue, 5034 since possession of the hash would greatly simplify an exhaustive 5035 search for the password, since the attacker could limit login 5036 attempts to guessed password whose hash value matched the value 5037 obtained from the files on the client. 5039 Although it is true that making clients responsible for 5040 authentication of user identities undercuts much of the original 5041 motivation for making RPCSEC_GSS MANDATORY to implement, it needs to 5042 be understood that the situation today is different from that when 5043 this decision was made. 5045 * It has been recommended that servers not allow unauthenticated 5046 clients to issue requests using AUTH_SYS. 5048 * The identification of a request as issued by the user with uid 5049 zero, no longer provides access without file access authorization. 5051 * Given that users are unaware of where their files are located and 5052 it is desirable that they are able to remain unaware of this, it 5053 is natural that they use the same password to authenticate 5054 themselves for local resource use as for use of files located on 5055 NFSv4 servers. 5057 Support for AUTH_SYS in NFSv4 was included for a number of reasons 5058 which still hold true today, despite the fact that the original 5059 mistake, to make no reference to the security consequences of doing 5060 so, is now being corrected. Such provision is necessary for the 5061 following reasons, that go beyond the need to temporarily accommodate 5062 implementations following the older specifications, for a number of 5063 reasons: 5065 * When considered, as NFS was to intended to be, as consistent with 5066 local access as possible, AUTH_SYS was the natural way of 5067 providing authentication, just as it had been done for local 5068 files. 5070 While use of AUTH_SYS exposes user passwords to the client 5071 operating system, the fact that user are unable or unwilling to 5072 use different passwords for different files in a multi-server 5073 namespace means this issue will be present even when AUTH_SYS is 5074 not used. 5076 * [Elaboration Needed (Item #55a)]: In many important environments 5077 including cloud environments, important implementation constraints 5078 has made use of Kerberos impractical. 5080 [Verification Needed (Item #55a)]: In such environments, client 5081 credentials are maintained by the cloud customer while the cloud 5082 provider manages network access. 5084 17.4.6.2. Attacks on Name/Userid Mapping Facilities 5086 NFSv4 provides for the identification users and groups in two ways 5087 (i.e. by means of strings of the form name@domain or strings 5088 containing numeric uid/gid values) while file systems used on NFSv4 5089 servers typically use 32-bit uids and gids. 5091 As a result, NFSv4 server implementations are required to have some 5092 means of translating between the name@domain form and the numeric 5093 form used internally. While the specifics of this translation are 5094 not specified as part of the NFSv4 protocols, is required for server 5095 implementations to work, and, if it not done securely and attackers 5096 have the ability to interfere with this translation, it gives them 5097 the ability to interfere with authorization as follows: 5099 * When authentication occurs using user names, as occurs when 5100 RPCSEC_GSS, a mistranslation might allow the numeric value used in 5101 authorization to allow access to a file the authenticated user 5102 would not be allowed to access. 5104 * When any authentication occurs on the client and the uid is 5105 presented to the server using AUTH_SYS a mistranslation to the 5106 string form could result in confusion and uncertainty about the 5107 users allowed to access the file. 5109 17.4.7. Disruption and Denial-of-Service Attacks 5111 17.4.7.1. Attacks Based on the Disruption of Client-Server Shared State 5113 When data is known to both the client and server, a rogue client can 5114 interfere with the correct interaction between client and server, by 5115 modifying that shared data, including locking state and session 5116 information. 5118 For this reason, it is recommended that client-peer authentication be 5119 in effect, because, it it were not, a different client could could 5120 easily modify data that the current client depend on, disrupting ones 5121 interaction with the server. 5123 It is still possible, if one's client is somehow compromised, as 5124 described in Section 17.4.3, for various forms of mischief to occur: 5126 * Locks required for effective mutual exclusion can be released, 5127 causing application failures. 5129 * Mandatory share locks can be obtained preventing those with valid 5130 access from opening file that they are supposed to have access to. 5132 * Session slot sequence numbers may be rendered invalid if requests 5133 are issued on existing sessions. As a result, the client that 5134 issued a request would receive unexpected sequence errors. 5136 17.4.7.2. Attacks Based on Forcing the Misuse of Server Resources 5138 It is is also possible for attacks to be mounted, in the absence of 5139 the ability to obtain or modify confidential data, with the sole goal 5140 of the attack being to make spurious requests, with no expectation 5141 that the request will be authorized but with the goal of causing 5142 resources that would otherwise be used to service valid requests to 5143 be unavailable due to the burden of dealing with numerous invalid 5144 requests. 5146 The design of the NFSv4 protocols requires that clients establishing 5147 new connections make initial requests which establishes a shared 5148 context referred to by subsequent requests which might request 5149 substantive actions (e.g. client and session ids). This structure 5150 helps mitigate the effect of such denial-of-service attacks as 5151 described below. 5153 * The server can limit the resources devoted to connections not yet 5154 fully identified without unduly restricted connections which have 5155 identified themselves. 5157 * The recommendation that client peers authenticate themselves, 5158 allows unknown clients to be dispensed with at an early stage 5159 negating their ability to make requests which could require file 5160 system action to obtain information needed to make authorization 5161 decisions (e.g. ACLs or other authorization-related) file 5162 attributes. 5164 18. IANA Considerations 5166 [Author Aside]: All unannotated paragraphs in this section are to be 5167 considered part of Consensus Item #32c. 5169 Because of the shift from implementing security-related services only 5170 in connection with RPCSEC_GSS to one in which connection-oriented 5171 security has a prominent role, a number if new values need to be 5172 assigned. 5174 These include new authstat values to guide selection of a connection 5175 types acceptable to both client and server, presented in Section 18.1 5176 and new pseudo-flavors to be used in the process of security 5177 negotiation, presented in Section 18.2. 5179 18.1. New Authstat Values 5181 [Author Aside]: All unannotated paragraphs in this section are to be 5182 considered part of Consensus Item #32d. 5184 The following new authstat values are necessary to enable a server to 5185 indicate that the server's policy does not allows requests to be made 5186 on the current connection because of security issues associated with 5187 connection type used. In the event they are received, the client 5188 needs to establish a new connection. 5190 * The value XP_CRYPT indicates that the server will not support 5191 access using unencrypted connections while the current connection 5192 is not encrypted. 5194 * The value XP_CPAUTH indicates that the server will not support 5195 access using connections for which the client peer has not 5196 authenticated itself as part of connection while the current 5197 connection has not been set up in that way. 5199 18.2. New Authentication Pseudo-Flavors 5201 [Author Aside]: All unannotated paragraphs in this section are to be 5202 considered part of Consensus Item #32e. 5204 The new pseudo-flavors described in this section are to be made 5205 available to allow their return as part of the response to the 5206 SECINFO and SECINFO_NONAME operations. How these operations are to 5207 used to negotiate the use of appropriate auth flavors and associated 5208 security-relevant connection characteristics is discussed in 5209 Section 15. 5211 The following pseodo-flavors are to be defined: 5213 * FL_GSS_CRYPT is returned to indicate that subsequent secinfo 5214 entries indicating the auth flavor RPCSEC_GSS are to considered 5215 limited to use on connections for which transort-level encryption 5216 is provided. 5218 When this pseudo-flavor is used, the client constraints are 5219 different than they would be if the RPCSEC_GSS secinfo entry 5220 indicated the need for privacy/confidentiality. That case would 5221 allow the encryption to be provided by either the auth-flavor or 5222 the by the transport layer. When FL_GSS_CRYPT os present, only 5223 the latter is allowed. 5225 * FL_GSS_MPA is returned to indicate that subsequent secinfo entries 5226 indicating the auth flavor RPCSEC_GSS are to be consdered limited 5227 to use on connections on which mutual peer authentication has been 5228 provided at connection setup. 5230 These pseudo-flavors provide the same sort of facilities for 5231 RPCSEC_GSS as provided by [13] for AUTH_SYS and AUTH_NONE. They 5232 differ in being modifiers of existing auth flavor entries rather than 5233 combining auth flavor and connection characteristics in a single 5234 entry. This is necessary because existing XDR only allows an 5235 RPCSEC_GSS secinfo entry to present information in additional to the 5236 flavor id. 5238 19. References 5240 19.1. Normative References 5242 [1] Bradner, S., "Key words for use in RFCs to Indicate 5243 Requirement Levels", BCP 14, RFC 2119, 5244 DOI 10.17487/RFC2119, March 1997, 5245 . 5247 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 5248 Specification", RFC 2203, DOI 10.17487/RFC2203, September 5249 1997, . 5251 [3] Linn, J., "Generic Security Service Application Program 5252 Interface Version 2, Update 1", RFC 2743, 5253 DOI 10.17487/RFC2743, January 2000, 5254 . 5256 [4] Thurlow, R., "RPC: Remote Procedure Call Protocol 5257 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 5258 May 2009, . 5260 [5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5262 May 2017, . 5264 [6] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 5265 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 5266 March 2015, . 5268 [7] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 5269 (NFS) Version 4 External Data Representation Standard 5270 (XDR) Description", RFC 7531, DOI 10.17487/RFC7531, March 5271 2015, . 5273 [8] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 5274 Version 4 Minor Version 1 Protocol", RFC 8881, 5275 DOI 10.17487/RFC8881, August 2020, 5276 . 5278 [9] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 5279 "Network File System (NFS) Version 4 Minor Version 1 5280 External Data Representation Standard (XDR) Description", 5281 RFC 5662, DOI 10.17487/RFC5662, January 2010, 5282 . 5284 [10] Haynes, T., "Network File System (NFS) Version 4 Minor 5285 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 5286 November 2016, . 5288 [11] Haynes, T., "Network File System (NFS) Version 4 Minor 5289 Version 2 External Data Representation Standard (XDR) 5290 Description", RFC 7863, DOI 10.17487/RFC7863, November 5291 2016, . 5293 [12] Myklebust, T. and C. Lever, "Towards Remote Procedure Call 5294 Encryption By Default", Work in Progress, Internet-Draft, 5295 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 5296 . 5299 [13] Lever, C., "Pseudo-flavors for Remote Procedure Calls with 5300 Transport Layer Security", Work in Progress, Internet- 5301 Draft, draft-cel-nfsv4-rpc-tls-pseudoflavors-01, 15 5302 December 2021, . 5305 [14] NIST, "SP 800-209 Security Guidelines for Storage 5306 Infrastructure". 5308 19.2. Informative References 5310 [15] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 5311 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 5312 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 5313 October 2017, . 5315 [16] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 5316 "Network File System (NFS) Version 4 Minor Version 1 5317 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 5318 . 5320 Appendix A. Changes Made 5322 This section summarizes the substantive changes between the treatment 5323 of security in previous minor version specification documents (i.e. 5324 RFCs 7530 and 8881) and the new treatment applying to NFSv4 as a 5325 whole. 5327 This is expected to be helpful to implementers familiar with previous 5328 specifications but also has an important role in verifying the 5329 working group consensus for these changes and in guiding the search 5330 for potential compatibility issues. 5332 A.1. Motivating Changes 5334 A number of changes reflect the basic motivation for a new treatment 5335 of NFSv4 security. These include the ability to obtain privacy and 5336 integrity services from RPC on a per-connection basis rather than as 5337 a service ancillary to a specific authentication flavor. 5339 This motivated a major reorganization of the treatment of security 5340 together with a needed emphasis on the security of data in flight. 5341 In addition, the security negotiation framework for NFSv4 has been 5342 significantly enhanced to support the combined negotiation of 5343 authentication-related services and connection characteristics. 5345 Despite these major changes there are not expected to be 5346 compatibility issues between peers supporting provision of security 5347 services on a per-connection basis and those without such support. 5349 Another such change was in the treatment of AUTH_SYS, previously 5350 described, inaccurately, as an "OPTIONAL means of authentication" 5351 with the unfortunate use of the RFC2119 keyword obscuring the 5352 negative consequences of the typical use of AUTH_SYS (in the clear; 5353 without client-peer authentication) for security by enabling the 5354 execution of unauthenticated requests. 5356 The new treatment avoids the inappropriate use of term 5357 "authentication" for all activities triggered by the use of RPC 5358 authentication flavors and clearly distinguishes those flavors 5359 providing authentication from those providing identification only or 5360 neither identification nor authentication. 5362 A.2. Other Major Changes 5364 The need to make the major changes discussed in Appendix A.1 has 5365 meant that much text dealing with security has needed to be 5366 significantly revised or rewritten. As a result of the process, may 5367 issues involving unclear, inconsistent, or otherwise inappropriate 5368 text were uncovered and needed to be dealt with. 5370 While the author believes such changes are necessary, the fact that 5371 we are changing a document adopted by consensus requires the working 5372 group to be clear about the acceptability of the changes. This 5373 applies to both the troublesome issues discussed in Section 3.4 and 5374 to the other changes included below. 5376 Because of concurrent re-organizations, the ordering of the list 5377 follows the text of the current version which may differ considerably 5378 from that in earlier versions of the I-D. 5380 * In order to deal better with the fact that ACLs have multiple uses 5381 some significant structural changes have been made. 5383 Section 5, a new top-level section describes the the structure of 5384 ACLs, 5386 * In Section 7.2, makes clear that owner and owner group are 5387 essentially REQUIRED attributes. 5389 * Also in Section 7.2, there is added clarity in the discussion of 5390 support for multiple authorization approaches by eliminating use 5391 of the subjective term "reasonable semantics". 5393 In connection with this clarification, we have switched from 5394 describing the needed co-ordination between modes and acls as 5395 "goals" to describing them as "requirements" to give clients some 5396 basis for expecting interoperability in handling these issues. 5398 As a result of this shift to a prescriptive framework applying to 5399 all minor versions it becomes possible to treat all minor versions 5400 together. In earlier versions of this document, it had been 5401 assumed that NFSv4.0 was free to ignore the relevant prescriptions 5402 first put forth in RFC 5661 and only needed to address the "goals" 5403 for this co-ordination. 5405 Appendix B. Issues for which Consensus Needs to be Ascertained 5407 The section helps to keep track of specific changes which the author 5408 has made or intends to make to deal with issues found in RFCs 7530 5409 and 7881. The changes listed here exclude those which are clearly 5410 editorial but includes some that the author believes are editorial 5411 but for which the issues are sufficiently complicated that working 5412 group consensus on the issue is probably necessary. 5414 These changes are presented in the table below, organized into a set 5415 of "Consensus Items" identified by the numeric code appearing in 5416 annotations in the proposed document text. For each such item, a 5417 type code is assigned with separate sets of code define for pending 5418 items and for those which are no longer pending. 5420 The following codes are defined for pending consensus items: 5422 * "NM" denotes a change which is new material that is not purely 5423 editorial and thus requires Working Group consensus for eventual 5424 publication. 5426 * "BE" denotes a change which the author believes is editorial but 5427 for which the change is sufficiently complex that the judgment is 5428 best confirmed by the Working Group. 5430 * "BC" denotes a change which is a substantive change that the 5431 author believes is correct. This does not exclude the possibility 5432 of compatibility issues becoming an issue but is used to indicate 5433 that the author believes any such issues are unlikely to prevent 5434 its eventual acceptance. 5436 * "CI" denotes a change for which the potential for compatibility 5437 issues is major concern with the expected result that working 5438 group discussion of change will focus on clarifying our knowledge 5439 of how existing clients and server deal with the issue and how 5440 they might be affected by the change or the change modified to 5441 accommodate them. 5443 * "NS" denotes a change which represents the author's best effort to 5444 resolve a difficulty but for which the author is not yet confident 5445 that it will be adopted in its present form, principally because 5446 of the possibility of troublesome compatibility issues. 5448 * "NE" denotes change based on an existing issue in the spec but for 5449 which the replacement text is incomplete and needs further 5450 elaboration. 5452 * "WI" denotes a potential change based on an existing issue in the 5453 spec but for which replacement text is not yet available because 5454 further working group input is necessary before drafting. It is 5455 expected that replacement text will be available in a later draft 5456 once that discussion is done. 5458 * "LD" denotes a potential change based on an existing issue in the 5459 spec but for which replacement text is not yet available due to 5460 the press of time. It is expected that replacement text will be 5461 available in a later draft. 5463 * "EV" denote a potential change which is tentative or incomplete 5464 because further details need to be provide or because the author 5465 is unsure that he has a correct explanation of the issue. It is 5466 expected that replacement text will be available in a later draft. 5468 The following codes are defined for consensus items which are no 5469 longer pending. 5471 * "RT" designates a former item which has been retired, because it 5472 has been merged with another one or otherwise organized out of 5473 existence. 5475 Such items no longer are referred to the document source although 5476 the item id is never reassigned. They are no longer counted among 5477 the set of total items. 5479 * "CA" designates a former item for which consensus has been 5480 achieved in the judgment of the author, although not by any 5481 official process. 5483 Items reaching this state are effected in the document source 5484 including the deletion of annotations and the elimination of 5485 obsoleted previous treatments. 5487 Items in this state are still counted among the total of item but 5488 are no longer considered pending 5490 * "CV" designates a former item for which consensus has been 5491 achieved and officially verified. 5493 Because the author is a working group co-chair,it is probably best 5494 if he is not involved in this process and intends to leave it to 5495 the other co-chair and the Area Director. 5497 Items in this state are not counted among the item totals. They 5498 may be kept in the table but only to indicate that the item id is 5499 still reserved. 5501 * "DR" designates a former item which has been dropped, because it 5502 appears that working group acceptance of it, even with some 5503 modification, is unlikely. 5505 Such items no longer are referred to the document source although 5506 the item id is never reassigned. They are no longer counted among 5507 the set of total items. 5509 When asterisk is appended to a state of "NM", "BE" or "BE" it that 5510 there has been adequate working group discussion leading one to 5511 reasonably expect it will be adopted, without major change, in a 5512 subsequent document revision. 5514 Such general acceptance is not equivalent to a formal working group 5515 consensus and it not expected to result in major changes to the draft 5516 document, 5517 On the other hand, once there is a working group consensus with 5518 regard to a particular issue, the document will be modified to remove 5519 associated annotations, with the previously conditional text 5520 appearing just as other document text does. The issue will remain in 5521 this table as a non-pendin item. It will be mentioned in Appendices 5522 A.2 or A.1 to summarize the changes that have been made. 5524 It is is expected that these designations will change as discussion 5525 proceeds and new document versions are published. It is hoped that 5526 most such shifts will be upward in the above list or result in the 5527 deletion of a pending item, by reaching a consensus to accept or 5528 reject it. This would enable, once all items are dealt with, an 5529 eventual request for publication as an RFC, with this appendix having 5530 been deleted. 5532 +====+======+==================+===================================+ 5533 | # | Type | ...References... | Substance | 5534 +====+======+==================+===================================+ 5535 | 1 | NM* | #1a in S 4 | Outline of new approach to | 5536 | | | | authetication/identification, | 5537 | | | | replacing confusion about the | 5538 | | | | matter in previous | 5539 | | | | specifications. | 5540 +----+------+------------------+-----------------------------------+ 5541 | 2 | NM* | #2a in S 4 | Introduction to and outline of | 5542 | | | | changes needed in negotiation | 5543 | | | | framework to support provision of | 5544 | | | | security by RPC on a per- | 5545 | | | | connection basis. | 5546 +----+------+------------------+-----------------------------------+ 5547 | 3 | BE | #3a in S 5.4 | Conversion of mask bit | 5548 | | | | descriptions from being about | 5549 | | | | "permissions" to being about the | 5550 | | | | action permitted, denied, or | 5551 | | | | specified as being audited or | 5552 | | | | generating alarms. | 5553 +----+------+------------------+-----------------------------------+ 5554 | 4 | CI | #4a in S 5.4 | Elimination of uses of SHOULD | 5555 | | | | believed inappropriate in | 5556 | | | | Section 5.4. | 5557 +----+------+------------------+-----------------------------------+ 5558 | 5 | BE | #5a in S 5.4 | Explicit inclusion of ACCESS as | 5559 | | | | an operation affected in the mask | 5560 | | | | bit definitions. | 5561 +----+------+------------------+-----------------------------------+ 5562 | 6 | CI | #6a in S 5.4 | New/revised description of the | 5563 | | | | role of the "sticky bit" for | 5564 | | | #6b in S 5.6 | directories, both with respect to | 5565 | | | | ACL handling and mode handling. | 5566 | | | #6c in S 7.3.1 | | 5567 +----+------+------------------+-----------------------------------+ 5568 | 7 | BE | #7a in S 5.4 | Clarification of relationship | 5569 | | | | between READ_DATA and EXECUTE. | 5570 +----+------+------------------+-----------------------------------+ 5571 | 8 | CI | #8a in S 5.4 | Revised discussion of | 5572 | | | | relationship between WRITE_DATA | 5573 | | | | and APPEND_DATA. | 5574 +----+------+------------------+-----------------------------------+ 5575 | 9 | BC | #9a in S 5.4 | Clarification of how | 5576 | | | | ADD_DIRECTORY relates to RENAME. | 5577 +----+------+------------------+-----------------------------------+ 5578 | 10 | BC | #10a in S 5.4 | Revisions in handling of the | 5579 | | | | masks WRITE_RETENTION and | 5580 | | | #10b in S 5.5 | WRITE_RETENTION_HOLD. | 5581 +----+------+------------------+-----------------------------------+ 5582 | 11 | CI | #11a in S 5.4 | Explicit recommendation and | 5583 | | | | requirements for mask | 5584 | | | #11b in S 5.5 | granularity, replacing the | 5585 | | | | previous treatment which gave the | 5586 | | | #11c in S 5.11 | server license to ignore most of | 5587 | | | | the previous section, placing | 5588 | | | | clients in an unfortunate | 5589 | | | | situation. | 5590 +----+------+------------------+-----------------------------------+ 5591 | 12 | BC | #12a in S 5.6 | Revised treatment of directory | 5592 | | | | entry deletion. | 5593 | | | #12b in S 5.6.1 | | 5594 +----+------+------------------+-----------------------------------+ 5595 | 13 | BC | #13a in 5.7 | Attempt to put some reasonable | 5596 | | | | limits on possible non-support | 5597 | | | | (or variations in the support | 5598 | | | | provided) for the ACE flags. | 5599 | | | | This is to replace a situation in | 5600 | | | | which the client has no real way | 5601 | | | | to deal with the freedom granted | 5602 | | | | to server implementations. | 5603 +----+------+------------------+-----------------------------------+ 5604 | 14 | BC | #14a in S 5.11 | Explicit discussion of the case | 5605 | | | | in which aclsupport is not | 5606 | | | | supported. | 5607 +----+------+------------------+-----------------------------------+ 5608 | 15 | BC | #15a in S 5.11 | Handling of the proper | 5609 | | | | relationship between support for | 5610 | | | #15b in S 7.1 | ALLOW and DENY ACEs. | 5611 | | | | | 5612 | | | #15c in S 7.2 | | 5613 +----+------+------------------+-----------------------------------+ 5614 | 16 | NM | #16a in S 5.1 | Discussion of coherence of acl, | 5615 | | | | sacl, and dacl attributes. | 5616 +----+------+------------------+-----------------------------------+ 5617 | 17 | BC | #17a in S 7.1 | Relationship of support for ALLOW | 5618 | | | | and DENY ACEs | 5619 | | | #17b in S 7.2 | | 5620 +----+------+------------------+-----------------------------------+ 5621 | 18 | BC | #18a in S 7.1 | Need for support of owner, | 5622 | | | | owner_group. | 5623 | | | #18b in S 7.2 | | 5624 +----+------+------------------+-----------------------------------+ 5625 | 19 | CI | #19a in S 7.2 | Revised discussion of | 5626 | | | | coordination of mode and the ACL- | 5627 | | | | related attributes. | 5628 +----+------+------------------+-----------------------------------+ 5629 | 20 | WI | #20 in S 7.3.1 | More closely align ACL_based and | 5630 | | | | mode-based semantics with regard | 5631 | | | | to SVTX. | 5632 +----+------+------------------+-----------------------------------+ 5633 | 21 | BC | #21a in S 4.1 | Introduce the concept of reverse- | 5634 | | | | slope modes and deal properly | 5635 | | | #21b in S 7.3.1 | with them. The decision as to | 5636 | | | | the proper handling is addressed | 5637 | | | | as Consensus Item #28. | 5638 +----+------+------------------+-----------------------------------+ 5639 | 22 | BC | #22a in S 8.1 | Revise treatment of divergences | 5640 | | | | between AC/mode authorization and | 5641 | | | | server behavior, dividing the | 5642 | | | | treatment between cases in which | 5643 | | | | something authorized is still not | 5644 | | | | allowed (OK), and those in which | 5645 | | | | something not authorized is | 5646 | | | | allowed (highly problematic from | 5647 | | | | a security point of view). | 5648 +----+------+------------------+-----------------------------------+ 5649 | 23 | BC | #23a in S 8.2 | Revise discussion of client | 5650 | | | | access to of ACLs. | 5651 +----+------+------------------+-----------------------------------+ 5652 | 24 | BE | #24a in S 8.2 | Delete bogus reference. | 5653 +----+------+------------------+-----------------------------------+ 5654 | 25 | CI | #25a in S 3.3 | Revised description of co- | 5655 | | | | ordination of acl and mode | 5656 | | | #25b in S 9.1 | attributes to apply to NFSv4 as a | 5657 | | | | whole. While this includes many | 5658 | | | #25d in S 9.8 | aspects of the shift to be more | 5659 | | | | specific about the co-ordination | 5660 | | | #25e in S 9.10 | requirements including addressing | 5661 | | | | apparently unmotivated uses of | 5662 | | | #25f in S 9.11 | the terms "SHOULD" and "SHOULD | 5663 | | | | NOT", it excludes some arguably | 5664 | | | #25g in S 9.12 | related matters dealt with as | 5665 | | | | Consensus Items #26 and #27. | 5666 +----+------+------------------+-----------------------------------+ 5667 | 26 | CI | #26a in S 9.2 | Decide how ACEs with who values | 5668 | | | | other than OWNER@, Group, or | 5669 | | | #26 in S 9.7.3 | EVERYONE@ are be dealt with when | 5670 | | | | setting mode. | 5671 +----+------+------------------+-----------------------------------+ 5672 | 27 | CI | #27a in S 9.2 | Concerns the possible existence | 5673 | | | | of multiple methods of computing | 5674 | | | #27b in S 9.3 | a mode from an acl that clients | 5675 | | | | can depend on, and the proper | 5676 | | | #27c in S 9.4 | elationship among these methods. | 5677 +----+------+------------------+-----------------------------------+ 5678 | 28 | WI | #28a in S 9.2 | Decide how to address flaws in | 5679 | | | | mapping to/from reverse- slope | 5680 | | | #28b in S 9.3 | modes. | 5681 | | | | | 5682 | | | #28 in S 9.7.3 | | 5683 +----+------+------------------+-----------------------------------+ 5684 | 29 | BC | #29 in S 9.7.3 | Address the coordination of mode | 5685 | | | | and ACL-based attributes in | 5686 | | | | unified way for all minor | 5687 | | | | versions. | 5688 +----+------+------------------+-----------------------------------+ 5689 | 30 | CI | #30a in S 9.7.1 | New proposed treatment of setting | 5690 | | | | mode incorporating some | 5691 | | | #30b in S 9.7.2 | consequences of anticipated | 5692 | | | | decisions regarding other | 5693 | | | #30c in S 9.7.3 | consensus items (#26, #28, #29) | 5694 +----+------+------------------+-----------------------------------+ 5695 | 31 | WI | #31a in S 9.7.3 | Need to deal with mask bits | 5696 | | | | ACE4_READ_ATTRIBUTES, | 5697 | | | | ACE4_WRITE_RETENTION, | 5698 | | | | ACE4_WRITE_RETENTION_HOLD, | 5699 | | | | ACE4_READ_ACL to reflect the | 5700 | | | | semantics of the mode attribute. | 5701 +----+------+------------------+-----------------------------------+ 5702 | 32 | BC | #32a in S 15 | Expanded negotiation framework to | 5703 | | | | accommodate multiple transport | 5704 | | | #32b in S 15.1 | types and security services | 5705 | | | | provided on a per-connection | 5706 | | | #32c in S 18 | basis, i.e. encryption and peer | 5707 | | | | authentication. | 5708 | | | #32d in S 18.1 | | 5709 | | | | | 5710 | | | #32e in S 18.2 | | 5711 +----+------+------------------+-----------------------------------+ 5712 | 33 | RJ | Material | Reorganization of description of | 5713 | | | formerly here | SECINFO op to apply to all minor | 5714 | | | moved to #32. | versions. (Dropped) | 5715 +----+------+------------------+-----------------------------------+ 5716 | 34 | RJ | Superseded by | Revision to NFSv4.0 SECINFO | 5717 | | | simpler | implementation section (Dropped. | 5718 | | | treatment. | | 5719 +----+------+------------------+-----------------------------------+ 5720 | 35 | NE | #35a in S 16 | Now has preliminary work on | 5721 | | | | future security needs. | 5722 +----+------+------------------+-----------------------------------+ 5723 | 36 | CI | #36a in S 17.1.3 | Threat analysis only dealing with | 5724 | | | | RECOMMENDED behavior regarding | 5725 | | | | use of per-connection security | 5726 | | | | facilities and handling of | 5727 | | | | AUTH_SYS. | 5728 +----+------+------------------+-----------------------------------+ 5729 | 37 | CI | #37a in S 17.1.3 | Threat analysis only dealing with | 5730 | | | | RECOMMENDED behavior with regard | 5731 | | | | to acl support including ACL/mode | 5732 | | | | coordination. | 5733 +----+------+------------------+-----------------------------------+ 5734 | 38 | CI | #38a in S 17.1.4 | Address the need to temporarily | 5735 | | | | allow unsafe behavior mistakenly | 5736 | | | | allowed by previous | 5737 | | | | specifications | 5738 +----+------+------------------+-----------------------------------+ 5739 | 39 | CI | #39a in S 17.1.5 | Define new approach to AUTH_SYS. | 5740 +----+------+------------------+-----------------------------------+ 5741 | 40 | CI | #40a in S 17.2.1 | Discussion of scope for security | 5742 | | | | considerations and the | 5743 | | | #40a in S 17.2.2 | corresponding threat analysis. | 5744 +----+------+------------------+-----------------------------------+ 5745 | 41 | CI | #41a in S 8.1 | Discuss major new security | 5746 | | | | recommendations regarding | 5747 | | | #41b in S 17.3.1 | protection of data in flight and | 5748 | | | | client peer authentication. | 5749 | | | #41c in S 17.3.2 | Also, covers the circumstances | 5750 | | | | under which such recommendations | 5751 | | | #41d in S 17.3.4 | can be bypassed. | 5752 | | | | | 5753 +----+------+------------------+-----------------------------------+ 5754 | 42 | RT | #42a in S 17.4.5 | Former placeholders for threat | 5755 +----+------+------------------+ analysis subsections have now | 5756 | 43 | RT | #43a in S | been superseded by new proposed | 5757 | | | 17.4.6.1 | subsections. | 5758 +----+------+------------------+ | 5759 | 44 | RT | #44a in S | | 5760 | | | 17.4.6.2 | | 5761 +----+------+------------------+ | 5762 | 45 | RT | #45a in S | | 5763 | | | 17.4.7.1 | | 5764 +----+------+------------------+ | 5765 | 46 | RT | #46a in S | | 5766 | | | 17.4.7.2 | | 5767 +----+------+------------------+-----------------------------------+ 5768 | 47 | CI | gone fir now. | Dubious paragraph regarding | 5769 | | | | AUTH_NONe is SECINFO response | 5770 | | | | which should be deleted if there | 5771 | | | | are no compatibility issues that | 5772 | | | | make that impossible. | 5773 +----+------+------------------+-----------------------------------+ 5774 | 48 | RJ | Superseded by | Missing pieces of secinfo | 5775 | | | simpler | processing algorithm that didn't | 5776 | | | treatment. | get done in -02. | 5777 +----+------+------------------+-----------------------------------+ 5778 | 49 | RJ | perseded by | Secinfo processing algorithm that | 5779 | | | simpler | needs to finished in -04. | 5780 | | | treatment. | | 5781 +----+------+------------------+-----------------------------------+ 5782 | 50 | BC | #50a in S 5.9 | Revise handling of "special" who | 5783 | | | | values, making it clear for which | 5784 | | | | ones "special" is a euphemism for | 5785 | | | | "semantics-challenged". | 5786 +----+------+------------------+-----------------------------------+ 5787 | 51 | BC | #51a in S 5.9 | Clarify the handling of the group | 5788 | | | | bit for the special who values. | 5789 +----+------+------------------+-----------------------------------+ 5790 | 52 | BC | #52a in S 8.1 | Eliminate superuser semantics as | 5791 | | | | it had been, as valid by | 5792 | | | #52b in S 17.3.3 | implication. Also, deal with the | 5793 | | | | security consequences of its | 5794 | | | | inclusion appropriately. | 5795 +----+------+------------------+-----------------------------------+ 5796 | 53 | EV | #53a in S 17.4.2 | Discussion of possible adaptation | 5797 | | | | of RPCSEC_GSS/Kerberos to multi- | 5798 | | | | factor authentication. | 5799 +----+------+------------------+-----------------------------------+ 5800 | 54 | EV | #54a in S | Discussion of prevention of code | 5801 | | | 17.4.6.1 | on a compromised client from | 5802 | | | | hijacking the client machine's | 5803 | | | | peer authentication. | 5804 +----+------+------------------+-----------------------------------+ 5805 | 55 | EV | #55a in S | Discussion of issues with | 5806 | | | 17.4.6.1 | potential use of Kerberos in | 5807 | | | | cloud environments | 5808 +----+------+------------------+-----------------------------------+ 5809 | 56 | WI | #56a in S 4.1 | Discussion of issues related to | 5810 | | | | the handling of UNIX ACLs. | 5811 | | | #56b in S 9.5 | | 5812 | | | | | 5813 | | | #56c in S 16 | | 5814 +----+------+------------------+-----------------------------------+ 5816 Table 3 5818 The following table summarizes the issues in each particular pending 5819 state, dividing them into those associated with the motivating 5820 changes for this new document and those that derive from other 5821 issues, that were uncovered later, once work on a new treatment of 5822 NFSv4 security had begun. 5824 +========+=====+============================+ 5825 | Type | Cnt | Issues | 5826 +========+=====+============================+ 5827 | NM*(M) | 2 | 1, 2 | 5828 +--------+-----+----------------------------+ 5829 | BC(M) | 2 | 32, 52 | 5830 +--------+-----+----------------------------+ 5831 | CI(M) | 5 | 36, 38, 39, 40, 41 | 5832 +--------+-----+----------------------------+ 5833 | WI(M) | 1 | 47 | 5834 +--------+-----+----------------------------+ 5835 | NE(M) | 1 | 35 | 5836 +--------+-----+----------------------------+ 5837 | EV(M) | 3 | 53, 54, 55 | 5838 +--------+-----+----------------------------+ 5839 | All(M) | 14 | As listed above. | 5840 +--------+-----+----------------------------+ 5841 | NM(O) | 1 | 16 | 5842 +--------+-----+----------------------------+ 5843 | BE(O) | 4 | 3, 5, 7, 24 | 5844 +--------+-----+----------------------------+ 5845 | BC(O) | 14 | 9, 10, 12, 13, 14, 15, 17, | 5846 | | | 18, 21, 22, 23, 29, 50, 51 | 5847 +--------+-----+----------------------------+ 5848 | CI(O) | 10 | 4, 6, 8, 11, 19, 25, 26, | 5849 | | | 27, 30, 37 | 5850 +--------+-----+----------------------------+ 5851 | WI(O) | 4 | 20, 28, 31, 56 | 5852 +--------+-----+----------------------------+ 5853 | All(O) | 33 | As described above | 5854 +--------+-----+----------------------------+ 5855 | *All* | 47 | Grand total for above | 5856 | | | table. | 5857 +--------+-----+----------------------------+ 5859 Table 4 5861 The following table summarizes the issues in each particular non- 5862 pending state, dividing them into those associated with the 5863 motivating changes for this new document and those that derive from 5864 other issues, that were uncovered later, once work on a new treatment 5865 of NFSv4 security had begun. 5867 +========+=====+==============================+ 5868 | Type | Cnt | Issues | 5869 +========+=====+==============================+ 5870 | RT(M) | 5 | 42, 43, 44, 45, 46 | 5871 +--------+-----+------------------------------+ 5872 | RJ(M) | 4 | 33, 34, 48, 49 | 5873 +--------+-----+------------------------------+ 5874 | All(M) | 9 | As listed above. | 5875 +--------+-----+------------------------------+ 5876 | All(O) | 0 | Nothing yet. | 5877 +--------+-----+------------------------------+ 5878 | *All* | 9 | Grand total for above table. | 5879 +--------+-----+------------------------------+ 5881 Table 5 5883 Acknowledgments 5885 The author wishes to thank Tom Haynes for his helpful suggestion to 5886 deal with security for all NFSv4 minor versions in the same document. 5888 The author wishes to draw people's attention to Nico Williams' remark 5889 that NFSv4 security was not so bad, except that there was no 5890 provision for authentication of the client peer. This perceptive 5891 remark, which now seems like common sense, did not seem so when made, 5892 but it has served as a beacon for those working on putting NFSv4 5893 security on a firmer footing. We appreciate this perceptive 5894 guidance. 5896 The author wishes to thank Bruce Fields for his helpful comments 5897 regarding ACL support which had a major role in the evolution of this 5898 document. 5900 The author wishes to acknowledge the important role of the authors of 5901 RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS 5902 security agenda forward and thank them for all their efforts to 5903 improve NFS security. 5905 The author wishes to thank Chuck Lever for his many helpful comments 5906 about nfsv4 security issues, his explanation of many unclear points, 5907 and and much important guidance he provided that is reflected in this 5908 document. 5910 The author wishes to thank Rick Macklem for his role in clarifying 5911 possible server policies regarding RPC-with-TLS and in bringing the 5912 to the Working Group's attention the possibility of deriving limited 5913 principal identification from client peer authentication while still 5914 staying within the boundaries of RPC-with-TLS. 5916 Author's Address 5918 David Noveck (editor) 5919 NetApp 5920 1601 Trapelo Road, Suite 16 5921 Waltham, MA 02451 5922 United States of America 5924 Phone: +1-781-572-8038 5925 Email: davenoveck@gmail.com