idnits 2.17.1 draft-dnoveck-nfsv4-security-02.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 : ---------------------------------------------------------------------------- -- 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 926 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 (13 October 2021) is 916 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 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) 13 October 2021 5 Intended status: Standards Track 6 Expires: 16 April 2022 8 Security for the NFSv4 Protocols 9 draft-dnoveck-nfsv4-security-02 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 the RPC transport. 17 This preliminary version of the document, is intended, in large part, 18 to result in working group discussion regarding existing NFSv4 19 security issues and to provide a framework for addressing these 20 issues and obtaining working group consensus regarding necessary 21 changes. 23 When a successor document is eventually published as an RFC, it will 24 supersede the description of security appearing in existing minor 25 version specification documents such as RFC 7530 and RFC 8881. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 16 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Document Motivation . . . . . . . . . . . . . . . . . . . 5 74 1.2. Document Annotation . . . . . . . . . . . . . . . . . . . 6 75 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 76 2.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 7 77 2.2. Special Considerations . . . . . . . . . . . . . . . . . 7 78 3. Introduction to this Update . . . . . . . . . . . . . . . . . 8 79 3.1. Transport-based Security Features . . . . . . . . . . . . 8 80 3.2. Handling of Multiple Minor Versions . . . . . . . . . . . 9 81 3.3. Handling of Minor-version-specific features . . . . . . . 10 82 3.4. Features Needing Extensive Clarification . . . . . . . . 12 83 3.5. Process Going Forward . . . . . . . . . . . . . . . . . . 15 84 4. Introduction to NFSv4 Security . . . . . . . . . . . . . . . 17 85 5. Structure of Access Control Lists . . . . . . . . . . . . . . 19 86 5.1. Access Control Entries . . . . . . . . . . . . . . . . . 20 87 5.2. ACE Type . . . . . . . . . . . . . . . . . . . . . . . . 20 88 5.3. ACE Access Mask . . . . . . . . . . . . . . . . . . . . . 22 89 5.4. Uses of Mask Bits . . . . . . . . . . . . . . . . . . . . 22 90 5.5. Requirements and Recommendations Regarding Mask 91 Granularity . . . . . . . . . . . . . . . . . . . . . . 32 92 5.6. Handling of Deletion . . . . . . . . . . . . . . . . . . 34 93 5.6.1. Previous Handling of Deletion . . . . . . . . . . . . 35 94 5.7. ACE flag bits . . . . . . . . . . . . . . . . . . . . . . 36 95 5.8. Details Regarding ACE Flag Bits . . . . . . . . . . . . . 38 96 5.9. ACE Who . . . . . . . . . . . . . . . . . . . . . . . . . 40 97 5.10. Automatic Inheritance Features . . . . . . . . . . . . . 41 98 5.11. Attribute 13: aclsupport . . . . . . . . . . . . . . . . 44 99 5.12. Attribute 12: acl . . . . . . . . . . . . . . . . . . . . 45 100 6. Authorization in General . . . . . . . . . . . . . . . . . . 46 101 7. User-based File Access Authorization . . . . . . . . . . . . 46 102 7.1. Attributes for User-based File Access Authorization . . . 46 103 7.2. Handling of Multiple Parallel File Access Authorization 104 Models . . . . . . . . . . . . . . . . . . . . . . . . . 47 105 7.3. Posix Authorization Model . . . . . . . . . . . . . . . . 49 106 7.3.1. Attribute 33: mode . . . . . . . . . . . . . . . . . 49 107 7.3.2. NFSv4.1 Attribute 74: mode_set_masked . . . . . . . . 51 108 7.4. ACL-based Authorization Model . . . . . . . . . . . . . . 52 109 7.4.1. Processing Access Control Entries . . . . . . . . . . 52 110 7.4.2. V4.1 Attribute 58: dacl . . . . . . . . . . . . . . . 54 111 8. Common Considerations for Both File access Models . . . . . . 54 112 8.1. Server Considerations . . . . . . . . . . . . . . . . . . 54 113 8.2. Client Considerations . . . . . . . . . . . . . . . . . . 58 114 9. Combining Authorization Models . . . . . . . . . . . . . . . 59 115 9.1. Background for Combined Authorization Model . . . . . . . 59 116 9.2. Needed Attribute Coordination . . . . . . . . . . . . . . 60 117 9.3. Computing a Mode Attribute from an ACL . . . . . . . . . 63 118 9.4. Alternatives in Computing Mode Bits . . . . . . . . . . . 65 119 9.5. Setting Multiple ACL Attributes . . . . . . . . . . . . . 66 120 9.6. Setting Mode and not ACL (overall) . . . . . . . . . . . 66 121 9.6.1. Setting Mode and not ACL (vestigial) . . . . . . . . 66 122 9.6.2. Setting Mode and not ACL (Discussion) . . . . . . . . 67 123 9.6.3. Setting Mode and not ACL (Proposed) . . . . . . . . . 69 124 9.7. Setting ACL and Not Mode . . . . . . . . . . . . . . . . 73 125 9.8. Setting Both ACL and Mode . . . . . . . . . . . . . . . . 74 126 9.9. Retrieving the Mode and/or ACL Attributes . . . . . . . . 74 127 9.10. Creating New Objects . . . . . . . . . . . . . . . . . . 74 128 9.11. Use of Inherited ACL When Creating Objects . . . . . . . 76 129 9.12. Combined Authorization Models for NFSv4.2 . . . . . . . . 76 130 10. Labelled NFS Authorization Model . . . . . . . . . . . . . . 77 131 11. State Modification Authorization . . . . . . . . . . . . . . 77 132 12. Other Uses of Access Control Lists . . . . . . . . . . . . . 78 133 12.1. V4.1 Attribute 59: sacl . . . . . . . . . . . . . . . . 78 134 13. Identification and Authentication . . . . . . . . . . . . . . 78 135 13.1. Identification vs. Authentication . . . . . . . . . . . 79 136 13.2. Items to be Identified . . . . . . . . . . . . . . . . . 79 137 13.3. Authentication Provided by specific RPC Flavors . . . . 80 138 13.4. Authentication Provided by the RPC Transport . . . . . . 81 139 14. Security of Data in Flight . . . . . . . . . . . . . . . . . 81 140 14.1. Data Security Provided by the Flavor-associated 141 Services . . . . . . . . . . . . . . . . . . . . . . . . 81 142 14.2. Data Security Provided by the RPC Transport . . . . . . 81 143 15. Security Negotiation . . . . . . . . . . . . . . . . . . . . 81 144 15.1. Flavors and Pseudo-flavors . . . . . . . . . . . . . . . 82 145 15.2. Negotiation of Security Flavors and Mechanisms . . . . . 83 146 15.3. Negotiation of RPC Transports and Characteristics . . . 84 147 15.4. Overall Interpretation of SECINFO Response Arrays . . . 85 148 15.4.1. Interpretation of SECINFO Response Arrays (Core) . . 87 149 15.4.2. Connection Type Transcription . . . . . . . . . . . 89 150 15.4.3. Flavor Transcription . . . . . . . . . . . . . . . . 89 151 15.5. SECINFO . . . . . . . . . . . . . . . . . . . . . . . . 89 152 15.5.4. SECINFO IMPLEMENTATION (general) . . . . . . . . . . 91 153 15.5.5. SECINFO IMPLEMENTATION (for NFSv4.0) . . . . . . . . 92 154 15.5.6. SECINFO IMPLEMENTATION (for NFSv4.1 and v4.2) . . . 93 155 16. Future Security Needs . . . . . . . . . . . . . . . . . . . . 95 156 17. Security Considerations . . . . . . . . . . . . . . . . . . . 96 157 17.1. Changes in Security Considerations . . . . . . . . . . . 96 158 17.1.1. Wider View of Threats . . . . . . . . . . . . . . . 96 159 17.1.2. Transport-layer Security Facilities . . . . . . . . 97 160 17.1.3. Approach to Implementation Semantic Divergences . . 98 161 17.1.4. Compatibility and Maturity Issues . . . . . . . . . 98 162 17.1.5. Discussion of AUTH_SYS . . . . . . . . . . . . . . . 99 163 17.2. Security Considerations Scope . . . . . . . . . . . . . 100 164 17.2.1. Discussion of Potential Classification of 165 Environments . . . . . . . . . . . . . . . . . . . . 100 166 17.2.2. Discussion of Environments . . . . . . . . . . . . . 100 167 17.3. Major New Recommendations . . . . . . . . . . . . . . . 101 168 17.3.1. Recommendations Regarding Security of Data in 169 Flight . . . . . . . . . . . . . . . . . . . . . . . 101 170 17.3.2. Recommendations Regarding Client Peer 171 Authentication . . . . . . . . . . . . . . . . . . . 101 172 17.3.3. Issues Regarding Valid Reasons to Bypass 173 Recommendations . . . . . . . . . . . . . . . . . . . 102 174 17.4. Data Security Threats . . . . . . . . . . . . . . . . . 102 175 17.5. Authentication-based threats . . . . . . . . . . . . . . 102 176 17.5.1. Attacks based on the use of AUTH_SYS . . . . . . . . 102 177 17.5.2. Attacks on Name/Userid Mapping Facilities . . . . . 103 178 17.6. Disruption and Denial-of-Service Attacks . . . . . . . . 103 179 17.6.1. Attacks Based on the Disruption of Client-Server 180 Shared State . . . . . . . . . . . . . . . . . . . . 103 181 17.6.2. Attacks Based on Forcing the Misuse of Server 182 Resources . . . . . . . . . . . . . . . . . . . . . . 103 183 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 184 18.1. New Authstat Values . . . . . . . . . . . . . . . . . . 103 185 18.2. New Authentication Pseudo-Flavors . . . . . . . . . . . 104 186 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 187 19.1. Normative References . . . . . . . . . . . . . . . . . . 105 188 19.2. Informative References . . . . . . . . . . . . . . . . . 106 189 Appendix A. Changes Made . . . . . . . . . . . . . . . . . . . . 106 190 A.1. Motivating Changes . . . . . . . . . . . . . . . . . . . 107 191 A.2. Other Major Changes . . . . . . . . . . . . . . . . . . . 107 193 Appendix B. Issues for which Consensus Needs to be 194 Ascertained . . . . . . . . . . . . . . . . . . . . . . . 108 195 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 117 196 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118 198 1. Overview 200 This document is intended to form the basis for a new description of 201 NFSv4 security applying to all NFSv4 minor versions. The motivation 202 for this new document and the need for major improvements in NFSv4 203 security are explained in Section 1.1. 205 Because this document anticipates making major changes in material 206 covered in previous standards-track RFCs, extensive working group 207 discussion will be necessary to make sure that there is a working 208 group consensus to make the changes being proposed. These changes 209 include the major improvements mentioned above and changes necessary 210 to suitably describe features currently in an unsatisfactory state as 211 described in Section 3.4 213 1.1. Document Motivation 215 A new treatment of security is necessary because: 217 * Previous treatments paid insufficient attention to security issues 218 regarding data in flight. 220 * The presentation of AUTH_SYS as an "'OPTIONAL' means of 221 authentication" obscured the significant security problems that 222 come with its use. 224 * The security considerations sections of existing minor version 225 specifications contain no threat analyses and focus on particular 226 security issues in a way that obscures, rather than clarifying, 227 the security issues that need to be addressed. 229 * The availability of RPC-with-TLS (described in [12]) provides 230 facilities that NFSv4 clients and servers will need to use to 231 provide security for data in flight and mitigate the lack of 232 authentication when AUTH_SYS is used. 234 1.2. Document Annotation 236 The first version of this preliminary document contained many notes 237 with headers in brackets, requesting comments regarding confusing or 238 otherwise dubious passages in existing documents and noting other 239 choices that need to made. Comments about and working group 240 discussion of these issues will be important in arriving at an 241 adequate RFC candidate. In this version, those specific items have 242 been removed and are replaced by the sorts of items described below 243 which show the troublesome existing text, explain the issues with it, 244 and and provide a proposed replacement. 246 In order to make further progress on these difficult issues, 247 including many whose resolution will probably involve compatibility 248 issues with existing implementations, the author has tried his best 249 to resolve these issues, even though there is no assurance that the 250 resolution adopted by consensus will match the author's current best 251 efforts. To provide a possible resolution that might be the basis of 252 discussion while not foreclosing other possibilities, proposed 253 changes are organized into a series of consensus items, which are 254 listed in Appendix B. 256 For such pending issues, the following annotations will be used: 258 * A paragraph headed "[Author Aside]:", provides the author's 259 comments about possible changes and will probably not appear in an 260 eventual RFC. 262 This paragraph can specify that certain changes within the current 263 section are to be implicitly considered as part of a specific 264 consensus item. 266 The paragraph can indicate that all unannotated material in the 267 current section is to be considered either the previous treatment 268 or the proposed replacement text for a specific consensus item. 270 * A paragraph headed "[Consensus Needed (Item #NNx)]:", provides the 271 author's preferred treatment of the matter and should only appear 272 in the eventual RFC if working group consensus on the matter is 273 obtained allowing the necessary changes to be made permanent, 274 without being conditional on a future consensus. 276 The item id, represented above by "NNx" consists of a number 277 identifying the specific consensus item and letter which is unique 278 to appearance of that consensus item in a particular section. In 279 cases in which a pending item is cited with no part of the 280 discussion appearing in the current section, an item id of the 281 form "#NN" is used. 283 * A paragraph headed "[Previous Treatment]:", indicates text that is 284 provided for context but which the author believes, should not 285 appear in the eventual RFC, because it is expected to be 286 superseded by a corresponding consensus item 288 The corresponding consensus item is often easily inferred, but can 289 be specified explicitly, as it is for items associated with the 290 consensus item itself. 292 Each of the annotations above can be modified by addition of the 293 phrase, "Including List" to indicate that it applies to a following 294 bulleted list as well as the current paragraph. 296 2. Requirements Language 298 2.1. Keyword Definitions 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 302 document are to be interpreted as specified in BCP 14 [1] [5] when, 303 and only when, they appear in all capitals, as shown here. 305 2.2. Special Considerations 307 Because this document needs to revise previous treatments of its 308 subject, it will need to cite previous treatments of issues that now 309 need to be dealt with in a different way. This will take the form of 310 quotations from documents whose treatment of the subject is being 311 obsoleted, most often direct but sometimes indirect as well. 313 Paragraphs headed "[Previous Treatment] or otherwise annotated as 314 having that status, as described in Section 1, can be considered 315 quotations in this context. 317 Such treatments in quotations will involve use of these BCP14-defined 318 terms in two noteworthy ways: 320 * The term may have been used inappropriately (i.e not in accord 321 with [1]), as has been the case for the "RECOMMENDED" attributes, 322 which are in fact OPTIONAL. 324 In such cases, the surrounding text will make clear that the 325 quoted text does not have a normative effect. 327 Some specific issues relating to this case are described below 328 Section 7.1. 330 * The term may been used in accord with [1], although the resulting 331 normative statement is now felt to be inappropriate. 333 In such cases, the surrounding text will need to make clear that 334 the text quoted is no longer to be considered normative, often by 335 providing new text that conflicts with the quoted, previously 336 normative, text. 338 An important instance of this situation is the description of 339 AUTH_SYS as an "OPTIONAL" means of authentication. For detailed 340 discussion of this case, see Sections 13 and 17.1.5 342 3. Introduction to this Update 344 There are a number of noteworthy aspects to the updated approach to 345 NFSv4 security presented in this document: 347 * There is a major rework of the security framework to take 348 advantage of work done in RPC-with-TLS, as described in 349 Section 1.1. 351 NFSv4 security is still built on RPC, as had been done previously. 352 However, it is now able to take advantage of security-related 353 transport properties. For more information about this 354 transformation, see Section 3.1. 356 For an overview of changes made so far as part of this rework, see 357 Appendix A.1. 359 * This document deals with all minor versions together, although 360 there is a need for exceptions to deal with, for example, pNFS 361 security. 363 For more detail about how minor version differences will be 364 addressed, see Sections 3.2 and 3.3. 366 * There is a new Security Considerations section including a threat 367 analysis. 369 * There has been extensive work to clarify the multiple types of 370 authorization within NFSv4 and deal more completely with the co- 371 ordination of ACL-based and mode-based file access authorization. 373 3.1. Transport-based Security Features 375 There are a number of security-related facilities that can be 376 provided at the transport layer eliminating the need to provide such 377 support to as part of RPC proper. 379 These will initially be provided by RPC-with-TLS but similar 380 facilities might be provided by new versions of existing transports 381 or new RPC transports. 383 * The transport might provide encryption of requests and replies, 384 eliminating the need for privacy and integrity services to be 385 negotiated later and applied on a per-request basis. 387 While clients might choose to establish connections with such 388 encryption, servers can establish policies allowing access to 389 certain pieces of the namespace using such transports, or limiting 390 access to those providing privacy, allowing the use of either 391 transport-based encryption or privacy services provided by 392 RPCSEC_GSS. 394 * The transport might provide mutual authentication of the client 395 and server peers as part of the establishment of the connection 396 This authentication is distinct from the the mutual authentication 397 of the client user and server peer, implemented within the 398 GSSSEC_RPC framework. 400 This form of authentication is of particular importance when when 401 the server allows the use of the flavors AUTH_SYS and AUTH_NONE, 402 which have no provision for the authentication of the user 403 requesting the operation. 405 While clients might choose, on their own,to establish connections 406 with such peer authentication, servers can establish policies a 407 limiting access to certain pieces of the namespace without such 408 peer authentication or only allowing it when using RPCSEC_GSS. 410 To enable server policies to be effectively communicated to clients, 411 the security negotiation framework now allows connection 412 characteristics to be specified using pseudo-flavors returned as part 413 of the response to SECINFO and SECINFO_NONAME. See Section 15 for 414 details. 416 3.2. Handling of Multiple Minor Versions 418 In some cases, there are differences between minor versions in that 419 there are security-related features, not present in all minor 420 versions. 422 To deal with this issue, this document will focus on a few major 423 areas listed below which are common to all minor versions. 425 * File access authorization (discussed in Section 7) is the same in 426 all minor versions together with the identification/ 427 authentication infrastructure supporting it (discussed in 428 Section 13) provided by RPC and applying to all of NFS. 430 An exception is made regarding labelled NFS, an optional feature 431 within NFSv4.2, described in [10]. This is discussed as a 432 version-specific feature in this document in Section 10 434 * Features to secure data in-flight, all provided by RPC, together 435 with the negotiation infrastructure to support them are common to 436 all NFSv4 minor versions, are discussed in Section 15 438 However, the use of SECINFO_NONAME, together with changes needed 439 for transport level encryption, paralleling those proposed here 440 for SECINFO, is treated as a version-specific feature and, while 441 mentioned here, will be fully documented in new NFSv4.1 442 specification documents. 444 * The protection of state data from unauthorized modification is 445 discussed in Section 11) is the same in all minor versions 446 together with the identification/ authentication infrastructure 447 supporting it (discussed in Section 13) provided by secure 448 transports such as RPC-over-TLS. 450 It should be noted that state protection based on RPCSEC_GSS is 451 treated as a version-specific feature and will continue to be 452 described by [8] or its successors. Also, it needs to be noted 453 that the use of state protection was not discussed in [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 needs to be modified to match the description of SECINFO 476 appearing in this document. It is expected that this will be done 477 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 pNFS optional 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 and its successors (i.e. the rfc5661bis document suite). However, 491 because pNFS security relies heavily on the infrastructure 492 discussed here, it is anticipated that the new treatment of pNFS 493 security will deal with many matters by referencing the overall 494 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 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 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 and RFC8881. 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 [13], now part of NFSv4.2, is 534 also related to the issue of co-ordination of acl and mode 535 attributes and will be discussed in that context. 537 Nevertheless, the description in [13] will remain definitive. 539 * The NFSv4.1 attribute set-mode-masked attribute is mentioned 540 together with the other attributes implementing the POSIX 541 authorization model. 543 Because this attribute. while related to security, does not 544 substantively modify the security properties of the protocol, the 545 full description of this attribute, will continue to be the 546 province of the NFSv4.1 specification proper. 548 * There is a brief description of the v4.2 Labelled NFS feature in 549 Section 10. Part of that description discusses the limitations in 550 the description of that feature within [10]. 552 Because of some limitations in the description, it is not possible 553 to provide an appropriate security considerations section for that 554 feature in this document. 556 As a result, the responsibility for providing an appropriate 557 Security Considerations section remains, unrealized for now, with 558 the NFSv4.2 specification document and its possible successors. 560 3.4. Features Needing Extensive Clarification 562 For a number of authorization-related features, the existing 563 descriptions are inadequate for various reasons: 565 * In the description of the the use of the mode attribute in 566 implementing the POSIX-based authorization model, critical pieces 567 of the semantics are not mentioned, while, ironically, the 568 corresponding semantics for ACL-based authorization are discussed. 570 This includes the authorization of file deletion and of 571 modification of the mode, owner and owner-group attributes. For 572 ACL-based authorization, there is a an attempt to provide the 573 description. 575 The situation for authorization of RENAME is similar, although, in 576 this case, the corresponding semantics for the ACL case are also 577 absent. 579 * The description of authorization for ACLs is more complete but it 580 needs further work, because the previous specifications make 581 extensive efforts, in my view misguided, to allow an enormous 582 range of server behaviors, making it hard for a client to know 583 what the effect of many actions, and the corresponding security- 584 related consequences, might be. 586 Troublesome in this connection are the discussion of ACE mask bits 587 which essentially treats every mask bit, as its own OPTIONAL 588 feature, the use of "SHOULD" and "SHOULD NOT" in situations which 589 it is unclear what valid reasons to ignore the recommendation 590 might be, and cases in which it is is simply stated that some 591 servers do some particular thing, leaving the unfortunate 592 implication that clients need to be prepared for a vast range of 593 server behaviors. 595 This approach essentially treated ACLs in a manner appropriate to 596 an experimental feature. 598 * Similar issues apply to descriptions related to the need to co- 599 ordinate the values of the mode attribute and the ACL-related 600 attributes. 602 Although the need for such coordination is recognized. There are 603 multiple modes of mapping an ACL to a corresponding mode together 604 with multiple sources of uncertainty about the reverse mapping. 606 In addition, certain of the mapping algorithms have flaws in that 607 their behavior under unusual circumstances give results that 608 appear erroneous. 610 Dealing with these issues is not straightforward, because the 611 appropriate resolution will depend on: 613 * The actual existence of server implementations with non-preferred 614 semantics. 616 In some cases in which "SHOULD" was used, there may not have been 617 any actual severs choosing to ignore the recommendation, 618 eliminating the possibility of compatibility issues when changing 619 the "SHOULD" to a formulation that restricts the server's choices. 621 * The difficulty of modifying server implementations to eliminate or 622 narrow the effect of non-standard semantics. 624 One aspect of that difficulty might be client or application 625 expectations based on existing server implementations, even if the 626 existing specifications give the client no assurance that that 627 server's behavior is mandated by the standard. 629 * Whether the existing flaw in some existing recommended actions to 630 be performed by the server is sufficiently troublesome to justify 631 changing the specification at this point. 633 This sort of information will be used in deciding whether to: 635 * Narrow the scope of allowable server behavior to those actually 636 used by existing severs. 638 * Limiting the negative effects of unmotivated SHOULDs by limiting 639 valid reasons to ignore the recommendation to the difficulty of 640 changing existing implementations. 642 This would give significant guidance to future implementations, 643 while forcing clients to live with the uncertainty about existing 644 servers 646 * Tie a more restricted set of semantics to nominally unrelated 647 OPTIONAL features such as implementation of dacl and sacl. 649 This would provide a way to allow the development of newer servers 650 to proceed in a way that 652 * Provide means that clients to use to determine, experimentally, 653 what semantics are provided by the server. 655 Would need to be supported by a requirement/assurance that a 656 server behave uniformly, at least within the scope of a single 657 filesystem. 659 * Allow the provision of other ways for the client to know the 660 semantics choices made by the server. 662 Despite the difficulty of addressing these issues, if the protocol is 663 to be secure and ACLs are to be widely available, these problems must 664 be addressed. While there has not been significant effort to provide 665 client-side ACL APIs and there might not be for a while, we cannot 666 have a situation if which the security specification makes that 667 development essentially impossible. 669 3.5. Process Going Forward 671 Because of the scope of this document, and the fact that it is 672 necessary to modify previous treatments of the subject previously 673 published as Proposed Standards, it is necessary that the process of 674 determining whether there is Working Group Consensus to submit it for 675 publication be more structured than that used for the antecedent 676 documents. 678 In order to facilitate this process, the necessary changes which need 679 to be made, beyond those clearly editorial in nature, are listed in 680 Appendix B. As working group review and discussion of this document 681 and its successors proceeds, there will be occasion to discuss each 682 of these changes, identified by the annotations described in 683 Section 1.2. 685 Based on working group discussions, successive document versions will 686 do one of the following for some set of consensus items: 688 * Deciding that the replacement text is now part of a new working 689 group consensus. 691 When this happens, future drafts of the document will be modified 692 to remove the previous treatment, treat the proposed text as 693 adopted, and remove Author Asides or replace them by new text 694 explaining why a new treatment of the matter has been adopted or 695 pointing the reader to an explanation in Appendix A. 697 At this point, the consensus item will be removed from Appendix B 698 and an explanation for the change will be added to Appendix A. 700 * Deciding that the general approach to the issue, if not 701 necessarily the specific current text has reached the point of 702 "general acceptance" as defined in Appendix B 704 In this case, to facilitate discussion of remaining issues, the 705 text of the document proper will remain as it is. 707 At this point, the consensus item will be marked within the table 708 in Appendix B as having reached general acceptance, indicating the 709 need to prioritize discussion in the next document cycle, aimed at 710 arriving at final text to address the issue. 712 In addition, an explanation for the change will be added to 713 Appendix A. 715 * Deciding that modification of the existing text is necessary to 716 facilitate eventual consensus, based on the working group's input. 718 In this case, there will be changes to the document proper in the 719 next draft revision. In some cases, because of the need for a 720 coherent description, text outside the consensus item may be 721 affected. 723 The table in Appendix B will be updated to reflect the new item 724 status while Appendix A is not expected to change. 726 * Deciding that the item is best dropped in the next draft. 728 In this case, the changes to the document proper will be the 729 inverse of those when a change is accepted by consensus. The 730 previous treatment will be restored as the current text while the 731 proposed new text will vanish from the document at the next draft 732 revision. The Author Aside will be the basis for an explanation 733 of the consequences of not dealing with the issue. 735 At this point, the consensus item will be removed from Appendix B. 737 The changes that the working group will need to reach consensus on, 738 either to accept (as-is or with significant modifications) or reject 739 can be divided into three groups. 741 * A large set of changes, all addressing issues mentioned in 742 Section 1.1, were already present in the initial I-D so that there 743 has been the opportunity for working group discussion of them, 744 although that discussion has been quite limited so far. 746 As a result, a small set of these changes is marked, in 747 Appendix B, as having reached general acceptance. 749 That subset of these changes changes, together with the 750 organizational changes to support them are described in 751 Appendix A.1. 753 * Another large set of changes were made in draft -02. These mostly 754 concern the issues mentioned in Section 3.4 None of these changes 755 is yet considered to have reached general acceptance. 757 The organizational changes to support these changes are described 758 in Appendix A.2. 760 * There remain a set of potential changes for which a need is 761 expected but for which no text is yet available. 763 Such changes have associated Author Asides and are listed in 764 Appendix B. 766 The text for these changes is expected to be made available in 767 future document revisions and they will be processed then, in the 768 same way as other changes will be processed now. 770 If and when such changes reach general acceptance, they will be 771 explained in the appropriate subsection of Appendix A. 773 4. Introduction to NFSv4 Security 775 Because the basic approach to security issues is so similar for all 776 minor versions, this document applies to all NFSv4 minor versions. 777 The details of the transition to an NFSv4-wide document are discussed 778 in Sections 3.2 and 3.3. 780 NFSv4 security is built on facilities provided by the RPC layer, 781 including various authentication flavors and underlying transports. 783 [Consensus Needed, Including List (Item #1a)}: Support for multiple 784 authentication flavors can be provided. Not all of these actually 785 provide authentication, as discussed in Section 13. 787 * Support for RPCSEC_GSS is REQUIRED, although use of other flavors 788 is provided for. 790 This flavor provides for mutual authentication of the principal 791 making the request and the server performing it. 793 This flavor allows the client to request the provision of 794 encryption-based services to provide privacy or integrity for 795 specific requests. Although such services are often provided by 796 the underlying RPC transport, this support is useful, when the 797 transport services are not supported or are otherwise unavailable. 799 * AUTH_SYS, provides identification of the principal making the 800 request but SHOULD NOT be used unless the client peer sending the 801 request can be authenticated and there is protection against the 802 modification of the request in flight. 804 Both of the above require transport-level support. 806 * AUTH_NONE does not provide identification of the principal making 807 the request so only should be used for requests for which there is 808 no such principal or for which it would irrelevant. 810 The restrictions mentioned above for AUTH_SYS apply to AUTH_NONE 811 as well. 813 [Consensus Needed, Including List (Item #1a)}: There are important 814 services that can be provided by the RPC transport when RPC-with-TLS 815 is available, or when other transports provide similar services 817 * The transport can provide data security to all requests on the. 818 This is to be preferred to data security provided by the 819 authentication flavor because it provides protection to the 820 request headers, because it applies to requests using all 821 authentication flavors, and because it is more likely to be 822 offloadable. 824 * The transport can authenticate the server to the client peer. 825 This is desirable since that authentication applies even when 826 AUTH_SYS or AUTH_NONE is used. 828 * The transport can authenticate the client-peer to the server at 829 the time the connection is set up. This is essential to allow 830 AUTH_SYS to be used with a modicum of security, based on the 831 server's level of trust with regard to the client peer. 833 [Consensus Needed (Item #2a)}: Because important security-related 834 services depend on the transport used, rather the authentication, the 835 process of security negotiation, described in Section 15 provides for 836 the negotiation of an appropriate transport at connection time if the 837 server's policy limits the range of transports being used and also 838 when use of a particular transport/flavor combination causes 839 NFS4ERR_WRONGSEC to be returned, 841 [Consensus Needed (Item #1a)}: The authentication provided by RPC, is 842 used to provide the basis of authorization, which is discussed in 843 general in Section 6. This includes file access authorization, 844 discussed in Sections 7 through 9 and state modification 845 authorization, discussed in Section 11 846 File access is controlled by the server support for and client use of 847 certain recommended attributes, as described in Section 7.1. 848 Multiple file access model are provided for and the considerations 849 discussed in Section 8 apply to all of them. 851 * The mode attribute provides a POSIX-based authorization model, as 852 described in Section 7.3 854 * The ACL-related attributes acl, sacl, and dacl (the last two 855 introduced in NFSv4.1) support a finer grained authorization model 856 and provide additional securiy-related services. The structure of 857 ACLs is described in Section 5. 859 The ACL-based authorization model is described in Section 7.4 861 The additional security-related services are described in 862 Section 12. These also rely on the authentication provided by 863 RPC. 865 * Because there are two different approaches to file-access 866 authorization, servers might implement both, in which case the 867 associated attributes need to be coordinated as described in 868 Section 9. 870 * NFSv4.2 provides an file access authorization model oriented 871 toward Mandatory Access Control. It is described in Section 10. 872 For reasons described there, its security properties are hard to 873 analyze in detail and this document will not consider it as part 874 of the NFSv4 threat analysis. 876 Authorization of locking state modification is discussed in 877 Section 11. This form of authorization relies on the authentication 878 of the client peer as opposed to file access authorization, which 879 relies on authentication of the client principal. 881 5. Structure of Access Control Lists 883 Access Control Lists consisting of multiple Access Control Elements, 884 while originally designed to support a more flexible authorization 885 model, have multiple uses within NFSv4, with the use of each element 886 depending on its type, as defined in Section 5.2 888 * They may be used to provide a more flexible authorization model as 889 described in Section 7.4. This involves use of Access Control 890 Entries of the ALLOW and DENY types. 892 * They may be used to provide the security-related services 893 described in Section 12. This involves use of Access Control 894 Entries of the AUDIT and ALARM types. 896 Subsections of this section define the structure of ACLs and discuss 897 ACL-related matters that apply to multiple types of ACL use, 898 including the definitions of the acl and aclsupport attributes. 900 Matters that relate to only a single one of these use classes, 901 including the definition of the NFSv4.1-specific attributes dacl and 902 sacl, are discussed in subsections of Sections 7.4 or 12. 904 5.1. Access Control Entries 906 The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each 907 contain an array of Access Control Entries (ACEs) that are associated 908 with the file system object. The client can set and get these 909 attributes attribute, the server is responsible for using the ACL- 910 related attributes to perform access control. The client can use the 911 OPEN or ACCESS operations to check access without modifying or 912 explicitly reading data or metadata. 914 The NFS ACE structure is defined as follows: 916 typedef uint32_t acetype4; 918 typedef uint32_t aceflag4; 920 typedef uint32_t acemask4; 922 struct nfsace4 { 923 acetype4 type; 924 aceflag4 flag; 925 acemask4 access_mask; 926 utf8str_mixed who; 927 }; 929 5.2. ACE Type 931 The constants used for the type field (acetype4) are as follows: 933 const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; 934 const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; 935 const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; 936 const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; 937 All four are permitted in the acl attribute. For NFSv4.1 and beyond, 938 only the ALLOWED and DENIED types may be used in the dacl attribute, 939 and only the AUDIT and ALARM types.x used in the sacl attribute. 941 +==============================+==============+====================+ 942 | Value | Abbreviation | Description | 943 +==============================+==============+====================+ 944 | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants | 945 | | | the ability to | 946 | | | perform the action | 947 | | | specified in | 948 | | | acemask4 to the | 949 | | | file or directory. | 950 +------------------------------+--------------+--------------------+ 951 | ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies | 952 | | | the ability to | 953 | | | perform the action | 954 | | | specified in | 955 | | | acemask4 to the | 956 | | | file or directory. | 957 +------------------------------+--------------+--------------------+ 958 | ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- | 959 | | | dependent way) any | 960 | | | attempt to | 961 | | | perform, for the | 962 | | | file or directory, | 963 | | | any of the actions | 964 | | | specified in | 965 | | | acemask4. | 966 +------------------------------+--------------+--------------------+ 967 | ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm | 968 | | | (in a system- | 969 | | | dependent way) any | 970 | | | attempt to | 971 | | | perform, for the | 972 | | | file or directory, | 973 | | | any of the actions | 974 | | | specified in | 975 | | | acemask4. | 976 +------------------------------+--------------+--------------------+ 978 Table 1 980 The "Abbreviation" column denotes how the types will be referred to 981 throughout the rest of this document. 983 5.3. ACE Access Mask 985 The bitmask constants used for the access mask field of the ACE are 986 as follows: 988 const ACE4_READ_DATA = 0x00000001; 989 const ACE4_LIST_DIRECTORY = 0x00000001; 990 const ACE4_WRITE_DATA = 0x00000002; 991 const ACE4_ADD_FILE = 0x00000002; 992 const ACE4_APPEND_DATA = 0x00000004; 993 const ACE4_ADD_SUBDIRECTORY = 0x00000004; 994 const ACE4_READ_NAMED_ATTRS = 0x00000008; 995 const ACE4_WRITE_NAMED_ATTRS = 0x00000010; 996 const ACE4_EXECUTE = 0x00000020; 997 const ACE4_DELETE_CHILD = 0x00000040; 998 const ACE4_READ_ATTRIBUTES = 0x00000080; 999 const ACE4_WRITE_ATTRIBUTES = 0x00000100; 1000 const ACE4_WRITE_RETENTION = 0x00000200; 1001 const ACE4_WRITE_RETENTION_HOLD = 0x00000400; 1003 const ACE4_DELETE = 0x00010000; 1004 const ACE4_READ_ACL = 0x00020000; 1005 const ACE4_WRITE_ACL = 0x00040000; 1006 const ACE4_WRITE_OWNER = 0x00080000; 1007 const ACE4_SYNCHRONIZE = 0x00100000; 1009 Note that some masks have coincident values, for example, 1010 ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries 1011 ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are 1012 intended to be used with directory objects, while ACE4_READ_DATA, 1013 ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with 1014 non-directory objects. 1016 5.4. Uses of Mask Bits 1018 [Author Aside]: Because this section has been moved to be part of a 1019 general description of ACEs, not limited to authorization, the 1020 descriptions no longer refer to permissions but rather to actions. 1021 This is best considered a purely editorial change, but, to allow for 1022 possible disagreement on the matter, it will be considered, here and 1023 in Appendix B, as consensus item #3a. 1025 [Author Aside]: In a large number of places, SHOULD is used 1026 inappropriately, since there appear to be no valid reasons to allow a 1027 server to ignore what might well be a requirement. Such changes are 1028 not noted individually below. However, they will be considered, here 1029 and in Appendix B, as consensus item #4a. 1031 [Author Aside}: In a significant number of cases the ACCESS operation 1032 is not listed as a operation affected by the mask bit. These 1033 additions are not noted individually below. However, they will be 1034 considered, here and in Appendix B, as consensus item #5a. 1036 [Author Aside, Including List]: In a number of cases, there are 1037 additional changes which go beyond editorial or arguably do so. 1038 These will be marked as their own consensus items usually with an 1039 accompanying author aside but without necessarily citing the previous 1040 treatment. These include: 1042 * Revisions were necessary to clarify the relationship between 1043 READ_DATA and EXECUTE. These are part of consensus item #7a. 1045 * Revisions were necessary to clarify the relationship between 1046 WRITE_DATA and APPEND_DATA. These are part of consensus item #8a. 1048 * Clarification of the handling of RENAME by ADD_SUBDIRECTORY. This 1049 is part of consensus item #9a. 1051 * Revisions in handling of the masks WRITE_RETENTION and 1052 WRITE_RETENTION_HOLD. These are parts of consensus items #10a. 1054 [Author Aside]: Because of the need to address sticky-bit issues as 1055 part of of the ACE mask descriptions, it is appropriate to introduce 1056 the subject here. 1058 [Consensus Item (Item #6a)]: Despite the fact that ACLs and mode bits 1059 are separate means of authentication, it has been necessary, even if 1060 only for the purpose of providing compatibility with earlier 1061 implementations, to introduce the issue here, since reference to this 1062 mode bit are necessary to resolve issues regard directory entry 1063 deletion, as is done in Section 5.6. 1065 [Consensus Item, Including List (Item #6a): The full description of 1066 the role of the sticky-bit appears in Section 7.3.1. In evaluating 1067 and understanding the relationship between the handling of this bit 1068 when ACLs are used and when they are not, the following points need 1069 to be kept in mind: 1071 * This is troublesome in that it combines data normally assigned to 1072 two different authorization models and breaks the overall 1073 architectural arrangement in which the mask bits represent the 1074 mode bits but provide a finer granularity of control. 1076 * It might have been possible to conform to the existing 1077 architectural model if a new mask bit were created to represent to 1078 directory sticky bit. It is probably too late to so now, even 1079 though it would be allowed as an NFSv4.2 extension. 1081 * The new treatment in Section 5.6 is more restrictive than the 1082 previous one appearing in Section 5.6.1. This raises potential 1083 compatibility issues since the new treatment, while designed to 1084 address the same issues was designed to match existing Unix 1085 handling of this bit. 1087 * This handling initially addresses REMOVE and does not address 1088 directory sticky bit semantics with regard to RENAME. Whether it 1089 should do so is still uncertain. 1091 * The handling of this mode bit was not documented in previous 1092 specifications. However, there is a preliminary attempt to do so 1093 in Section 7.3.1. The reason for doing so, is that given the Unix 1094 orientation of the mode attribute, it is likely that servers 1095 currently implement this, even though there is no NFSv4 1096 documentation of this semantics 1098 This treatment needs to be checked for compatibility issues and 1099 also to establish a model that we might adapt to the ACL case. 1101 * In the long term, it would make more sense to allow the client 1102 rather than the server to have the primary role in determining the 1103 semantics for things like this. That does not seem possible right 1104 now but it is worth considering. 1106 ACE4_READ_DATA 1108 Operation(s) affected: 1109 READ 1111 OPEN 1113 ACCESS 1115 Discussion: 1116 The action of reading the data to the data of the file. 1118 [Previous Treatment (Item #7a)]: Servers SHOULD allow a user 1119 the ability to read the data of the file when only the 1120 ACE4_EXECUTE access mask bit is allowed. 1122 [Author Aside]: The treatment needs to be clarified to make it 1123 appropriate to all ACE types. 1125 [Consensus Needed (Item #7a)]: When used to handle READ or OPEN 1126 operations, the handling MUST be identical whether this bit, 1127 ACE4_EXECUTE, or both are present, as the server has no way of 1128 determining whether a file is being read for execution are not. 1129 The only occasion for different handling is in construction of 1130 a corresponding mode or in responding to the ACCESS operation. 1132 ACE4_LIST_DIRECTORY 1134 Operation(s) affected: 1135 READDIR 1137 Discussion: 1138 The action of listing the contents of a directory. 1140 ACE4_WRITE_DATA 1142 Operation(s) affected: 1143 WRITE 1145 OPEN 1147 ACCESS 1149 SETATTR of size 1151 Discussion: 1152 [Author Aside]: Needs to be revised to deal with issues related 1153 to the interaction of WRITE_DATA and APPEND_DATA. 1155 [Consensus Needed (Item #8a)]: The action of modifying existing 1156 data bytes within a file's current data. 1158 [Consensus Needed (Item #8a)]: As there is no way for the 1159 server to decide, in processing an OPEN or ACCESS request, 1160 whether subsequent WRITEs will extend the file or not, the 1161 server will, in processing an OPEN treat masks containing only 1162 WRITE_DATA, only APPEND_DATA, or both identically. 1164 [Consensus Needed (Item #8a)]: In processing a WRITE request, 1165 the server is presumed to have the to determine whether the 1166 current request extends the file and whether it modifies bytes 1167 already in the file. 1169 [Consensus Needed (Item #8a)]: ACE4_WRITE_DATA is required to 1170 process a WRITE which spans pre-existing byte in the file, 1171 whether the file is extended or not. 1173 ACE4_ADD_FILE 1175 Operation(s) affected: 1176 CREATE 1178 LINK 1180 OPEN 1182 RENAME 1184 Discussion: 1185 The action of adding a new file in a directory. The CREATE 1186 operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, 1187 NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not included because 1188 it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when 1189 used to create a regular file. LINK and RENAME are always 1190 affected. 1192 ACE4_APPEND_DATA 1194 Operation(s) affected: 1195 WRITE 1197 ACCESS 1199 OPEN 1201 SETATTR of size 1203 Discussion: 1204 [Author Aside]: Also needs to be revised to deal with issues 1205 related to the interaction of WRITE_DATA and APPEND_DATA. 1207 The action of modifying a file's data, but only starting at 1208 EOF. This allows for the specification of append-only files, 1209 by allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the 1210 same user or group. 1212 [Consensus Needed (Item #8a)]: As there is no way for the 1213 server to decide, in processing an OPEN or ACCESS request, 1214 whether subsequent WRITEs will extend the file or not, the 1215 server will treat masks containing only WRITE_DATA, only 1216 APPEND_DATA or both, identically. 1218 [Consensus Needed (Item #8a)]: If the server is processing a 1219 WRITE request and the area to be written extends beyond the 1220 existing EOF of the file then the state of APPEND_DATA mask bit 1221 is consulted to determine whether the operation is permitted or 1222 whether alarm or audit activities are to be performed. If a 1223 file has an ACL allowing only APPEND_DATA (and not WRITE_DATA) 1224 and a WRITE request is made at an offset below EOF, the server 1225 MUST return NFS4ERR_ACCESS. 1227 [Consensus Needed (Item #8a)]: If the server is processing a 1228 WRITE request and the area to be written does not extend beyond 1229 the existing EOF of the file then the state of APPEND_DATA mask 1230 bit does not need to be consulted to determine whether the 1231 operation is permitted or whether alarm or audit activities are 1232 to be performed. In this case, only the WRITE_DATA mask bit 1233 needs to be checked to determine whether the WRITE is 1234 authorized. 1236 ACE4_ADD_SUBDIRECTORY 1238 Operation(s) affected: 1239 CREATE 1241 RENAME 1243 Discussion: 1244 [Author Aside]: The RENAME cases need to be limited to the 1245 renaming of directories, rather than saying, "The RENAME 1246 operating is always affected." 1248 [Consensus Needed (Item #9a)]: The action of creating a 1249 subdirectory in a directory. The CREATE operation is affected 1250 when nfs_ftype4 is NF4DIR. The RENAME operation is always 1251 affected when directories are renamed and the target directory 1252 ACL contains the mask ACE4_ADD_SUBDIRECTORY. 1254 ACE4_READ_NAMED_ATTRS 1256 Operation(s) affected: 1257 OPENATTR 1259 Discussion: 1260 The action of reading the named attributes of a file or of 1261 looking up the named attribute directory. OPENATTR is affected 1262 when it is not used to create a named attribute directory. 1263 This is when 1) createdir is TRUE, but a named attribute 1264 directory already exists, or 2) createdir is FALSE. 1266 ACE4_WRITE_NAMED_ATTRS 1268 Operation(s) affected: 1270 OPENATTR 1272 Discussion: 1273 The action of writing the named attributes of a file or 1274 creating a named attribute directory. OPENATTR is affected 1275 when it is used to create a named attribute directory. This is 1276 when createdir is TRUE and no named attribute directory exists. 1277 The ability to check whether or not a named attribute directory 1278 exists depends on the ability to look it up; therefore, users 1279 also need the ACE4_READ_NAMED_ATTRS permission in order to 1280 create a named attribute directory. 1282 ACE4_EXECUTE 1284 Operation(s) affected: 1285 READ 1287 OPEN 1289 ACCESS 1291 REMOVE 1293 RENAME 1295 LINK 1297 CREATE 1299 Discussion: 1300 The action of reading a file in order to execute it. 1302 Servers MUST allow a user the ability to read the data of the 1303 file when only the ACE4_EXECUTE access mask bit is allowed. 1304 This is because there is no way to execute a file without 1305 reading the contents. Though a server may treat ACE4_EXECUTE 1306 and ACE4_READ_DATA bits identically when deciding to permit a 1307 READ or OPEN operation, it MUST still allow the two bits to be 1308 set independently in ACLs, and distinguish between them when 1309 replying to ACCESS operations. In particular, servers MUST NOT 1310 silently turn on one of the two bits when the other is set, as 1311 that would make it impossible for the client to correctly 1312 enforce the distinction between read and execute permissions. 1314 As an example, following a SETATTR of the following ACL: 1316 nfsuser:ACE4_EXECUTE:ALLOW 1318 A subsequent GETATTR of ACL for that file will return: 1320 nfsuser:ACE4_EXECUTE:ALLOW 1322 and MUST NOT return: 1324 nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW 1326 ACE4_EXECUTE 1328 Operation(s) affected: 1329 LOOKUP 1331 Discussion: 1332 The action of traversing/searching a directory. 1334 ACE4_DELETE_CHILD 1336 Operation(s) affected: 1337 REMOVE 1339 RENAME 1341 Discussion: 1342 The action of deleting a file or directory within a directory. 1343 See Section 5.6 for information on now ACE4_DELETE and 1344 ACE4_DELETE_CHILD are to interact. 1346 ACE4_READ_ATTRIBUTES 1348 Operation(s) affected: 1349 GETATTR of file system object attributes 1351 VERIFY 1353 NVERIFY 1355 READDIR 1357 Discussion: 1358 The action of reading basic attributes (non-ACLs) of a file. 1359 On a UNIX system, such basic attributes can be thought of as 1360 the stat-level attributes. Allowing this access mask bit would 1361 mean that the entity can execute "ls -l" and stat. If a 1362 READDIR operation requests attributes, this mask must be 1363 allowed for the READDIR to succeed. 1365 ACE4_WRITE_ATTRIBUTES 1366 Operation(s) affected: 1367 SETATTR of time_access_set, time_backup, time_create, 1368 time_modify_set, mimetype, hidden, system. 1370 Discussion: 1371 The action of changing the times associated with a file or 1372 directory to an arbitrary value. Also permission to change the 1373 mimetype, hidden, and system attributes. A user having 1374 ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set 1375 the times associated with a file to the current server time. 1377 ACE4_WRITE_RETENTION 1379 Operation(s) affected: 1380 SETATTR of retention_set, retentevt_set. 1382 Discussion: 1383 The action of modifying the durations for event and non-event- 1384 based retention. Also includes enabling event and non-event- 1385 based retention. 1387 [Author Aside]: The use of "MAY" here ignores the potential for 1388 harm which unexpected modification of the associated attributes 1389 might cause for security/compliance. 1391 [Previous Treatment]: A server MAY behave such that setting 1392 ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION. 1394 [Consensus Needed (Items #10a, #11a)]: Options for coarser- 1395 grained treatment involving this mask bit are discussed in 1396 Section 5.5 1398 ACE4_WRITE_RETENTION_HOLD 1400 Operation(s) affected: 1401 SETATTR of retention_hold. 1403 Discussion: 1404 The action of modifying the administration retention holds. 1406 [Previous Treatment]: A server MAY map ACE4_WRITE_ATTRIBUTES to 1407 ACE_WRITE_RETENTION_HOLD. 1409 [Author Aside]: The use of "MAY" here ignores the potential for 1410 harm which unexpected modification of the associated attributes 1411 might cause for security/compliance. 1413 [Consensus Needed (Items #10a, #11a)]: Options for coarser- 1414 grained treatment of this mask bit are discussed in Section 5.5 1416 ACE4_DELETE 1418 Operation(s) affected: 1419 REMOVE 1421 Discussion: 1422 The action of deleting the associated file or directory. See 1423 Section 5.6 for information on how ACE4_DELETE and 1424 ACE4_DELETE_CHILD are to interact. 1426 ACE4_READ_ACL 1428 Operation(s) affected: 1429 GETATTR of acl, dacl, or sacl 1431 NVERIFY 1433 VERIFY 1435 Discussion: 1436 The action of reading the ACL. 1438 ACE4_WRITE_ACL 1440 Operation(s) affected: 1441 SETATTR of acl and mode 1443 Discussion: 1444 The action of modifying the acl or mode attributes. 1446 ACE4_WRITE_OWNER 1448 Operation(s) affected: 1449 SETATTR of owner and owner_group 1451 Discussion: 1452 The action of modifying the owner or owner_group attributes. 1453 On UNIX systems, this done by executing chown() and chgrp(). 1455 ACE4_SYNCHRONIZE 1457 Operation(s) affected: 1458 NONE 1460 Discussion: 1462 Permission to use the file object as a synchronization 1463 primitive for interprocess communication. This permission is 1464 not enforced or interpreted by the NFSv4.1 server on behalf of 1465 the client. 1467 Typically, the ACE4_SYNCHRONIZE permission is only meaningful 1468 on local file systems, i.e., file systems not accessed via 1469 NFSv4.1. The reason that the permission bit exists is that 1470 some operating environments, such as Windows, use 1471 ACE4_SYNCHRONIZE. 1473 For example, if a client copies a file that has 1474 ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 1475 server, and then later copies the file from the NFSv4.1 server 1476 to a local file system, it is likely that if ACE4_SYNCHRONIZE 1477 was set in the original file, the client will want it set in 1478 the second copy. The first copy will not have the permission 1479 set unless the NFSv4.1 server has the means to set the 1480 ACE4_SYNCHRONIZE bit. The second copy will not have the 1481 permission set unless the NFSv4.1 server has the means to 1482 retrieve the ACE4_SYNCHRONIZE bit. 1484 5.5. Requirements and Recommendations Regarding Mask Granularity 1486 This is new section which replaces material formerly in the previous 1487 section, cited here as "Previous Treatment. The new material, 1488 constituting the remainder of the section is proposed to replace it. 1489 All such unannotated material is to be considered, as part of 1490 consensus item #11b. 1492 [Previous Treatment (Item #11b)]: Server implementations need not 1493 provide the granularity of control that is implied by this list of 1494 masks. For example, POSIX-based systems might not distinguish 1495 ACE4_APPEND_DATA (the ability to append to a file) from 1496 ACE4_WRITE_DATA (the ability to modify existing contents); both masks 1497 would be tied to a single "write" permission bit. When such a server 1498 returns attributes to the client that contain such masks, it would 1499 show ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the the 1500 write permission bit is enabled. 1502 [Previous Treatment (Item #11b)]: If a server receives a SETATTR 1503 request that it cannot accurately implement, it should err in the 1504 direction of more restricted access, except in the previously 1505 discussed cases of execute and read. For example, suppose a server 1506 cannot distinguish overwriting data from appending new data, as 1507 described in the previous paragraph. If a client submits an ALLOW 1508 ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice 1509 versa), the server should either turn off ACE4_APPEND_DATA or reject 1510 the request with NFS4ERR_ATTRNOTSUPP. 1512 [Author Aside]: Giving servers a general freedom to to not support 1513 the masks defined in this section, creates an unacceptable level of 1514 potential interoperability problems. With regard to the specific 1515 example given, it is hard to imagine a server incapable of 1516 distinguishing a write to an offset within existing file and one 1517 beyond it. This applies whether the server in question is 1518 implemented within a POSIX-based system or not. It is true that a 1519 server that used the unmodified POSIX interface to interact with the 1520 file system, rather than a purpose-built VFS, would face this 1521 difficulty, but it not clear that that fact justifies the client 1522 compatibility issues that accommodating this behavior in the protocol 1523 would generate. A further difficulty with the previous treatment is 1524 that it at variance with the approach to other cases in which ACEs 1525 are stored with the understanding that implementations of other 1526 protocols might be responsible for enforcement. 1528 [Author Aside]: A replacement should clearly be based on the idea 1529 that these mask bits were included in NFSv4 for a reason, and that 1530 exceptions need to be justified, and take interoperability issues 1531 into account. The treatment below attempts to do that. 1533 All implementations of the acl, dacl, and sacl attributes SHOULD 1534 follow the definitions provided above in Section 5.4, which allow 1535 finer-grained control of the actions allowed to specific users than 1536 is provided by the mode attribute. Valid reasons to bypass this 1537 guidance include the need for compatibility with clients expecting a 1538 coarser-grained implementation. 1540 The specific cases in which servers may validly provide coarser- 1541 grained implementations are discussed below. 1543 Servers not providing the mask granularity described in Section 5.4 1544 MUST NOT treat masks other than described in that section except as 1545 listed below. 1547 * Servers that do not distinguish between WRITE_DATA and APPEND_DATA 1548 need to make it clear to clients that support for append-only 1549 files is not present. To do that, requests to set ACLs where the 1550 handling for these two masks are different for any specified user 1551 or group are to be rejected with NFS4ERR_ATTRNOTSUPP. 1553 * [Consensus Needed (Items #10b, #11b)]: Servers that combine either 1554 of the masks WRITE_RETENTION or WRITE_RETENTION_HOLD with 1555 WRITE_ATTRIBUTES need to make it clear to clients that the finer- 1556 grained treatment normally expected is not available. To do that, 1557 requests to set ACLs in which the two combined masks are 1558 explicitly assigned different permission states (i.e. one is 1559 ALLOWED while the other is DENIED) for any specific user or group 1560 are to be rejected with NFS4ERR_ATTRNOTSUPP. 1562 The above are in line with the requirement that attempts to set ACLs 1563 that the server cannot enforce, it needs to be clear that there are 1564 cases in which such ACLs need to be set with the expectation that 1565 enforcement will be done by the local file system or by another file 1566 access protocol. In particular, 1568 * In handling the mask bit SYNCHRONIZE, the server is not 1569 responsible for enforcement and so can accept ACLs it has no way 1570 of enforcing. 1572 * When mask bits refers to an OPTIONAL feature that the server does 1573 not support such as named attributes or retention attributes, the 1574 server is allowed to accept ACLs containing mask bits associated 1575 with the unimplemented feature, even though there is no way these 1576 cold be enforced. The expectation is that the files might be 1577 accessed by other protocols having such support or might be 1578 copied, together with associated ACLs to severs capable of 1579 enforcing them. 1581 5.6. Handling of Deletion 1583 [Author Aside]: This section, exclusive of subsections contains a 1584 proposal for the revision of the ACL-based handling of requests to 1585 delete directory entries. All unannotated material within it is to 1586 be considered part of consensus item #12a. 1588 [Author Aside]: The associated previous treatment is to be found in 1589 Section 5.6.1 1591 This section describes the handling requests of that involve deletion 1592 of a directory entry. It needs to be noted that: 1594 * Modification or transfer of a directory, as happens in RENAME is 1595 not covered. 1597 * The deletion of the file's data is dealt with separately as this, 1598 like a truncation to length zero, requires ACE4_WRITE_DATA. 1600 In general, the recognition of such an operation for 1601 authorization/auditing/alarm depends on either of two bits mask bits 1602 being set: ACE4_MASK_DELETE on the file being deleted and 1603 ACE4_MASK_DELETE_CHILD on the directory from which the entry is being 1604 deleted. 1606 In the case of authorization, the above applies even when one of the 1607 bits is allowed and the other is explicitly denied. 1609 [Consensus Items, Including List (#6b, #12a): When neither of the 1610 mask bits is set, the result is normally negative. That is, 1611 permission is denied and no audit or alarm event is recognized. 1612 However, in the case of authorization, the server MAY make permission 1613 dependent on the setting of MODE4_SVTX if the mode attribute is 1614 supported, as follows: 1616 * If that bit not set, allow the removal if and only if 1617 ACE4_ADD_FILE is permitted. 1619 * If that bit is set, allow the removal if and only if ACE4_ADD_FILE 1620 is permitted and the requester is the owner of the target. 1622 5.6.1. Previous Handling of Deletion 1624 [Author Aside]: This section contains the former content of 1625 Section 5.6. All unannotated paragraphs within it are to be 1626 considered the Previous Treatment associated with consensus item 1627 #12b. 1629 [Author Aside, Including List]: Listed below are some of the reasons 1630 that I have tried to replace the existing treatment rather than 1631 address the specific issues mentioned here and in later asides. 1633 * The fact that there is no clear message about what servers are to 1634 do and about whether behavior clients might rely rely on. This 1635 derives in turn from the use of SHOULD in contexts in which it is 1636 clearly not appropriate, combined with non-normative reports of 1637 what some systems do, and the statement that the approach 1638 suggested is a way of providing "something like traditional UNIX- 1639 like semantics". 1641 * The complexity of the approach without any indication that there 1642 is a need for such complexity makes me doubtful that anything was 1643 actually implemented, especially since the text is so wishy-washy 1644 about the need for server implementation. The probability that it 1645 would be implemented so widely that clients might depend on it is 1646 even more remote. 1648 * The fact that how audit and alarm issues are to be dealt with is 1649 not addressed at all. 1651 * The fact that this treatment combines ACL data with mode bit 1652 information in a confused way without any consideration of the 1653 fact that the mode attribute is OPTIONAL. 1655 Two access mask bits govern the ability to delete a directory entry: 1656 ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD 1657 on the containing directory (the "parent"). 1659 Many systems also take the "sticky bit" (MODE4_SVTX) on a directory 1660 to allow unlink only to a user that owns either the target or the 1661 parent; on some such systems the decision also depends on whether the 1662 target is writable. 1664 Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the 1665 target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that 1666 this is true even if the parent or target explicitly denies one of 1667 these permissions.) 1669 If the ACLs in question neither explicitly ALLOW nor DENY either of 1670 the above, and if MODE4_SVTX is not set on the parent, then the 1671 server SHOULD allow the removal if and only if ACE4_ADD_FILE is 1672 permitted. In the case where MODE4_SVTX is set, the server may also 1673 require the remover to own either the parent or the target, or may 1674 require the target to be writable. 1676 This allows servers to support something close to traditional UNIX- 1677 like semantics, with ACE4_ADD_FILE taking the place of the write bit. 1679 5.7. ACE flag bits 1681 The bitmask constants used for the flag field are as follows: 1683 const ACE4_FILE_INHERIT_ACE = 0x00000001; 1684 const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; 1685 const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; 1686 const ACE4_INHERIT_ONLY_ACE = 0x00000008; 1687 const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; 1688 const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; 1689 const ACE4_IDENTIFIER_GROUP = 0x00000040; 1690 const ACE4_INHERITED_ACE = 0x00000080; 1692 [Author Aside]: Although there are multiple distinct issues that 1693 might need to be changed, in the interest of simplifying the review, 1694 all such issues within this section will be considered part of 1695 Consensus Item #13a with a single revised treatment addressing all 1696 the issues noted. 1698 [Previous Treatment]: A server need not support any of these flags. 1700 [Author Aside]: It is hard to understand why such broad license is 1701 granted to the server, leaving the client to deal, without an 1702 explicit non-support indication, with 256 possible combinations of 1703 supported and unsupported flags. If there were specific issues with 1704 some flags that makes it reasonable for a server not to support them, 1705 then these need to be specifically noted. Also problematic is the 1706 use of the term "need not", suggesting that the server does not need 1707 any justification for choosing these flags, defined by the protocol. 1708 At least it needs to be said that the server SHOULD support the 1709 defined ACE flags. After all they were included in the protocol for 1710 a reason. 1712 [Previous Treatment]: If the server supports flags that are similar 1713 to, but not exactly the same as, these flags, the implementation may 1714 define a mapping between the protocol-defined flags and the 1715 implementation-defined flags. 1717 [Author Aside]: The above dealing how an implementation might store 1718 the bits it support, while valid, is out-of-scope and should be 1719 deleted. 1721 [Previous Treatment]: For example, suppose a client tries to set an 1722 ACE with ACE4_FILE_INHERIT_ACE set but not 1723 ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form 1724 of ACL inheritance, the server should reject the request with 1725 NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE" 1726 flag that applies to both files and directories, the server may 1727 reject the request (i.e., requiring the client to set both the file 1728 and directory inheritance flags). The server may also accept the 1729 request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag. 1731 ]Author Aside]: What is the possible for justification for accepting 1732 a request asking you do something and then, without notice to the 1733 client do, something else. I believe there is none. 1735 Consensus Needed (Item #13a)]: Servers SHOULD support the flag bits 1736 defined above as described in Section 5.8. When a server which does 1737 not support all the flags bits receives a request to set an ACL 1738 containing an ACE with an unsupported flag bit set the server MUST 1739 reject the request with NFS4ERR_ATTRNOTSUPP. 1741 Consensus Needed (Item #13a)]: The case of servers which do not 1742 provide support for particular flag combinations is to be treated 1743 similarly. If a server supports a single "inherit ACE" flag that 1744 applies to both files and directories, receives a request set an ACL 1745 with ACE ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE not 1746 set, it MUST reject the request with NFS4ERR_ATTRNOTSUPP. 1748 5.8. Details Regarding ACE Flag Bits 1750 ACE4_FILE_INHERIT_ACE 1751 Any non-directory file in any sub-directory will get this ACE 1752 inherited. 1754 ACE4_DIRECTORY_INHERIT_ACE 1755 Can be placed on a directory and indicates that this ACE should be 1756 added to each new directory created. 1758 If this flag is set in an ACE in an ACL attribute to be set on a 1759 non-directory file system object, the operation attempting to set 1760 the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP. 1762 ACE4_NO_PROPAGATE_INHERIT_ACE 1763 Can be placed on a directory. This flag tells the server that 1764 inheritance of this ACE should stop at newly created child 1765 directories. 1767 ACE4_INHERIT_ONLY_ACE 1768 Can be placed on a directory but does not apply to the directory; 1769 ALLOW and DENY ACEs with this bit set do not affect access to the 1770 directory, and AUDIT and ALARM ACEs with this bit set do not 1771 trigger log or alarm events. Such ACEs only take effect once they 1772 are applied (with this bit cleared) to newly created files and 1773 directories as specified by the ACE4_FILE_INHERIT_ACE and 1774 ACE4_DIRECTORY_INHERIT_ACE flags. 1776 If this flag is present on an ACE, but neither 1777 ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, 1778 then an operation attempting to set such an attribute SHOULD fail 1779 with NFS4ERR_ATTRNOTSUPP. 1781 ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG 1782 The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and 1783 ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on 1784 ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE 1785 (ALARM) ACE types. If during the processing of the file's ACL, 1786 the server encounters an AUDIT or ALARM ACE that matches the 1787 principal attempting the OPEN, the server notes that fact, and the 1788 presence, if any, of the SUCCESS and FAILED flags encountered in 1789 the AUDIT or ALARM ACE. Once the server completes the ACL 1790 processing, it then notes if the operation succeeded or failed. 1791 If the operation succeeded, and if the SUCCESS flag was set for a 1792 matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM 1793 event occurs. If the operation failed, and if the FAILED flag was 1794 set for the matching AUDIT or ALARM ACE, then the appropriate 1795 AUDIT or ALARM event occurs. Either or both of the SUCCESS or 1796 FAILED can be set, but if neither is set, the AUDIT or ALARM ACE 1797 is not useful. 1799 The previously described processing applies to ACCESS operations 1800 even when they return NFS4_OK. For the purposes of AUDIT and 1801 ALARM, we consider an ACCESS operation to be a "failure" if it 1802 fails to return a bit that was requested and supported. 1804 ACE4_IDENTIFIER_GROUP 1805 Indicates that the "who" refers to a GROUP as defined under UNIX 1806 or a GROUP ACCOUNT as defined under Windows. Clients and servers 1807 MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who 1808 value equal to one of the special identifiers outlined in 1809 Section 5.9. 1811 ACE4_INHERITED_ACE 1812 Indicates that this ACE is inherited from a parent directory. A 1813 server that supports automatic inheritance will place this flag on 1814 any ACEs inherited from the parent directory when creating a new 1815 object. Client applications will use this to perform automatic 1816 inheritance. Clients and servers MUST clear this bit in the acl 1817 attribute; it may only be used in the dacl and sacl attributes. 1819 5.9. ACE Who 1821 The "who" field of an ACE is an identifier that specifies the 1822 principal or principals to whom the ACE applies. It may refer to a 1823 user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying 1824 which. 1826 There are several special identifiers that need to be understood 1827 universally, rather than in the context of a particular DNS domain. 1828 Some of these identifiers cannot be understood when an NFS client 1829 accesses the server, but have meaning when a local process accesses 1830 the file. The ability to display and modify these permissions is 1831 permitted over NFS, even if none of the access methods on the server 1832 understands the identifiers. 1834 +===============+==================================================+ 1835 | Who | Description | 1836 +===============+==================================================+ 1837 | OWNER | The owner of the file. | 1838 +---------------+--------------------------------------------------+ 1839 | GROUP | The group associated with the file. | 1840 +---------------+--------------------------------------------------+ 1841 | EVERYONE | The world, including the owner and owning group. | 1842 +---------------+--------------------------------------------------+ 1843 | INTERACTIVE | Accessed from an interactive terminal. | 1844 +---------------+--------------------------------------------------+ 1845 | NETWORK | Accessed via the network. | 1846 +---------------+--------------------------------------------------+ 1847 | DIALUP | Accessed as a dialup user to the server. | 1848 +---------------+--------------------------------------------------+ 1849 | BATCH | Accessed from a batch job. | 1850 +---------------+--------------------------------------------------+ 1851 | ANONYMOUS | Accessed without any authentication. | 1852 +---------------+--------------------------------------------------+ 1853 | AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). | 1854 +---------------+--------------------------------------------------+ 1855 | SERVICE | Access from a system service. | 1856 +---------------+--------------------------------------------------+ 1858 Table 2 1860 To avoid conflict, these special identifiers are distinguished by an 1861 appended "@" and should appear in the form "xxxx@" (with no domain 1862 name after the "@"), for example, ANONYMOUS@. 1864 The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these 1865 special identifiers. When encoding entries with these special 1866 identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. 1868 [working group input needed]: I don't understand what might be valid 1869 reasons to ignore this. Would "MUST" be appropriate here? 1871 It is important to note that "EVERYONE@" is not equivalent to the 1872 UNIX "other" entity. This is because, by definition, UNIX "other" 1873 does not include the owner or owning group of a file. "EVERYONE@" 1874 means literally everyone, including the owner or owning group. 1876 [working group input needed]: Some of these require that changes be 1877 made as discussed below: 1879 * For "INTERACTIVE", "NETWORK", "DIALUP", "BATCH", and "SERVICE" it 1880 needs to be specified that server's ability to make these 1881 distinctions is limited, making their use where security is an 1882 issue quite problematic. 1884 * For "ANONYMOUS", clearly requests using AUTH_NONE fit but what 1885 else? 1887 Request by nobody and by users root-squashed to nobody are 1888 probably OK, although you could argue about the case of a user 1889 "nobody" authenticated by RPCSEC_GSS. 1891 ON a more contentious note, I would argue that users 1892 "authenticated" using AUTH_SYS, in the clear, without client-peer 1893 authentication fit here, but we need to get to consensus on this 1894 point. 1896 * Issues regarding "AUTHENTICATED" will be the mirror image of those 1897 for "ANONYMOUS". 1899 5.10. Automatic Inheritance Features 1901 The acl attribute consists only of an array of ACEs, but the sacl 1902 (Section 12.1) and dacl (Section 7.4.2) attributes also include an 1903 additional flag field. 1905 struct nfsacl41 { 1906 aclflag4 na41_flag; 1907 nfsace4 na41_aces<>; 1908 }; 1910 The flag field applies to the entire sacl or dacl; three flag values 1911 are defined: 1913 const ACL4_AUTO_INHERIT = 0x00000001; 1914 const ACL4_PROTECTED = 0x00000002; 1915 const ACL4_DEFAULTED = 0x00000004; 1916 and all other bits must be cleared. The ACE4_INHERITED_ACE flag may 1917 be set in the ACEs of the sacl or dacl (whereas it must always be 1918 cleared in the acl). 1920 Together these features allow a server to support automatic 1921 inheritance, which we now explain in more detail. 1923 Inheritable ACEs are normally inherited by child objects only at the 1924 time that the child objects are created; later modifications to 1925 inheritable ACEs do not result in modifications to inherited ACEs on 1926 descendants. 1928 However, the dacl and sacl provide an OPTIONAL mechanism that allows 1929 a client application to propagate changes to inheritable ACEs to an 1930 entire directory hierarchy. 1932 A server that supports this feature performs inheritance at object 1933 creation time in the normal way, and SHOULD set the 1934 ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to 1935 the new object. 1937 A client application such as an ACL editor may then propagate changes 1938 to inheritable ACEs on a directory by recursively traversing that 1939 directory's descendants and modifying each ACL encountered to remove 1940 any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the 1941 new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It 1942 uses the existing ACE inheritance flags in the obvious way to decide 1943 which ACEs to propagate. (Note that it may encounter further 1944 inheritable ACEs when descending the directory hierarchy and that 1945 those will also need to be taken into account when propagating 1946 inheritable ACEs to further descendants.) 1948 The reach of this propagation may be limited in two ways: first, 1949 automatic inheritance is not performed from any directory ACL that 1950 has the ACL4_AUTO_INHERIT flag cleared; and second, automatic 1951 inheritance stops wherever an ACL with the ACL4_PROTECTED flag is 1952 set, preventing modification of that ACL and also (if the ACL is set 1953 on a directory) of the ACL on any of the object's descendants. 1955 This propagation is performed independently for the sacl and the dacl 1956 attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may 1957 be independently set for the sacl and the dacl, and propagation of 1958 one type of acl may continue down a hierarchy even where propagation 1959 of the other acl has stopped. 1961 New objects should be created with a dacl and a sacl that both have 1962 the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to 1963 the same value as that on, respectively, the sacl or dacl of the 1964 parent object. 1966 Both the dacl and sacl attributes are Recommended, and a server may 1967 support one without supporting the other. 1969 A server that supports both the old acl attribute and one or both of 1970 the new dacl or sacl attributes must do so in such a way as to keep 1971 all three attributes consistent with each other. Thus, the ACEs 1972 reported in the acl attribute should be the union of the ACEs 1973 reported in the dacl and sacl attributes, except that the 1974 ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl. 1975 And of course a client that queries only the acl will be unable to 1976 determine the values of the sacl or dacl flag fields. 1978 When a client performs a SETATTR for the acl attribute, the server 1979 SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the 1980 dacl. By using the acl attribute, as opposed to the dacl or sacl 1981 attributes, the client signals that it may not understand automatic 1982 inheritance, and thus cannot be trusted to set an ACL for which 1983 automatic inheritance would make sense. 1985 When a client application queries an ACL, modifies it, and sets it 1986 again, it should leave any ACEs marked with ACE4_INHERITED_ACE 1987 unchanged, in their original order, at the end of the ACL. If the 1988 application is unable to do this, it should set the ACL4_PROTECTED 1989 flag. This behavior is not enforced by servers, but violations of 1990 this rule may lead to unexpected results when applications perform 1991 automatic inheritance. 1993 If a server also supports the mode attribute, it SHOULD set the mode 1994 in such a way that leaves inherited ACEs unchanged, in their original 1995 order, at the end of the ACL. If it is unable to do so, it SHOULD 1996 set the ACL4_PROTECTED flag on the file's dacl. 1998 Finally, in the case where the request that creates a new file or 1999 directory does not also set permissions for that file or directory, 2000 and there are also no ACEs to inherit from the parent's directory, 2001 then the server's choice of ACL for the new object is implementation- 2002 dependent. In this case, the server SHOULD set the ACL4_DEFAULTED 2003 flag on the ACL it chooses for the new object. An application 2004 performing automatic inheritance takes the ACL4_DEFAULTED flag as a 2005 sign that the ACL should be completely replaced by one generated 2006 using the automatic inheritance rules. 2008 5.11. Attribute 13: aclsupport 2010 A server need not support all of the above ACE types. This attribute 2011 indicates which ACE types are supported for the current file system. 2012 The bit mask constants used to represent the above definitions within 2013 the aclsupport attribute are as follows: 2015 const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; 2016 const ACL4_SUPPORT_DENY_ACL = 0x00000002; 2017 const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; 2018 const ACL4_SUPPORT_ALARM_ACL = 0x00000008; 2020 [Author Aside]: Even though support aclsupport is OPTIONAL, there has 2021 been no mention of the possibility of it not being supported. 2023 [Consensus Needed (Item #14a)]: If this attribute is not supported 2024 for a server, the client is entitled to assume that if the acl 2025 attribute is supported, support for ALLOW and DENY ACEs is present. 2026 Thus, if such a server supports the the sacl attribute, clients are 2027 not likely to use it if aclsupport is not supported by the server. 2029 [Previous Treatment]: Servers that support either the ALLOW or DENY 2030 ACE type SHOULD support both ALLOW and DENY ACE types. 2032 [Author Aside]: It needs to be made clearer what the harm is that is 2033 to be prevented by this. Further if such harm exists, it is not 2034 clear what are the valid reasons not do this? 2036 [Consensus Needed (Item #15a)]: There is little point in implementing 2037 a server which supports either ALLOW or DENY ACE types without 2038 supporting both. For reasons explained in Section 7.1 the ACL_based 2039 authorization cannot be used if only a single ACE type is available. 2041 Clients should not attempt to set an ACE unless the server claims 2042 support for that ACE type. If the server receives a request to set 2043 an ACE that it cannot store, it MUST reject the request with 2044 NFS4ERR_ATTRNOTSUPP. 2046 [Previous Treatment (Item #12c)]: If the server receives a request to 2047 set an ACE that it can store but cannot enforce, the server SHOULD 2048 reject the request with NFS4ERR_ATTRNOTSUPP. 2050 [Author Aside]: Beyond the issues with the use of SHOULD, it is 2051 better to centralize this material and be clearer about the whole 2052 issue of ACL enforcement. 2054 [Consensus Needed (Item #12c)]: The case of ACEs that cannot be 2055 enforced is similar, with the details of enforcement discussed in 2056 Section 5.5. 2058 Support for any of the ACL attributes is OPTIONAL, although 2059 Recommended. However, a server (NFSv4.1 and above) that supports 2060 either of the new ACL attributes (dacl or sacl) MUST allow use of the 2061 new ACL attributes to access all of the ACE types that it supports. 2062 In other words, if a server which supports sacl or dacl supports 2063 ALLOW or DENY ACEs, then it MUST support the dacl attribute, and if 2064 it supports AUDIT or ALARM ACEs, then it MUST support the sacl 2065 attribute. 2067 5.12. Attribute 12: acl 2069 The acl attribute, as opposed to the sacl and dacl attributes, 2070 consists only of an ACE array and does not support automatic 2071 inheritance. 2073 The acl attribute is recommended and there is no requirement that a 2074 server support it. However, when the dacl attribute is supported, it 2075 is a good idea to provide support for the acl attribute as well, in 2076 order to accommodate clients that have not been upgraded to use the 2077 dacl attribute. 2079 [Author Aside]: Although it has generally been assumed that changes 2080 to sacl and dacl attributes are to be visible in the acl and vice 2081 versa, NFSv4.1 specification do not appear to document this fact. 2083 [Consensus Item, Including List (Item #16a)]: For NFSv4.1 servers 2084 that support Both the acl attribute and one or more of the sacl and 2085 dacl attributes, changes to the ACE's need to be immediately 2086 reflected in the other supported attributes: 2088 * The result of reading the dacl attribute MUST consist of a set of 2089 ACEs that are exactly the same as the ACEs ALLOW and DENY ACEs 2090 within the the acl attribute, in the same order. 2092 * The result of reading the sacl attribute MUST consist of a set of 2093 ACEs that are exactly the same as the ACEs AUDIT and ALARM ACEs 2094 within the the acl attribute, in the same order. 2096 * The result of reading the acl attribute MUST consist of a set of 2097 ACEs that are exactly the same as the union of ACEs within the 2098 sacl and dacl attributes. Two ACEs that both appear in one of the 2099 sacl or dacl attributes must appear in the same order in the acl 2100 attribute. 2102 6. Authorization in General 2104 There are three distinct methods of checking whether NFSv4 requests 2105 are authorized: 2107 * The most important method of authorization is used to effect user- 2108 based file access control, as described in Section 7. 2110 This requires the identification of the user making the request. 2111 Because of the central role of such access control in providing 2112 NFSv4 security, server implementations SHOULD NOT use such 2113 identifications when they are not authenticated. In this context, 2114 valid reasons to do otherwise are limited to the compatibility and 2115 maturity issues discussed in Section 17.1.4 2117 * NFSv4.2, via the labelled NFS feature, provides an additional 2118 potential requirement for request authorization. 2120 For reasons made clear in Section 10, there is no realistic 2121 possibility of the server using the data defined by existing 2122 specifications of this feature to effect request authorization. 2123 While it is possible for clients to provide this authorization, 2124 the lack of detailed specifications makes it impossible to 2125 determine the nature of the identification used and whether it can 2126 appropriately be described as "authentication". 2128 * Since undesired changes to server-maintained locking state (and, 2129 for NFSv4.1, session state) can result in denial of service 2130 attacks (see Section 17.6), server implementations SHOULD take 2131 steps to prevent unauthorized state changes. This can be done by 2132 implementing the state authorization restrictions discussed in 2133 Section 11 2135 7. User-based File Access Authorization 2137 7.1. Attributes for User-based File Access Authorization 2139 NFSv4.1 provides for multiple authentication models, controlled by 2140 the support for particular recommended attributes implemented by the 2141 server, as discussed below: 2143 * Consensus Needed (Item #18a)]: The attributes owner, owning_group, 2144 and mode enable use of a POSIX-based authorization model, as 2145 described in Section 7.3. When all of these attributes are 2146 supported, this authorization model can be implemented. 2148 Consensus Needed (Item #18a)]:When none of these attributes or 2149 only a proper subset of them are supported, this authorization 2150 model is unavailable. 2152 * [Consensus Needed (Item #17a)]: The acl attribute (or the 2153 attribute dacl in NFSv4.1) can provide an ACL-based authorization 2154 model as described in Section 7.4 as long as support for ALLOW and 2155 DENY ACEs is provided. 2157 [Consensus Needed (Items #17a, #18a)]: When some of these ACE 2158 types are not supported or the owner or owning_group attribute is 2159 not supported, this authorization model is unavailable, since 2160 there are some modes that cannot be represented as corresponding 2161 ACL, when using only a single ACE type. See Section 9.2 for 2162 details. 2164 7.2. Handling of Multiple Parallel File Access Authorization Models 2166 ACLs and modes represent two well-established models for specifying 2167 user-based file access permissions. NFSv4 provides support for 2168 either or both depending on the attributes supported by the server 2169 and, in cases in which both ACLs and the mode attribute are 2170 supported, the actual attributes set for a particular object. 2172 * [Consensus Needed (item #18b)]: When the attributes mode, owner, 2173 owner group are all supported, the posix-based authorization 2174 model, described in Section 7.3 can be used. 2176 * [Consensus Needed (Items #17b, #18b)]: When the acl (or dacl) 2177 attribute is supported together with both of the ACE types ALLOW 2178 and DENY, the acl based authorization model, described in 2179 Section 7.4 can be used as long as the attributes owner and 2180 owner_group are also supported. 2182 [Consensus Needed (item #18b)]: While formally recommended 2183 (essentially OPTIONAL) attributes, it appears that the owner and 2184 owner_group attributes need to be available to support any file 2185 access authorization model. As a result, this document will not 2186 discuss the possibility of servers that do not support both of these 2187 attributes and clients have no need to support such servers. 2189 When both authorization models can be used, there are difficulties 2190 that can arise because the ACL-based model provides finer-grained 2191 access control than the POSIX model. The ways of dealing with these 2192 difficulties appear later in this section while more detail on the 2193 appropriate handling of this situation, which might depend on the 2194 minor version used, appears in Section 9. 2196 The following describe NFSv4's handling in supporting multiple 2197 authorization models for file access. 2199 * If a server supports the mode attribute, it should provide the 2200 appropriate POSIX semantics if no ACL-based attributes have ever 2201 been assigned to object. These semantics include the restriction 2202 of the ability to modify the mode, owner and owner-group to the 2203 current owner of the file. 2205 * If a server supports ACL attributes, it should provide ACL 2206 semantics as described in this document for all objects for which 2207 the ACL attributes have actually been set. This includes the ACL- 2208 based restrictions on the authorization to modify the mode, owner 2209 and owner_group attributes. 2211 * On servers that support the mode attribute, if ACL attributes have 2212 never been set on an object, via inheritance or explicitly, the 2213 behavior should be the behavior mandated by POSIX, including the 2214 those that restrict the setting of authorization-related 2215 attributes. 2217 * On servers that support the mode attribute, if the ACL attributes 2218 have been previously set on an object, either explicitly or via 2219 inheritance: 2221 - [Previous Treatment]: Setting only the mode attribute should 2222 effectively control the traditional UNIX-like permissions of 2223 read, write, and execute on owner, owner_group, and other. 2225 [Author Aside]: It isn't really clear what the above paragraph 2226 means, especially as it governs the handling of aces 2227 designating specific users and groups which are not the owner 2228 and have no overlap with the owning group 2230 {Consensus Needed (Item #19a)]: Setting only the mode 2231 attribute, should result in the access of the file being 2232 controlled just it would be if the existing acl did not exist, 2233 with file access decisions as to read made in accordance with 2234 the mode set. The ALLOW and DENY aces in the ACL should 2235 reflect the modified security although there is no need to 2236 modify AUDIT and ALARM aces or mask bits not affected by the 2237 mode bits, such as SYNCHRONIZE. 2239 [Author Aside]: the above may need to modified to reflect the 2240 resolution of Consensus Item #??. 2242 - [Previous Treatment]: Setting only the mode attribute should 2243 provide reasonable security. For example, setting a mode of 2244 000 should be enough to ensure that future OPEN operations for 2245 OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any 2246 principal fail, regardless of a previously existing or 2247 inherited ACL. 2249 [Author Aside]: We need to get rid of or provide some some 2250 replacement for the subjective first sentence. While the 2251 specific example give is unexceptionable, it raises questions 2252 in other cases as to what would constitutes "reasonable 2253 semantics". While the resolution of such questions would be 2254 subject to dispute, the author believes that consensus item 2255 #19a deals with the matter adequately. As a result he 2256 proposes, that the that this bullet be removed and the second- 2257 level list collapsed to single paragraph. 2259 * Although RFCs 7530 and 8881 present different descriptions of the 2260 specific semantic requirements relating to the interaction of mode 2261 and ACL attributes, the difference are quite small, with the most 2262 important ones deriving from the absence of the set_mode_masked 2263 attribute. The unified treatment in Section 9 will indicate where 2264 version-specific differences exist. 2266 7.3. Posix Authorization Model 2268 7.3.1. Attribute 33: mode 2270 The NFSv4.1 mode attribute is based on the UNIX mode bits. The 2271 following bits are defined: 2273 const MODE4_SUID = 0x800; /* set user id on execution */ 2274 const MODE4_SGID = 0x400; /* set group id on execution */ 2275 const MODE4_SVTX = 0x200; /* save text even after use */ 2276 const MODE4_RUSR = 0x100; /* read permission: owner */ 2277 const MODE4_WUSR = 0x080; /* write permission: owner */ 2278 const MODE4_XUSR = 0x040; /* execute permission: owner */ 2279 const MODE4_RGRP = 0x020; /* read permission: group */ 2280 const MODE4_WGRP = 0x010; /* write permission: group */ 2281 const MODE4_XGRP = 0x008; /* execute permission: group */ 2282 const MODE4_ROTH = 0x004; /* read permission: other */ 2283 const MODE4_WOTH = 0x002; /* write permission: other */ 2284 const MODE4_XOTH = 0x001; /* execute permission: other */ 2286 Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal 2287 identified by the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and 2288 MODE4_XGRP apply to principals belonging to the group identified in 2289 the owner_group attribute but who are not identified by the owner 2290 attribute. Bits MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any 2291 principal that does not match that in the owner attribute and does 2292 not belong to a group matching that of the owner_group attribute. 2293 These nine bits are used in providing authorization information. 2295 [Previous Treatment]: The bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX 2296 do not provide authorization information and do not affect server 2297 behavior. Instead, they are acted on by the client just as they 2298 would be for corresponding mode bits obtained from local file 2299 systems. 2301 [Consensus needed (Item #6c)]: For objects which are not directories, 2302 the bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX do not provide 2303 authorization information and do not affect server behavior. 2304 Instead, they are acted on by the client just as they would be for 2305 corresponding mode bits obtained from local file systems. 2307 [Consensus needed (Item #6c)]: For directories, the bits MODE4_SUID 2308 and MODE4_SGID, do not provide authorization information and do not 2309 affect server behavior. Instead, they are acted on by the client 2310 just as they would be for corresponding mode bits obtained from local 2311 file systems. The mode bit MODE_SVTX does have an authorization- 2312 related role as described later in this section 2314 [Consensus Needed, Including List (Item #6c]): When handling RENAME 2315 and REMOVE operations the check for authorization depends on the 2316 setting of MODE_SVTX for the directory. 2318 * When MODE_SVTX is not set on the directory, authorization requires 2319 write permission on both the file being renamed and the source 2320 directory. 2322 * When MODE_SVTX is not on the directory, authorization requires, in 2323 addition that the requesting principal be the owner of the file to 2324 be named or removed. 2326 [Consensus needed (Item #6c)]: It should be noted that this approach 2327 is similar to ACL-based approach documented in Section 5.6. However 2328 there are some semantics differences whose motivation remains unclear 2329 and the specification does not mention RENAME, as it should. 2331 [Author Aside]: Bringing the above into more alignment with the ACL- 2332 based semantics is certainly desirable but the necessary work has not 2333 been done yet. For tracking purposes, that realignment will be 2334 considered Consensus Item #20. 2336 Bits within a mode other than those specified above are not defined 2337 by this protocol. A server MUST NOT return bits other than those 2338 defined above in a GETATTR or READDIR operation, and it MUST return 2339 NFS4ERR_INVAL if bits other than those defined above are set in a 2340 SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation. 2342 [Consensus Needed (Item #21a)]: In the typical case, the nine low- 2343 order bits are set such that each successive set of three bits is a 2344 subset, not necessarily proper, of the previous three bits. Such 2345 modes are described as forward-slope nodes because the privilege 2346 level goes downward as you proceed forward. There are, however, 2347 cases in which there is an increase of privilege going from owner to 2348 group or from group to owner. Such modes are considered reverse- 2349 slope modes. As will be seen in Sections 9.3 and 9.6, many 2350 straightforward ways of dealing with mode that work well with 2351 forward-slope modes need adjustment to properly deal with reverse- 2352 slope modes. 2354 7.3.2. NFSv4.1 Attribute 74: mode_set_masked 2356 The mode_set_masked attribute is a write-only attribute that allows 2357 individual bits in the mode attribute to be set or reset, without 2358 changing others. It allows, for example, the bits MODE4_SUID, 2359 MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified 2360 any of the nine low-order mode bits devoted to permissions. 2362 When minor versions other than NFSv4.0 are used, instances of use of 2363 the set_mode_masked attribute such that none of the nine low-order 2364 bits are subject to modification, then neither the acl nor the dacl 2365 attribute should be automatically modified as discussed in Sections 2366 9.6 and 9.8. 2368 The mode_set_masked attribute consists of two words, each in the form 2369 of a mode4. The first consists of the value to be applied to the 2370 current mode value and the second is a mask. Only bits set to one in 2371 the mask word are changed (set or reset) in the file's mode. All 2372 other bits in the mode remain unchanged. Bits in the first word that 2373 correspond to bits that are zero in the mask are ignored, except that 2374 undefined bits are checked for validity and can result in 2375 NFS4ERR_INVAL as described below. 2377 The mode_set_masked attribute is only valid in a SETATTR operation. 2378 If it is used in a CREATE or OPEN operation, the server MUST return 2379 NFS4ERR_INVAL. 2381 Bits not defined as valid in the mode attribute are not valid in 2382 either word of the mode_set_masked attribute. The server MUST return 2383 NFS4ERR_INVAL if any such bits are set to one in a SETATTR. If the 2384 mode and mode_set_masked attributes are both specified in the same 2385 SETATTR, the server MUST also return NFS4ERR_INVAL. 2387 7.4. ACL-based Authorization Model 2389 7.4.1. Processing Access Control Entries 2391 To determine if a request succeeds, the server processes each nfsace4 2392 entry of type ALLOW or DENY in turn as ordered in the array. Only 2393 ACEs that have a "who" that matches the requester are considered. An 2394 ACE is considered to match a given requester if at least one of the 2395 following is true: 2397 * The "who' designates a specific user which is the user making the 2398 request. 2400 * The "who" specifies "OWNER@" and the user making the request is 2401 the owner of the file. 2403 * The "who" designates a specific group and the user making the 2404 request is a member of that group. 2406 * The "who" specifies "GROUP@" and the user making the request is a 2407 member of the group owning the file. 2409 * The "who" specifies "EVERYONE@". 2411 * The "who" specifies "INTERACTIVE@", "NETWORK@", "DIALUP@", 2412 "BATCH@", or "SERVICE@" and the requester, in the judgment of the 2413 server, feels that designation appropriately describes the 2414 requester. 2416 * The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the 2417 requestor's authentication status matches the who, using the 2418 definitions in Section 5.9 2420 Each ACE is processed until all of the bits of the requester's access 2421 have been ALLOWED. Once a bit (see below) has been ALLOWED by an 2422 ACCESS_ALLOWED_ACE, it is no longer considered in the processing of 2423 later ACEs. If an ACCESS_DENIED_ACE is encountered where the 2424 requester's access still has unALLOWED bits in common with the 2425 "access_mask" of the ACE, the request is denied. When the ACL is 2426 fully processed, if there are bits in the requester's mask that have 2427 not been ALLOWED or DENIED, access is denied. 2429 Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do 2430 not affect a requester's access, and instead are for triggering 2431 events as a result of a requester's access attempt. AUDIT and ALARM 2432 ACEs are processed only after processing ALLOW and DENY ACEs if any 2433 exist. This is necessary since the handling of AUDIT and ALARM ACEs 2434 are affected by whether the access attempt is successful. 2436 [Previous Treatment]: The NFSv4.1 ACL model is quite rich. Some 2437 server platforms may provide access-control functionality that goes 2438 beyond the UNIX-style mode attribute, but that is not as rich as the 2439 NFS ACL model. So that users can take advantage of this more limited 2440 functionality, the server may support the acl attributes by mapping 2441 between its ACL model and the NFSv4.1 ACL model. Servers must ensure 2442 that the ACL they actually store or enforce is at least as strict as 2443 the NFSv4 ACL that was set. It is tempting to accomplish this by 2444 rejecting any ACL that falls outside the small set that can be 2445 represented accurately. However, such an approach can render ACLs 2446 unusable without special client-side knowledge of the server's 2447 mapping, which defeats the purpose of having a common NFSv4 ACL 2448 protocol. Therefore, servers should accept every ACL that they can 2449 without compromising security. To help accomplish this, servers may 2450 make a special exception, in the case of unsupported permission bits, 2451 to the rule that bits not ALLOWED or DENIED by an ACL must be denied. 2452 For example, a UNIX-style server might choose to silently allow read 2453 attribute permissions even though an ACL does not explicitly allow 2454 those permissions. (An ACL that explicitly denies permission to read 2455 attributes should still be rejected.) 2457 [Author Aside]: While the NFSv4.1 provides that many might not need 2458 or use, it is the one that the working group adopted by the working 2459 group, and I have to assume that alternatives, such as the withdrawn 2460 POSIX ACL proposal were considered but not adopted. The phrase 2461 "unsupported permission bits" with no definition of the bit whose 2462 support might be dispensed with, implies that the server is free to 2463 support whatever subset of these bits it chooses. As a result, 2464 clients would not be able to rely on a functioning server 2465 implementation of this OPTIONAL attribute. If there are specific 2466 compatibility issues that make it necessary to allow non-support of 2467 specific mask bits, then these need to be limited and the client 2468 needs guidance about determining the set of unsupported mask bits. 2470 [Previous Treatment]: The situation is complicated by the fact that a 2471 server may have multiple modules that enforce ACLs. For example, the 2472 enforcement for NFSv4.1 access may be different from, but not weaker 2473 than, the enforcement for local access, and both may be different 2474 from the enforcement for access through other protocols such as SMB 2475 (Server Message Block). So it may be useful for a server to accept 2476 an ACL even if not all of its modules are able to support it. 2478 [Author Aside]: The following paragraph does not provide helpful 2479 guidance and takes no account of the need of the the client to be 2480 able to rely on the server implementing protocol-specifying semantics 2481 and giving notice in those cases in which it is unable to so 2483 [Previous Treatment]: The guiding principle with regard to NFSv4 2484 access is that the server must not accept ACLs that appear to make 2485 access to the file more restrictive than it really is. 2487 7.4.2. V4.1 Attribute 58: dacl 2489 The dacl attribute is like the acl attribute, but dacl allows only 2490 ALLOW and DENY ACEs. The dacl attribute supports automatic 2491 inheritance (see Section 5.10). 2493 8. Common Considerations for Both File access Models 2495 [Author Aside, Including List]: This subsections within this section 2496 are derived from Section 6.3 of 8881, entitled "Common Methods. 2497 However, its content is different because it has been rewritten to 2498 deal with issues common to both file access models, which now appears 2499 to have not been the original intention. Nevertheless, the following 2500 changes have been made: 2502 * The section "Server Considerations" has been revised to deal with 2503 both the mode and acl attributes, since the points being made 2504 apply, in almost all cases, to both attributes. 2506 * The section "Client Considerations" has been heavily revised, 2507 since what had been there did not make any sense to me. 2509 * The section "Computing a Mode Attribute from an ACL" has been 2510 moved to Section 9.3 since it deals with the co-ordination of the 2511 posix and acl authorization models. 2513 8.1. Server Considerations 2515 The server uses the mode attribute or the acl attribute applying the 2516 algorithm described in Section 7.4.1 to determine whether an ACL 2517 allows access to an object. 2519 [Author Aside, Including List]: The list previously in this section 2520 (now described as "Previous Treatment" combines two related issues in 2521 a way which obscures the very different security-related consequences 2522 of two distinct issues: 2524 * In some cases an operation will be authorized but is not allowed 2525 for reasons unrelated to authorization. 2527 This has no negative effect on security. 2529 * The converse case does have troubling effects on security which 2530 are mentioned in this section and discussed in more detail in 2531 Section 17 2533 [Author Aside, Including List]: The items in that list have been 2534 dealt with as follows: 2536 * The first and sixth items fit under the first (i.e. less 2537 troublesome) of these issues. They have have been transferred 2538 into an appropriate replacement list. 2540 * The third item is to be deleted since it does not manifest either 2541 of these issues. In fact, it refers to the semantics already 2542 described in Section 5.4. is already described in ... 2544 * The second, fourth and fifth items need to be addressed in a new 2545 list dealing with the potentially troublesome issues arising from 2546 occasions in which the access semantics previously described are 2547 relaxed, for various reasons. 2549 Included are cases in which previous specifications explicitly 2550 allowed this by using the term "MAY" and others in which the 2551 existence of servers manifesting such behavior was reported, with 2552 the implication that clients need to prepared for such behavior. 2554 [Previous Treatment, Including List (Item #22a)]: However, these 2555 attributes might not be the sole determiner of access. For example: 2557 * In the case of a file system exported as read-only, the server 2558 will deny write access even though an object's file access 2559 attributes would grant it. 2561 * Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL 2562 permissions to prevent a situation from arising in which there is 2563 no valid way to ever modify the ACL. 2565 * All servers will allow a user the ability to read the data of the 2566 file when only the execute permission is granted (e.g., if the ACL 2567 denies the user the ACE4_READ_DATA access and allows the user 2568 ACE4_EXECUTE, the server will allow the user to read the data of 2569 the file). 2571 * Many servers implement owner-override semantics in which the owner 2572 of the object is allowed to override accesses that are denied by 2573 the ACL. This may be helpful, for example, to allow users 2574 continued access to open files on which the permissions have 2575 changed. 2577 * Many servers provide for the existence of a "superuser" that has 2578 privileges beyond an ordinary user. The superuser may be able to 2579 read or write data or metadata in ways that would not be permitted 2580 by the ACL or mode attributes. 2582 * A retention attribute might also block access otherwise allowed by 2583 ACLs (see Section 5.13 of [8]). 2585 [Consensus Needed, Including List (Item #22a)]: It should be noted 2586 that, even when an operation is authorized, it may be denied for 2587 reasons unrelated to authorization. For example: 2589 * In the case of a file system exported as read-only, the server 2590 will deny write access even though an object's file access 2591 attributes would authorize it. 2593 * A retention attribute might also block access otherwise allowed by 2594 ACLs (see Section 5.13 of [8]). 2596 [Consensus Needed, (Item #22a)]: There are also cases in which the 2597 converse issue arises, so that an operation which is not authorized 2598 as specified by the mode and ACL attributes is, nevertheless, 2599 executed as if it were authorized. Because previous NFSv4 2600 specifications have cited the cases listed below without reference to 2601 the security problems that they create, it is necessary to discuss 2602 them here to provide clarification of the security implications of 2603 following this guidance, which is now superseded. These cases are 2604 listed below and discussed in more detail in Section 17.1.3. 2606 [Consensus Needed, Including List (Item #22a)]: In the following 2607 list, the treatment used in RFC8881 is quoted, while the 2608 corresponding text in RFC7530 is essentially identical. 2610 * RFC8881 contains the following, which is now superseded: 2612 Server implementations MAY grant ACE4_WRITE_ACL and 2613 ACE4_READ_ACL permissions to prevent a situation from arising 2614 in which there is no valid way to ever modify the ACL. 2616 While, as a practical matter, there do need to be provisions to 2617 deal with this issue, the "MAY" above is too broad,in that it 2618 describes the motivation without any limits providing appropriate 2619 restriction on the step that might be taken to deal with the 2620 issue. See Section 17.1.3 for the updated treatment of this 2621 issue. 2623 * RFC8881 contains the following, which is now superseded: 2625 Many servers implement owner-override semantics in which the 2626 owner of the object is allowed to override accesses that are 2627 denied by the ACL. This may be helpful, for example, to allow 2628 users continued access to open files on which the permissions 2629 have changed. 2631 Regardless of the truth of the first sentence above, either when 2632 it was written or today, it needs to be stressed that the fact 2633 that a server manifests a particular behavior does not imply that 2634 it is valid according to the protocol specification. In this 2635 case, the supposed "owner-override semantics" clearly are not 2636 valid, since they contradict the specification of both the mode- 2637 based and ACL-based approaches to file access authorization. 2639 With regard to the second sentence of the quotation above, it is 2640 not clear whether it is helpful or hurtful to allow continued 2641 access to open files which have become inaccessible due to changes 2642 in security and it is not clear that the working group will make a 2643 decision on the matter in this document, despite the obvious 2644 security implications. In any case, the resolution is unlikely to 2645 depend on whether the owner is involved. 2647 * RFC8881 contains the following, which is now superseded: 2649 Many servers have the notion of a "superuser" that has 2650 privileges beyond an ordinary user. The superuser may be able 2651 to read or write data or metadata in ways that would not be 2652 permitted by the ACL or mode attributes. 2654 While many (or almost all) systems in which NFSv4 servers are 2655 embedded, have provisions for such privileged access to be 2656 provided, it does not follow that NFSv4 servers, as such, need to 2657 have provision for such access. 2659 Providing such access as part of the NFSv4 protocols, would 2660 necessitate a major revision of the semantics of ACL including 2661 such troublesome matters as the proper handling of AUDIT and ALARM 2662 ACEs in the face of such privileged access. 2664 Because of the effect such unrestricted access might have in 2665 facilitating and perpetuating attacks, Section 17.1.3 will explain 2666 that the treat analysis in Section 17, will not cover servers 2667 which choose to allow such access. 2669 8.2. Client Considerations 2671 [Previous Treatment]: Clients SHOULD NOT do their own access checks 2672 based on their interpretation of the ACL, but rather use the OPEN and 2673 ACCESS operations to do access checks. This allows the client to act 2674 on the results of having the server determine whether or not access 2675 should be granted based on its interpretation of the ACL. 2677 [Author Aside]: With regard to the use of "SHOULD NOT" in the 2678 paragraph above, it is not clear what might be valid reasons to 2679 bypass this recommendation. Perhaps "MUST NOT" or "should not" would 2680 be more appropriate. 2682 [Consensus Needed (Item #23a)]: Clients are expected to do their own 2683 access checks based on their interpretation of the ACL, but instead 2684 use the OPEN and ACCESS operations to do access checks. This allows 2685 the client to act on the results of having the server determine 2686 whether or not access should be granted based on its interpretation 2687 of the ACL. 2689 [Previous Treatment]: Clients must be aware of situations in which an 2690 object's ACL will define a certain access even though the server will 2691 not enforce it. In general, but especially in these situations, the 2692 client needs to do its part in the enforcement of access as defined 2693 by the ACL. 2695 [Author Aside]: Despite what is said later, the only such case I know 2696 of is the use of READ and EXECUTE where the client, but not the 2697 server, has any means of distinguishing these. I don't know of any 2698 others. If there were, how could ACCESS or OPEN be used to verify 2699 access? 2701 [Consensus Needed (Item #23a)]; Clients need to be aware of 2702 situations in which an object's ACL will define a certain access even 2703 though the server is not in position to enforce it because the server 2704 does not have the relevant information, such as knowing whether a 2705 READ is for the purpose of executing a file. Because of such 2706 situations, the client needs to do be prepared to do its part in the 2707 enforcement of access as defined by the ACL. 2709 To do this, the client will send the appropriate ACCESS operation 2710 prior to servicing the request of the user or application in order to 2711 determine whether the user or application should be granted the 2712 access requested. 2714 [Previous Treatment (Item #24a)]: For examples in which the ACL may 2715 define accesses that the server doesn't enforce, see Section 8.1. 2717 [Author Aside]: The sentence above is clearly wrong since that 2718 section is about enforcement the server does do. The expectation is 2719 that it will be deleted as part of Consensus Item #24a. 2721 9. Combining Authorization Models 2723 9.1. Background for Combined Authorization Model 2725 Both RFCs 7530 and 5661 contain material relating to the need, when 2726 both mode and ACL attributes are supported, to make sure that the 2727 values are appropriately co-ordinated. Despite the fact that these 2728 discussions are different, they are compatible, and differ in only a 2729 small number of areas. 2731 [Author Aside]: From this point on, all unannotated paragraphs in 2732 this section are to be assumed part of Consensus Item #25b 2734 As a result, in this document, we will have a single treatment of 2735 this issue, in Sections 9.2 through 9.11. In addition, an 2736 NFSv4.2-based extension related to attribute co-ordination will be 2737 described in Section 9.12. 2739 The current NFSv4.0 and NFSv4.1 descriptions of this share one 2740 unfortunate characteristic in that they both are written to give 2741 server implementations a broad latitude in implementation choices 2742 while neglecting entirely the need for the clients and users to have 2743 a reliable description of what servers are to do in this area. 2745 As a result, one of the goals of this new combined treatment will be 2746 to limit this excessive freedom, while taking proper account of the 2747 possibility of compatibility issues that a more tightly drawn 2748 specification might give rise to. 2750 [Author Aside, Including List]: The various ways in which these kinds 2751 of issues have been dealt with are listed below: 2753 * In some cases, the term "MAY" is used in contexts where it is 2754 inappropriate, since the allowed variation has the potential to 2755 cause harm in that it leaves the client unsure exactly what 2756 security-related action will be performed by the server. 2758 * There are also cases in which no RFC2119-defined keywords are used 2759 but it is stated that certain server implementations do a 2760 particular, leaving the impression that that action is to be 2761 allowed, just as if "MAY" had been used. 2763 * There is a case in which the term "SHOULD" is clearly used 2764 intentionally, without it being clear what the valid reasons to 2765 ignore the guidance might be. 2767 * There are many case in which the term "SHOULD" is used without any 2768 clear indication why it was used. In this situation it is 2769 possible that the "SHOULD" was essentially treated as a "MAY" but 2770 also possible that servers chose to follow the recommendation. 2772 In order to deal with the many uses of the terms "SHOULD" and "SHOULD 2773 NOT" in Section 9 and included subsections, which have no clear 2774 motivation, it is to be assumed that the valid reasons to act 2775 contrary to the recommendation given are the difficulty of changing 2776 implementations based on previous analogous guidance, which may have 2777 given the impression that the server was free to ignore the guidance 2778 for any reason the implementer chose. This allows the possibility of 2779 more individualized treatment of these instances once compatibility 2780 issues have been adequately discussed. 2782 [Author Aside]: In each subsection in which the the interpretation of 2783 these term in the previous paragraph applies there will be an 2784 explicit reference to Consensus Item #25, to draw attention to this 2785 change, even in the absence of modified text. 2787 9.2. Needed Attribute Coordination 2789 On servers that support both the mode and the acl or dacl attributes, 2790 the server must keep the two consistent with each other. The value 2791 of the mode attribute (with the exception of the high-order bits 2792 reserved for client use as described in Section 7.3.1) must be 2793 determined entirely by the value of the ACL, so that use of the mode 2794 is never required for anything other than setting the three high- 2795 order bits. See Sections 9.6 through 9.8 for detailed discussion. 2797 [Previous Treatment (Item #25c)]: When a mode attribute is set on an 2798 object, the ACL attributes may need to be modified in order to not 2799 conflict with the new mode. In such cases, it is desirable that the 2800 ACL keep as much information as possible. This includes information 2801 about inheritance, AUDIT and ALARM ACEs, and permissions granted and 2802 denied that do not conflict with the new mode. 2804 [Author Aside]: the things that this formulation leaves uncertain, is 2805 whether, if the ACL specifies permission for a named user group or 2806 group, it "conflicts" with the node. Ordinarily, one might think it 2807 does not, unless the specified user is the owner of the file or a 2808 member of the owning group, or the specified group is the owning 2809 group. However, while some parts of the existing treatment seem to 2810 agree with this, other parts, while unclear, seem to suggest 2811 otherwise, while the treatment in Section 9.6 is directly in 2812 conflict. 2814 [Previous Treatment (Item #26a)]: The server that supports both mode 2815 and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and 2816 MODE4_*OTH bits with the ACEs that have respective who fields of 2817 "OWNER@", "GROUP@", and "EVERYONE@". 2819 [Author Aside]: This sentence ignores named owners and group, giving 2820 the impressions that there is no need to change them. 2822 [Previous Treatment (Item #26a)]: This way, the client can see if 2823 semantically equivalent access permissions exist whether the client 2824 asks for the owner, owner_group, and mode attributes or for just the 2825 ACL. 2827 [Author Aside, Including List:] The above sentence, while hard to 2828 interpret for a number a reasons, is worth looking at in detail 2829 because it might suggest an approach different from the in the 2830 previous sentence from the initial paragraph for The Previous 2831 Treatment of Item #26a. 2833 * The introductory phrase "this way" adds confusion because it 2834 suggests that there are other valid ways of doing this, while not 2835 giving any hint about what these might be. 2837 * It is hard to understand the intention of "client can see if 2838 semantically equivalent access permissions" especially as the 2839 client is told elsewhere that he is not to interpret the ACL 2840 himself. 2842 * If this sentence is to have any effect at all it, it would be to 2843 suggest that the result be the same "whether the client asks for 2844 the owner, owner_group, and mode attributes or for just the ACL." 2846 If these are to be semantically equivalent it would be necessary 2847 to delete ACEs for named users, which requires a different 2848 approach form the first sentence of the original paragraph. 2850 {Consensus Needed (Items #26a, #28a)]: A server that supports both 2851 mode and ACL need to take care to synchronize the MODE4_*USR, 2852 MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective 2853 who fields of "OWNER@", "GROUP@", and "EVERYONE@". This is 2854 relatively straightforward in the case of forward-slope modes, but 2855 the case of reverse-slope modes need to be addressed as described in 2856 Sections 9.3 and 9.6. 2858 {Consensus Needed (Item #26a)]: How other ACEs are dealt with when 2859 setting mode is described in Section 9.6. This includes ACEs with 2860 other who value, all AUDIT and ALARM ACEs, and all ACES that affect 2861 ACL inheritance. 2863 [Author Aside, Including List]: The author believes that the material 2864 now associated with Item #27, including the following paragraph and 2865 Section 9.4 are best deleted. This is because of reasons specified 2866 in that section and the following reasons listed below: 2868 * Having multiple methods to map from ACL to mode undercuts the 2869 whole purpose of Section 9, which is to co-ordinate these 2870 attributes so that clients who use each of the attributes can use 2871 that without interfering with those that reference others. That 2872 cannot be accomplished if there were multiple valid ways that 2873 servers might choose, without providing any means by which the 2874 client might determine which mapping was being used. 2876 * The withdrawn POSIX draft ACLs would almost certainly have been 2877 considered in connection with an NFSv4. In any case, they were 2878 not adopted and the current ACL model adopted. Given that fact 2879 there is no sense in burdening the new feature with the 2880 substantial burden of supporting the one that was rejected by the 2881 working group 2883 * It is very unlikely that such implementations still exist, given 2884 that that it is over twenty years since the decision was made to 2885 adopt the more extensive NFSv4 ACL model and over ten years since 2886 RFC5661 was published. Even assuming this was justified as a 2887 transition measure, the time for any such transition mechanisms is 2888 long past. 2890 * Despite the statement in the next section that this alternate 2891 model is "discouraged", its continued appearance as an alternate 2892 way of computing mode, on the same level as the one appropriate to 2893 the NFSv4 acl model encourages this use compared to a situation in 2894 which no alternate method of computing mode was mentioned. 2896 [Previous Treatment (Item #27a)]: In this section, much depends on 2897 the method in specified Section 9.3. Many requirements refer to this 2898 section. It should be noted that the methods have behaviors 2899 specified with "SHOULD" and that alternate approaches are discussed 2900 in Section 9.4. This is intentional, to avoid invalidating existing 2901 implementations that compute the mode according to the withdrawn 2902 POSIX ACL draft (1003.1e draft 17), rather than by actual permissions 2903 on owner, group, and other. 2905 [Author Aside]: Given the mixture of RFC2219 terms, I think all of 2906 them in Section 9 need review. Further, given the effort that has 2907 gone into Section 9, to accommodate these implementations of a draft 2908 that was withdrawn decades ago. The idea of trying to make mode and 2909 acl match is undercut when there are different valid ways of 2910 computing the mode. There shouldn't be. To specify one way to do 2911 this is necessary to accomplish the goal here and to do so would not 2912 "invalidate" anything. Rather, it would establish, correctly, that 2913 such implementations are not implementations of the NFSv4 ACL model, 2914 but of the withdrawn POSIX ACL draft. 2916 9.3. Computing a Mode Attribute from an ACL 2918 [Previous Treatment (Item #27b)]: The following method can be used to 2919 calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode 2920 attribute, based upon an ACL. 2922 [Author Aside]: "can be used" says essentially "do whatever you 2923 choose" and would make Section 9 essentially pointless. Would prefer 2924 "is to be used" or "MUST", with "SHOULD" available if valid reasons 2925 to do otherwise can be found. 2927 [Consensus Needed (Items #27b, #28b)}: The following method (or 2928 another one providing exactly the same results) SHOULD be used to 2929 calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode 2930 attribute, based upon an ACL. In this case valid reasons to bypass 2931 the recommendation are limited to implementor reliance on previous 2932 specifications which ignored the cases of the owner having less 2933 access than the owning group or the owning group having less access 2934 than others. Further, in implementing or the maintaining an 2935 implementation previously believed to be valid, the implementor needs 2936 to be aware that this will result invalid values in some uncommon 2937 cases. 2939 [Author Aside, Including List]: The algorithm specified below, now 2940 considered the Previous Treatment associated with Item #24a, has an 2941 important flaw in does not deal with the (admittedly uncommon) case 2942 in which the owner_group has less access than the owner or others 2943 have less access than the owner-group. In essence, this algorithm 2944 ignores the following facts: 2946 * That GROUP@ includes the owning user while group bits in the mode 2947 do not affect the owning user. 2949 * That EVERYONE includes the owning group while other bits in the 2950 mode do not affect users within the owning group. 2952 [Previous Treatment (Item #28a)]: First, for each of the special 2953 identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, 2954 considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and 2955 for the identifier under consideration. The result of the evaluation 2956 will be an NFSv4 ACL mask showing exactly which bits are permitted to 2957 that identifier. 2959 [Previous Treatment (Item #28a)]: Then translate the calculated mask 2960 for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively, 2961 the user, group, and other, as follows: 2963 [Consensus Needed, including List(Item #28a)]: First, for each of the 2964 sets of mode bits (i.e., user, group other, evaluate the ACL in 2965 order, with a specific evaluation procedure depending on the specific 2966 set of mode bits being determined. For each set there will be one or 2967 more special identifiers considered in a positive sense so that ALLOW 2968 and DENY ACE's are considered in arriving at the mode bit. In 2969 addition, for some sets of bits, there will be one or more special 2970 identifiers to be considered only in a negative sense, so that only 2971 DENY ACE's are considered in arriving at the mode it. The users to 2972 be considered are as follows: 2974 * For the owner bits, "OWNER@" and "EVERYONE@" are to be considered, 2975 both in a positive sense. 2977 * For the group bits, "GROUP@" and "EVERYONE@" are to be considered, 2978 both in a positive sense, while "OWNER@" is to be considered in a 2979 negative sense. 2981 * For the other bit, "EVERYONE@" is to be considered in a positive 2982 sense, while "OWNER@" and "GROUP@" are to be considered in a 2983 negative sense. 2985 [Consensus Needed (Item #28a)]: Then translate the calculated mask 2986 for for each set of bit into the corresponding mode bits for, user, 2987 group, and other, as follows: 2989 1. Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and 2990 only if ACE4_READ_DATA is set in the corresponding mask. 2992 2. Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and 2993 only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the 2994 corresponding mask. 2996 3. Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if 2997 and only if ACE4_EXECUTE is set in the corresponding mask. 2999 9.4. Alternatives in Computing Mode Bits 3001 [Author Aside]: For reasons explained below, the author believes this 3002 section needs to deleted, as part of Consensus Item #27c. In order 3003 to enable this deletion or its replacement by an alternate 3004 formulation if the working group so decides, all unannotated 3005 paragraphs within this section are to be considered the Previous 3006 Treatment corresponding to Consensus Item #27c. 3008 Some server implementations also add bits permitted to named users 3009 and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and 3010 MODE4_XGRP). 3012 Implementations are discouraged from doing this, because it has been 3013 found to cause confusion for users who see members of a file's group 3014 denied access that the mode bits appear to allow. (The presence of 3015 DENY ACEs may also lead to such behavior, but DENY ACEs are expected 3016 to be more rarely used.) 3018 [Author Aside]: The text does not seem to really discourage this 3019 practice and makes no reference to the need to standardize behavior 3020 so the clients know what to expect or any other reason for providing 3021 standardization of server behavior. 3023 The same user confusion seen when fetching the mode also results if 3024 setting the mode does not effectively control permissions for the 3025 owner, group, and other users; this motivates some of the 3026 requirements that follow. 3028 [Author Aside]: The part before the semicolon appears to be relevant 3029 to Consensus Item #23 but does not point us to a clear conclusion. 3030 The statement certainly suggests that the 512-ACL approach is more 3031 desirable but the absence of a more direct statement to that effect 3032 suggest that this is a server implementer choice. 3034 [Author Aside]: The part after the semicolon is hard to interpret in 3035 that it is not clear what "this" refers to or which which 3036 requirements are referred to by "some of the requirements that 3037 follow". The author would appreciate hearing from anyone who has 3038 insight about what might have been intended here. 3040 9.5. Setting Multiple ACL Attributes 3042 In the case where a server supports the sacl or dacl attribute, in 3043 addition to the acl attribute, the server MUST fail a request to set 3044 the acl attribute simultaneously with a dacl or sacl attribute. The 3045 error to be given is NFS4ERR_ATTRNOTSUPP. 3047 9.6. Setting Mode and not ACL (overall) 3049 9.6.1. Setting Mode and not ACL (vestigial) 3051 [Author Aside]: All unannotated paragraphs as considered the Previous 3052 treatment of Consensus Item #30a. 3054 [Previous Treatment (Item #?a)]: When any of the nine low-order mode 3055 bits are subject to change, either because the mode attribute was set 3056 or because the mode_set_masked attribute was set and the mask 3057 included one or more bits from the nine low-order mode bits, and no 3058 ACL attribute is explicitly set, the acl and dacl attributes must be 3059 modified in accordance with the updated value of those bits. This 3060 must happen even if the value of the low-order bits is the same after 3061 the mode is set as before. 3063 Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl 3064 attribute) are unaffected by changes to the mode. 3066 In cases in which the permissions bits are subject to change, the acl 3067 and dacl attributes MUST be modified such that the mode computed via 3068 the method in Section 9.3 yields the low-order nine bits (MODE4_R*, 3069 MODE4_W*, MODE4_X*) of the mode attribute as modified by the 3070 attribute change. The ACL attributes SHOULD also be modified such 3071 that: 3073 1. If MODE4_RGRP is not set, entities explicitly listed in the ACL 3074 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3075 ACE4_READ_DATA. 3077 2. If MODE4_WGRP is not set, entities explicitly listed in the ACL 3078 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3079 ACE4_WRITE_DATA or ACE4_APPEND_DATA. 3081 3. If MODE4_XGRP is not set, entities explicitly listed in the ACL 3082 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 3083 ACE4_EXECUTE. 3085 Access mask bits other than those listed above, appearing in ALLOW 3086 ACEs, MAY also be disabled. 3088 Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect 3089 the permissions of the ACL itself, nor do ACEs of the type AUDIT and 3090 ALARM. As such, it is desirable to leave these ACEs unmodified when 3091 modifying the ACL attributes. 3093 Also note that the requirement may be met by discarding the acl and 3094 dacl, in favor of an ACL that represents the mode and only the mode. 3095 This is permitted, but it is preferable for a server to preserve as 3096 much of the ACL as possible without violating the above requirements. 3097 Discarding the ACL makes it effectively impossible for a file created 3098 with a mode attribute to inherit an ACL (see Section 9.10). 3100 9.6.2. Setting Mode and not ACL (Discussion) 3102 [Author Aside]: All unannotated paragraphs as considered Author 3103 Asides relating to Consensus Item #30b. 3105 Existing documents are unclear about the changes to be made to an 3106 existing ACL when the nine low-order bits of the mode attribute are 3107 subject to modification using SETATTR. 3109 A new treatment needs to apply to all minor versions. It will be 3110 necessary to specify that, for all minor versions, setting of the 3111 mode attribute, subjects the low-order nine bits to modification. 3113 One important source of this lack of clarity is the following 3114 paragraph from Section 9.6.1, which we refer to later as the trivial- 3115 implementation-remark". 3117 Also note that the requirement may be met by discarding the acl 3118 and dacl, in favor of an ACL that represents the mode and only the 3119 mode. This is permitted, but it is preferable for a server to 3120 preserve as much of the ACL as possible without violating the 3121 above requirements. Discarding the ACL makes it effectively 3122 impossible for a file created with a mode attribute to inherit an 3123 ACL (see Section 9.10). 3125 The only "requirement" which might be met by the procedure mentioned 3126 above is the text quoted below. 3128 In cases in which the permissions bits are subject to change, the 3129 acl and dacl attributes MUST be modified such that the mode 3130 computed via the method in Section 9.3 yields the low-order nine 3131 bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as 3132 modified by the attribute change. 3134 While it is true that this requirement could be met by the specified 3135 treatment, this fact does not, in itself, affect the numerous 3136 recommendations that appear between the above requirement and the 3137 trivial-implementation-remark. 3139 It may well be that there are are implementations that have treated 3140 the trivial-implementation-remark as essentially allowing them to 3141 essentially ignore all of those recommendations, resulting in a 3142 situation in which were treated as if it were a trivial- 3143 implementation-ok indication. How that issue will be dealt with in a 3144 replacement for Section 9.6.1 will be affected by the working group's 3145 examination of compatibility issues. 3147 The following specific issues need to be addressed: 3149 * Handling of inheritance. 3151 Beyond the possible issues that arise from the trivial- 3152 implementation-ok interpretation, the treatment in Section 9.6.1, 3153 by pointing specifically to existing INHERIT_ONLY ACEs obscures 3154 the corresponding need to convert ACE's that specify both 3155 inheritance and access permissions to be converted to INHERIT_ONLY 3156 ACEs. 3158 * Reverse-slope modes 3160 * Named users and groups. 3162 * The exact bounds of what within the ACL is covered by the low- 3163 order bits of the mode. 3165 It appears that for many of the issues, there are many possible 3166 readings of the existing specs, leading to the possibility of 3167 multiple inconsistent server behaviors. Furthermore, there are cases 3168 in which none of the possible behaviors described in existing 3169 specifications meets the needs. 3171 As a result of these issues, the existing specifications do not 3172 provide a reliable basis for client-side implementations of the ACL 3173 feature which a Proposed Standard is normally expected to provide. 3175 9.6.3. Setting Mode and not ACL (Proposed) 3177 [Author Aside]: This proposed section is part of Consensus Item #30c 3178 and all unannotated paragraphs within it are to be considered part of 3179 that Item. Since the proposed text includes support for reverse- 3180 slope modes, treats all minor versions together and assumes decisions 3181 about handling of ACEs for named users and groups, the relevance of 3182 consensus items #26, #28, and #29 should be noted. 3184 [Author Aside]: As with all such Consensus Items, it is expected that 3185 the eventual text in a published RFC might be substantially different 3186 based on working group discussion of client and server needs and 3187 possible compatibility issues. In this particular case, that 3188 divergence can be expected to be larger, because the author was 3189 forced to guess about compatibility issues and because earlier 3190 material, on which it is based left such a wide range of matters to 3191 the discretion of server implementers. It is the author's hope that, 3192 as the working group discusses matters, sufficient attention is 3193 placed on the need for client-side implementations to have reliable 3194 information about expected server-side actions. 3196 This section describes how ACLs are to be updated in response to 3197 actual or potential changes in the mode attribute, when the 3198 attributes needed by both of the file access authorization models are 3199 supported. It supersedes the discussions of the subject in RFCs 7530 3200 and 8881, each of which appeared in Section 6.4.1.1 of the 3201 corresponding document. 3203 It is necessary to approach the matter differently than in the past 3204 because: 3206 * Organizational changes are necessary to address all minor versions 3207 together. 3209 * Those previous discussions are often internally inconsistent 3210 leaving it unclear what specification-mandated actions were being 3211 specified.. 3213 * In many cases, servers were granted an extraordinary degree of 3214 freedom to choose the action to take, either explicitly or via an 3215 apparently unmotivated use of SHOULD, leaving it unclear what 3216 might be considered "valid" reasons to ignore the recommendation. 3218 * There appears to have been no concern for the problems that 3219 clients and applications might encounter dealing ACLs in such an 3220 uncertain environment. 3222 * Cases involving reverse-slope modes were not adequately addressed. 3224 * The security-related effects of SVTX were not addressed. 3226 While that sort of approach might have been workable at one time, it 3227 made it difficult to devise client-side ACL implementations, even if 3228 there had been any interest in doing so. In order to enable this 3229 situation to eventually be rectified, we will define the preferred 3230 implementation here, but in order to provide temporary compatibility 3231 with existing implementations based on reasonable interpretations of 3232 RFCs 7530 and 8881. To enable such compatibility the term "SHOULD" 3233 will be used, with the understanding that valid reasons to bypass the 3234 recommendation, are limited to implementers' previous reliance on 3235 these earlier specifications and the difficulty of changing them now. 3237 When the recommendation is bypassed in this way, it is necessary to 3238 understand, that, until the divergence is rectified, or the client is 3239 given a way to determine the detail of the server's non-standard 3240 behavior, client-side implementations may find it difficult to 3241 implement a client-side implementation that correctly interoperates 3242 with the existing server. 3244 When mode bits involved in determining file access authorization are 3245 subject to modification, the server MUST, when ACL-related attributes 3246 have been set, modify the associated ACEs so as not to conflict with 3247 the new value of the mode attribute. 3249 The occasions to which this requirement applies, vary with the 3250 attribute being set and the type of object being dealt with: 3252 * For all minor versions, any change to the mode attribute, triggers 3253 this requirement 3255 * When the set_mode_masked attribute is being set on an object which 3256 is not a directory, whether this requirement is triggered depends 3257 on whether any of the nine low-order bits of the mode is included 3258 in the mask. 3260 * When the set_mode_masked attribute is being set on a directory, 3261 whether this requirement is triggered depends on whether any of 3262 the nine low-order bits of the mode or the SVTX bit is included in 3263 the mask of bit whose values are to be set. 3265 When the requirement is triggered, ACEs need to be updated to be 3266 consistent with the new mode attribute. In the case of AUDIT and 3267 ALARM ACEs, which are outside of file access authorization, no change 3268 is to be made. 3270 For ALLOW and DENY ACEs, changes are necessary to avoid conflicts 3271 with the mode in a number of areas: 3273 * The handling of ACEs that have consequences relating to ACL 3274 inheritance. 3276 * The handling of ACEs with a who-value of OWNER@, GROUP@, or 3277 EVERYONE@ need to be adapted to the new mode. 3279 * ACEs whose who-value is a named user or group, are to be retained 3280 or not based on the mode being set as described below. 3282 * ACEs whose who-value is one of the other special values defined in 3283 Section 5.9 are to be left unmodified. 3285 In order to deal with inheritance issues, the following SHOULD be 3286 done: 3288 * ACEs that specify inheritance-only need to be retained, regardless 3289 of the value of who specified, since inheritance issues are 3290 outside of the semantic range of the mode attribute. 3292 * ACEs that specify inheritance, in addition to allowing or denying 3293 authorization for the current object need to be converted into 3294 inheritance-only ACEs. This needs to occur irrespective of the 3295 value of who appearing in the ACE. 3297 For NFSv4 servers that support the dacl attribute, at least the first 3298 of the above MUST be done. 3300 Other ACEs are to be treated are classified based on the ACE's who- 3301 value: 3303 * ACEs whose who-value is OWNER@, GROUP@, or EVERYONE@ are referred 3304 to as mode-directed ACEs and are subject to extensive 3305 modification. 3307 * ACEs whose who-value is a named user or group are either left 3308 alone or subject to extensive modification, as described below. 3310 * ACEs whose who-value is one of the other special values defined in 3311 Section 5.9 are left as they are. 3313 Mode-directed ACEs need to be modified so that they reflect the mode 3314 being set. 3316 In effecting this modification, the server will need to distinguish 3317 mask bits deriving from mode attributes from those that have no such 3318 connection. The former can be categorized as follows: 3320 * For non-directory objects, the mask bits ACE4_READ_DATA (from the 3321 read bit in the mode), ACE4_EXECUTE (from the execute bit in the 3322 mode), and ACE4_WRITE_DATA together with ACE4_APPEND_DATA (from 3323 the write bit in the mode) are all derived from the set of three 3324 mode bits appropriate to the current who-value. 3326 * For directories, analogous mask bits are included: 3327 ACE4_LIST_DIRECTORY (from the read in the mode), ACE4_EXECUTE 3328 (from the execute bit in the mode), and ACE4_ADD_FILE together 3329 with ACE4_ADD_SUBDIRECTORY and ACE4_DELETE_CHILD> (from the write 3330 bit in the mode) are all included based on the set of three mode 3331 bits appropriate to the current who-value. 3333 When the SVTX bit is set, ACE4_DELETE_CHILD is set, regardless of 3334 the values of the low-order nine bit of the mode. 3336 * When named attributes are supported for the object whose mode is 3337 subject to change, ACE4_READ_NAMED_ATTRIBUTES is set based on the 3338 read bit and ACE4_WRITE_NAMED_ATTRIBUTES is set based on the write 3339 bit based on the set of three mode bits appropriate to the current 3340 who-value. 3342 * In the case of OWNER@, ACE4_WRITE_ACL, ACE4_WRITE_ATTRIBUTES 3343 ACE4_WRITE_ACL, ACE4_WRITE_OWNER are all set. 3345 The union of these groups of mode bit are referred to as the mode- 3346 relevant mask bits. 3348 [Author Aside]: Except for the case of ACE4_SYNCHRONIZE, the handling 3349 of mask bits which are not mode-relevant is yet to be clarified. For 3350 tracking purposes, the handling of mask bits ACE4_READ_ATTRIBUTES, 3351 ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD, ACE4_READ_ACL will 3352 be dealt with as Consensus Item #31. 3354 If the mode is of forward-slope, then each set of three bits is 3355 translated into a corresponding set of mode bits. Then, for each 3356 ALLOW ACE with one of these who values, all mask bits in this class 3357 are deleted and the computed mode bits for that who-value 3358 substituted. For DENY ACEs, all mask bits in this class are reset, 3359 and, if none remain, the ACE MAY be deleted. 3361 In the case of reverse-slope modes, the following SHOULD be done: 3363 * For mode-directed ACEs all mode-relevant mask bits are reset, and, 3364 if none remain, the ACE MAY be deleted. 3366 * Then, proceeding from owner to others, ALLOW ACEs are generated 3367 based on the computed mode-relevant mask bits. 3369 At each stage, if the mode-relevant mask bits for the current 3370 stage includes mask bits not set for the previous stage, then a 3371 DENY ACE needs to be added before the new ALLOW ACE. That ACE 3372 will have a who-value based on the previous stage and a mask 3373 consisting of the bit included in the current stage that were not 3374 included in the previous stage. 3376 In cases in which the above recommendation is not followed, the 3377 server MUST follow a procedure which arrives at an ACL which behaves 3378 identically for all cases involving forward-slope mode values. 3380 When dealing with ACEs whose who-value is a named user or group, they 3381 SHOULD be processed as follows: 3383 * DENY ACEs are left as they are. 3385 * ALLOW ACES are subject to filtering to effect mode changes that 3386 deny access to any principal other than the owner. 3388 To determine the set of mode bits to which this filtering applies, 3389 the mode bits for group are combined with those for others, to get 3390 a set of three mode bits to determine which of the mode privileges 3391 (read, write, execute) are denied to all principals other than the 3392 owner, i.e. the set of bits not present in either the bits for 3393 group or the bits for others. 3395 Those three bits are converted to the corresponding set of mask 3396 bits, according to the rules above. 3398 All such mask bits are reset in the ACE, and, if none remain, the 3399 ACE MAY be deleted. 3401 In cases in which the above recommendation is not followed, the 3402 server MUST follow a procedure which arrives at an ACL which behaves 3403 identically for all cases involving forward-slope mode values. This 3404 would be accomplished if the mask bits were reset based on the group 3405 bits alone, as had been recommended in earlier specifications. 3407 9.7. Setting ACL and Not Mode 3409 [Author Aside]: The handling of SHOULD in this section is considered 3410 as part of Consensus Item #25d. 3412 When setting the acl or dacl and not setting the mode or 3413 mode_set_masked attributes, the permission bits of the mode need to 3414 be derived from the ACL. In this case, the ACL attribute SHOULD be 3415 set as given. The nine low-order bits of the mode attribute 3416 (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result 3417 of the method in Section 9.3. The three high-order bits of the mode 3418 (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged. 3420 9.8. Setting Both ACL and Mode 3422 When setting both the mode (includes use of either the mode attribute 3423 or the mode_set_masked attribute) and the acl or dacl attributes in 3424 the same operation, the attributes MUST be applied in the following 3425 order order: mode (or mode_set_masked), then ACL. The mode-related 3426 attribute is set as given, then the ACL attribute is set as given, 3427 possibly changing the final mode, as described above in Section 9.7. 3429 9.9. Retrieving the Mode and/or ACL Attributes 3431 [Author Aside]: The handling of SHOULD in this section is considered 3432 as part of Consensus Item #25e. 3434 Some server implementations may provide for the existence of "objects 3435 without ACLs", meaning that all permissions are granted and denied 3436 according to the mode attribute and that no ACL attribute is stored 3437 for that object. If an ACL attribute is requested of such a server, 3438 the server SHOULD return an ACL that does not conflict with the mode; 3439 that is to say, the ACL returned SHOULD represent the nine low-order 3440 bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as 3441 described in Section 9.3. 3443 For other server implementations, the ACL attribute is always present 3444 for every object. Such servers SHOULD store at least the three high- 3445 order bits of the mode attribute (MODE4_SUID, MODE4_SGID, 3446 MODE4_SVTX). The server SHOULD return a mode attribute if one is 3447 requested, and the low-order nine bits of the mode (MODE4_R*, 3448 MODE4_W*, MODE4_X*) MUST match the result of applying the method in 3449 Section 9.3 to the ACL attribute. 3451 9.10. Creating New Objects 3453 [Author Aside]: The handling of SHOULD in this section is considered 3454 as part of Consensus Item #25f. 3456 If a server supports any ACL attributes, it may use the ACL 3457 attributes on the parent directory to compute an initial ACL 3458 attribute for a newly created object. This will be referred to as 3459 the inherited ACL within this section. The act of adding one or more 3460 ACEs to the inherited ACL that are based upon ACEs in the parent 3461 directory's ACL will be referred to as inheriting an ACE within this 3462 section. 3464 Implementors should base the behavior of CREATE and OPEN depending on 3465 the presence or absence of the mode and ACL attributes by following 3466 the directions below: 3468 1. If just the mode is given in the call: 3470 In this case, inheritance SHOULD take place, but the mode MUST be 3471 applied to the inherited ACL as described in Section 9.6, thereby 3472 modifying the ACL. 3474 2. If just the ACL is given in the call: 3476 In this case, inheritance SHOULD NOT take place, and the ACL as 3477 defined in the CREATE or OPEN will be set without modification, 3478 and the mode modified as in Section 9.7. 3480 3. If both mode and ACL are given in the call: 3482 In this case, inheritance SHOULD NOT take place, and both 3483 attributes will be set as described in Section 9.8. 3485 4. If neither mode nor ACL is given in the call: 3487 In the case where an object is being created without any initial 3488 attributes at all, e.g., an OPEN operation with an opentype4 of 3489 OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD 3490 NOT take place (note that EXCLUSIVE4_1 is a better choice of 3491 createmode4, since it does permit initial attributes). Instead, 3492 the server SHOULD set permissions to deny all access to the newly 3493 created object. It is expected that the appropriate client will 3494 set the desired attributes in a subsequent SETATTR operation, and 3495 the server SHOULD allow that operation to succeed, regardless of 3496 what permissions the object is created with. For example, an 3497 empty ACL denies all permissions, but the server should allow the 3498 owner's SETATTR to succeed even though WRITE_ACL is implicitly 3499 denied. 3501 In other cases, inheritance SHOULD take place, and no 3502 modifications to the ACL will happen. The mode attribute, if 3503 supported, MUST be as computed in Section 9.3, with the 3504 MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no 3505 inheritable ACEs exist on the parent directory, the rules for 3506 creating acl, dacl, or sacl attributes are implementation 3507 defined. If either the dacl or sacl attribute is supported, then 3508 the ACL4_DEFAULTED flag SHOULD be set on the newly created 3509 attributes. 3511 9.11. Use of Inherited ACL When Creating Objects 3513 [Author Aside]: The handling of SHOULD in this section is considered 3514 as part of Consensus Item #25g. 3516 If the object being created is not a directory, the inherited ACL 3517 SHOULD NOT inherit ACEs from the parent directory ACL unless the 3518 ACE4_FILE_INHERIT_ACE flag is set. 3520 If the object being created is a directory, the inherited ACL should 3521 inherit all inheritable ACEs from the parent directory, that is, 3522 those that have the ACE4_FILE_INHERIT_ACE or 3523 ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has 3524 ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear, 3525 the inherited ACE on the newly created directory MUST have the 3526 ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being 3527 affected by ACEs meant for non-directories. 3529 When a new directory is created, the server MAY split any inherited 3530 ACE that is both inheritable and effective (in other words, that has 3531 neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set), 3532 into two ACEs, one with no inheritance flags and one with 3533 ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute, 3534 both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.) 3535 This makes it simpler to modify the effective permissions on the 3536 directory without modifying the ACE that is to be inherited to the 3537 new directory's children. 3539 9.12. Combined Authorization Models for NFSv4.2 3541 The NFSv4 server implementation requirements described in the 3542 subsections above apply to NFSv4.2 as well and NFSv4.2 clients can 3543 assume that the server follows them. 3545 NFSv4.2 contains an OPTIONAL extension, defined in [13], which is 3546 intended to reduce the interference of modes, restricted by the umask 3547 mechanism, with the acl inheritance mechanism. The extension allows 3548 the client to specify the umask separately from the mask attribute. 3550 10. Labelled NFS Authorization Model 3552 The labelled NFS feature of NFSv4.2 is designed to support Mandatory 3553 Access control. 3555 The attribute sec_label enables an authorization model focused on 3556 Mandatory Access Control and is described in Section 10. 3558 Not much can be said about this feature because the specification, in 3559 the interest of flexibility, has left important features undefined in 3560 order to allow future extension. As a result, we have something that 3561 is a framework to allow Mandatory Access Control rather than one to 3562 provide it. In particular, 3564 * The sec_label attribute, which provides the objects label has no 3565 existing specification. 3567 * There is no specification of the of the format of the subject 3568 label or way to authenticate them. 3570 * As a result, all authorization takes place on the client, and the 3571 server simply accepts the client's determination. 3573 This arrangements shares important similarities with AUTH_SYS. As 3574 such it makes sense: 3576 * To require/recommend that an encrypted connection be used. 3578 * To require/recommend that client and server peers mutually 3579 authenticate as part of connection establishment. 3581 * That work be devoted to providing a replacement without the above 3582 issues. 3584 11. State Modification Authorization 3586 Modification of locking and session state data should not be done by 3587 a client other than the one that created the lock. For this form of 3588 authorization, the server needs to identify and authenticate client 3589 peers rather than client users. 3591 Such authentication is not directly provided by any RPC 3592 authentication flavor. However, RPC-based transports, when suitably 3593 configured, can provide this authentication. 3595 NFSv4.1 defines a number of ways to provide appropriate authorization 3596 facilities. These will not be discussed in detail here but the 3597 following points should be noted: 3599 * NFSv4.1 defines the MACHCRED mechanism which uses the RPCSEC_GSS 3600 infrastructure to provide authentication of the clients peer. 3601 However, this is of no value when AUTH_SYS is being used. 3603 * NFSv4.1 also defines the SSV mechanism which uses the RPCSEC_GSS 3604 infrastructure to enable it to be reliably determined whether two 3605 different client connections are connected to the same client. It 3606 is unclear whether the word "authentication" is appropriate in 3607 this case. As with MACHCRED, this is of no value when AUTH_SYS is 3608 being used. 3610 * Because of the lack of support for AUTH_SYS and for NFSv4.0, it is 3611 quite desirable for clients to use and for servers to require the 3612 use of client-peer authentication as part of connection 3613 establishment. 3615 When unauthenticated clients are allowed, their state is exposed to 3616 unwanted modification as part of disruption or denial-of-service 3617 attacks. As a result, the potential burdens of such attacks are felt 3618 principally by clients who choose not to provide such authentication. 3620 12. Other Uses of Access Control Lists 3622 Whether the acl or sacl attributes are used, AUDIT and ALARM ACEs 3623 provide security-related facilities separate from the the file access 3624 authorization provide by ALLOw and DENY ACEs 3626 * AUDIT ACEs provide a means to audit attempts to acess specified 3627 file by specified sets of principals. 3629 * ALARM ACEs provide a means to draw special attention to attempts 3630 to acess specified files by specified sets of principals. 3632 12.1. V4.1 Attribute 59: sacl 3634 The sacl attribute is like the acl attribute, but sacl allows only 3635 AUDIT and ALARM ACEs. The sacl attribute supports automatic 3636 inheritance (see Section 5.10). 3638 13. Identification and Authentication 3640 Various objects and subjects need to be identified for a protocol to 3641 function. For it to be secure, many of these need to be 3642 authenticated so that incorrect identification is not the basis for 3643 attacks. 3645 13.1. Identification vs. Authentication 3647 It is necessary to be clear about this distinction which has been 3648 obscured in the past, by the use of the term "RPC Authentication 3649 Flavor" in connection with situation in which identification without 3650 authentication occurred or in which there was neither identification 3651 nor authentication involved. As a result, we will use the term "RPC 3652 Flavors" instead 3654 13.2. Items to be Identified 3656 Some identifier are not security-relevant and can used be used 3657 without authentication, given that, in the authorization decision, 3658 the object acted upon needs only to be properly identified 3660 * File names are of this type. 3662 Unlike the case for some other protocols, confusion of names that 3663 result from internationalization issues, while an annoyance, are 3664 not relevant to security. If the confusion between LATIN CAPITAL 3665 LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file 3666 being accessed, the mechanisms described in Section 7 prevent in 3667 appropriate access being granted. 3669 Despite the above, it is desirable if file names together with 3670 similar are not transferred in the clear as the information 3671 exposed may give attackers useful information helpful in planning 3672 and executing attacks. 3674 * The case of file handles is similar. 3676 Identifiers that refer to state shared between client and server can 3677 be the basis of disruption attacks since clients and server 3678 necessarily assume that neither side will change the state corpus 3679 without appropriate notice. 3681 While these identifiers do not need to be authenticated, they are 3682 associated with higher-level entities for which change of the state 3683 represented by those entities is subject to peer authentication. 3685 * Unexpected closure of stateids or changes in state sequence values 3686 can disrupt client access as no clients have provision to deal 3687 with this source of interference. 3689 While encryption may make it more difficult to execute such 3690 attacks attackers can often guess stateid's since server generally 3691 not randomize them. 3693 * Similarly, modification to NFSv4.1 session state information can 3694 result in confusion if an attacker changes the slot sequence by 3695 assuring spurious requests. Even if the request is rejected, the 3696 slot sequence is changed and clients may a difficult time getting 3697 back in sync with the server. 3699 While encryption may make it more difficult to execute such 3700 attacks attackers can often guess slot id's and obtain sessinid's 3701 since server generally do not randomize them. 3703 it is necessary that modification of the higher-levell entities be 3704 restricted to the client that created them. 3706 * For NFSv4.0, the relevant entity is the clientid. 3708 * for NFSv4.1, the relevant entity is the sessionid. 3710 Identifiers describing the issuer of the request, whether in numeric 3711 or string form always require authentication. 3713 13.3. Authentication Provided by specific RPC Flavors 3715 Different flavors differ quite considerably, as discussed below; 3717 * When AUTH_NONE is used, the user making the request is neither 3718 authenticated nor identified to the server. 3720 Also, the server is not authenticated to the client and has no way 3721 to determine whether the server it is communicating with is an 3722 imposter. 3724 * When AUTH_SYS is used, the user making is the request identified 3725 but there no authentication of that identification. 3727 As in the previous case, the server is not authenticated to the 3728 client and has no way to determine whether the server it is 3729 communicating with is an imposter. 3731 * When RPCSEC_GSS is used, the user making the request is 3732 authenticated as is the server peer responding. 3734 13.4. Authentication Provided by the RPC Transport 3736 Different transports differ quite considerably, as discussed below. 3737 In contrast to the case of RPC flavors, any authentication happens 3738 once, at connection establishment, rather than on each RPC request. 3739 As a result, it is the client and server peers, rather than 3740 individual users that is authenticated. 3742 * For most transports, such as TCP and RPC-over-RDMA version 1, 3743 there is no provision for peer authentication. 3745 As a result use of AUTH_SYS together with such transports is 3746 inherently problematic. 3748 * Some transports provide for the possibility of mutual peer 3749 authentication. 3751 14. Security of Data in Flight 3753 14.1. Data Security Provided by the Flavor-associated Services 3755 The only flavor providing these facilities is RPCSEC_GSS. When this 3756 flavor is used, data security can be negotiated between client and 3757 server as described in Section 15.2. However, when data security is 3758 provided at the transport level, as described in Section 14.2, the 3759 negotiation of privacy and integrity support is unnecessary, 3761 Other flavors, such as AUTH_SYS and AUTH_NONE have no such data 3762 security facilities. When these flavor are used, the only data 3763 security is provided by the transport. 3765 14.2. Data Security Provided by the RPC Transport 3767 Some transports provide data security for all transactions performed 3768 on them, eliminating the need for that security to be provided or 3769 negotiated by the selection of particular flavors, mechanism, or 3770 services. 3772 15. Security Negotiation 3774 [Author Aside]: All unannotated paragraphs in this section are 3775 considered to b part of Consensus Item #32a 3777 As previously in NFSv4, we use the term "negotiation" to characterize 3778 the process of the server providing a set of options and the client 3779 selecting one. 3781 The use of SECINFO, possibly with SECINFO_NONAME, remains the primary 3782 means by which the security parameters are determined. The addition 3783 of transports to flavors in providing security has resulted in the 3784 following changes: 3786 * Transport-related security choices are typically decided at 3787 connection-establishment so there needs to be provision for 3788 negotiation at this point. 3790 * Despite the above, because the choices of flavor and transport 3791 affect one another, SECINFO has been extended by the addition of 3792 pseudo-flavors, while retaining the existing XDR, to allow 3793 negotiation of transport choices and accompanying connection 3794 establishment options, in addition to selection of flavors and 3795 accompanying services. This allows server policies for such 3796 matters to be different for different portions of the namespace. 3798 15.1. Flavors and Pseudo-flavors 3800 [Author Aside]: All unannotated paragraphs in this section are 3801 considered to be part of Consensus Item #32b 3803 The flavor field of the secinfo4 items returned by SECINFO and 3804 SECINO_NONAME have always allowed pseudo flavors to be included. 3805 However, previous treatments of these operations have not provided 3806 information about how responses containing such pseudo-flavors are to 3807 be interpreted. 3809 Those pseudo-flavors now provide a means of extending the negotiation 3810 process so it is capable of providing for the negotiation of the use 3811 particular RPC transports and security-related options for the 3812 connections established using those transports. 3814 The flavors AUTH_NONE, AUTH_SYS and RPCSEC_GSS continue to indicate 3815 the acceptability of the corresponding method of user authentication, 3816 user identification, or user non-identification, when used with a 3817 particular RPC transport. 3819 The flavor AUTH_TLS, which is not used as part of issuing requests is 3820 not included in this list and is treated as a connection-type- 3821 specifying pseudo-flavor. 3823 secinfo4s for the flavor RPCSEC_GSS contains additional information 3824 describing the specific security algorithm to be used and the 3825 ancillary services to be provided (e.g. integrity, privacy) when 3826 these services are not provided by the transport. 3828 Such flavors are referred to as "identification-specifying flavors" 3829 The classification below organizes the flavors and pseudo-flavors 3830 used in security negotiation while Section 15.4 describes how the set 3831 of secinfos in a response can be used by the client to select 3832 acceptable combinations of security flavor, security mechanism, 3833 security services, security-related transports, and security-related 3834 connection characteristics. 3836 * The pseudo-flavors designating a particular transport type such as 3837 XPT_TCP or XPT_RDMA. 3839 These pseudo-flavors are referred to as "transport- specifying 3840 flavors". 3842 * The pseudo-flavors designating restrictions on acceptable 3843 connection characteristics include XPCH_ENCRYPT, XPCH_PEERAUTH, 3844 and XPCH_SECURE. 3846 Such pseudo-flavors are referred to as "transport-restriction 3847 pseudo-flavors". 3849 * The pseudo-flavors denoting sets of allowable connection types. 3850 While many connection types are designated by a combination of a 3851 flavor designating a transport with on designating a set of 3852 connection characteristics, there are pseudo-flavors, called 3853 "conection-type pseido-flavror that designate a a set of 3854 connection types directly. 3856 These include the flavor AUTH_TLS which is equivalent to XP_TCP 3857 combined with XPCH_ENCRYPT, and the pseudo-flavor XP_TCP_SECURE 3858 equivalent to XP_TCP combined with XPCH_SECURE. 3860 * The special pseudo-flavors, XPBREAK, XPCLEAR and XPCURRENT 3862 15.2. Negotiation of Security Flavors and Mechanisms 3864 [Author Aside]: All unannotated paragraphs in this section are 3865 considered to be part of Consensus Item #32c 3867 For the current connection, this proceeds as it has previously, when 3868 security-relevant transports were not available. Flavor entries, 3869 including those including mechanism information are listed in order 3870 of server preference and apply, by default, to the current 3871 connection, which is normally is favored by the server. 3873 When other transport-identifying pseudo-flavors appear before the 3874 flavor entries, then the server is indicating that these transport 3875 types are also acceptable, with the server preference following the 3876 ordering of the entries. In this case, any flavor entries that 3877 follow a transport entry specify that those flavor are usable with 3878 the transport types or connection types denoted by that transport 3879 entry. 3881 15.3. Negotiation of RPC Transports and Characteristics 3883 [Author Aside]: All unannotated paragraphs in this section are 3884 considered to be part of Consensus Item #32d 3886 First we define some necessary terminology. 3888 * A transport-specifying pseudo-flavor specifies one of a small set 3889 of RPC transport types such as TCP or RDMA. There are also 3890 pseudo-flavors that specify a set of transport types such as 3891 XPT_ALL. 3893 * Connection characteristics are designations of security-relevant 3894 characteristics or sets of characteristics that connections might 3895 have. 3897 There are pseudo-flavors associated with connection 3898 characteristics such as XPCH_CLPEERAUTH, denoting client-peer 3899 authentication and XPCH_ENCRYPT, denoting the presence of an 3900 encrypted channel. The pseudo-flavor XPCH_SECURE denotes the 3901 presence of peer mutual authentication together with the use of an 3902 encrypted channel. 3904 * The combination of a transport type with a set of connection 3905 characteristics is considered a connection type. While many 3906 connection types are designated by a combination of a flavor 3907 designating a transport with on designating a set of connection 3908 characteristics, there are pseudo-flavors that designate a set of 3909 connection types directly. 3911 For example, the flavor AUTH_TLS is equivalent to XP_TCP combined 3912 with XPCH_ENCRYPT and XPCH_CLPEERAUTH while the pseudo-flavor 3913 XP_TCP_SECURE equivalent to XP_TCP combined with CONCH_SECURE. 3915 * A flavor specification designates a specific flavor, or, in the 3916 case of RPCSEC_GSS, a flavor combined with additional mechanism 3917 and service information. 3919 * A flavor assignment denotes the association of a specific flavor 3920 specification with a connection type. 3922 A secinfo response will designate a set of valid flavor assignments 3923 with an implied server ordering derived from the order that the 3924 entries appear in. 3926 In interpreting the response array the client is to maintain sets of 3927 designated transport types, connection characteristics and connection 3928 types specified individually (i.e. without separately specifying 3929 transport types and connection characteristics). When a flavor 3930 specification is encountered, that flavor is considered valid when 3931 used with all currently active connection types, defined by the union 3932 of the individually specified connection types and the Cartesian 3933 product of the current transport types and current connection types. 3935 The presumed ordering of these assignments is as follows: 3937 * When one of the connection types was specified directly by a 3938 connection type, the position of that specification is compared to 3939 that of either the other individually-specified connection type or 3940 the earlier of the transport-type specification and the connection 3941 characteristics specification. 3943 * In other cases, the position of the transport type specifications 3944 are considered first withe the position of the connection 3945 characteristics considered if necessary. 3947 * If neither of the above resolve issue, the position of the flavor 3948 specification is considered. 3950 * The type of the current connection is considered to be specified 3951 first, implicitly. 3953 * There are provisions, described in Section 15.4 to modify this 3954 ordering, as may be necessary, for example, when the current 3955 connection, while acceptable is, of lower server preference. 3957 15.4. Overall Interpretation of SECINFO Response Arrays 3959 [Author Aside]: All unannotated paragraphs in this section are 3960 considered to be part of Consensus Item #32e. 3962 This section summarizes the processing necessary on the client to 3963 interpret the response to a SECINFO or SECINFO_NONAME request and 3964 determine, at the specified part of the server's namespace: 3966 * The set of transport types acceptable to the server. 3968 * The set of connection types acceptable to the server. 3970 * For each acceptable connection type, the set of flavors acceptable 3971 to the server. 3973 * For each acceptable connection type for which encryption is not 3974 provided and for which the flavor RPCSEC_GSS is accepted, a set of 3975 services to be required when using the flavor on connections of 3976 that type. 3978 For each of the items for which the set of acceptable elments has 3979 more than one element, the server's preference order can be 3980 communicated to the client. 3982 This section provides the same information as Sections 15 through 3983 15.3 but the presentation is in the form of an algorithm. 3985 The algorithm needs to maintain the following information as part of 3986 the context shared with the operations defined in Sections 15.4.2 and 3987 15.4.3 3989 * The ordered set of currently specified transport types. 3991 Because of the need to retain ordering information, a mask cannot 3992 be used to represent this. 3994 Because duplicates are not allowed, the size of this data can be 3995 limited, based on the number of valid transport types. 3997 The initial value is the empty list. 3999 * An array of sets of current transport restrictions. 4001 Since there are three possible transport characteristics: 4002 encryption, client-peer authentication, and server-peer 4003 authentication, a given connection may have eight possible states 4004 and a set of allowed characteristics represented by an eight-bit 4005 mask of allowed combinations of chaacteristics. 4007 The initial value is a single entry with all bits set, indicating 4008 no current restrictions. 4010 * The ordered set of additional connection types, beyond the 4011 Cartesian product of the current sets of transport types and of 4012 connection restrictions. 4014 Each entry consists of a transport type together with a connection 4015 characteristics mask. 4017 The initial value is a single-entry list whose only entry consists 4018 of the transport type of the current connection combined with a 4019 set of transport characteristics in effect for the current 4020 connection and no other possibilities. 4022 * The pseudo-flavor most previously processed. 4024 When this is not one of the special pseudo-flavors, the pseudo- 4025 flavor type is sufficient. 4027 The initial value is transport-restriction pseudo-flavor type 4028 reflecting the fact that the state of the current connection is 4029 the initial basis for flavor specification. 4031 * The output list showing, in order, the combinations of connection 4032 types combined with flavors, or, in the case of RPCSEC_GSS, of 4033 flavor triples. 4035 15.4.1. Interpretation of SECINFO Response Arrays (Core) 4037 [Author Aside]: This preliminary section, which is currently 4038 incomplete, is considered Consensus Item #49a. 4040 [Author Aside]: There are problems with the indenting in this 4041 section. This may be due to to an xml2rfc bug or I may be using ul 4042 incorrectly, or both. Will try to fix this for the next draft. 4044 Processing of the response proceeds through each secinfo4 in the 4045 response. For each such entry, the flavor value, which may be a 4046 pseudo-flavor, controls what is to be done. 4048 The current entry is fetched. 4050 The pseudo-flavor for that entry controls what is done next. 4052 If the pseudo-flavor specifies a transport type or a set of 4053 transport types, the following is done: 4055 If the previous pseudo-flavor was not a transport-specifying 4056 flavor, 4058 Connection type expansion, as described in Section 15.4.2 4059 is performed. 4061 If the flavor designates a single transport type, 4063 The connection type is added to the current list, if it 4064 is not already present in the list. 4066 Otherwise, each included transport type is added to the 4067 list in turn. 4069 If the pseudo-flavor specifies a connection restriction, the 4070 following is done: 4072 If the previous pseudo-flavor was not a transport-specifying 4073 flavor, is not a restriction-specifying flavor and is not 4074 XPBREAK, 4076 Connection type expansion, as described in Section 15.4.2 4077 is performed. 4079 If the previous pseudo-favor was XPBREAK, 4081 A new restriction entry, initialized with all bits one, 4082 is added to the list. 4084 In any case, the newly-specified restrictions are anded with 4085 the last entry in the list. 4087 If the pseudo-flavor specifies a set of connection types or is 4088 XPCURRENT, the following is done: 4090 Inoformation specified by the current flavor is added to the 4091 list of additional connection types, if that same set of 4092 connection type is not already present. 4094 If the pseudo-flavor is XPBREAK, 4096 Nothing specific is done at this point. 4098 If the pseudo-flavor is XPCLEAR, 4100 The set of data maintained by algorithm, including the 4101 flavor output is reset to its initial state. 4103 In addition the set of additional connection types is 4104 cleared to empty state, i.e. information about the current 4105 connection is removed. 4107 If the pseudo-flavor is an authentication flavor, 4109 Flavor expansion, as described in Section 15.4.3 is 4110 performed to combine the current flavor or flavor triple 4111 with each of the currently specified connection types. 4113 Then the current pseudo-flavor is saved as the previous pseudo- 4114 flavor. 4116 We then move on to the next entry. 4118 15.4.2. Connection Type Transcription 4120 [Author Aside]: This section will be provided in a later draft as 4121 part of Consensus Item #48a. 4123 15.4.3. Flavor Transcription 4125 [Author Aside]: This section will be provided in a later draft as 4126 part of Consensus Item #48b. 4128 15.5. SECINFO 4130 [Author Aside]: All unannotated paragraphs in this section are 4131 considered to be part of Consensus Item #33a. 4133 The description in the sub-sections below, while it adheres to the 4134 XDR appearing [6], [7], [8], [9] and [11]. will supersede the 4135 descriptions in [7] and [8]. 4137 This is necessary to adapt the security negotiation process to the 4138 presence of transport-level security services such as encryption and 4139 peer authentication. 4141 Similar changes are necessary in the parallel SECINFO_NONAME 4142 operation introduced in NFSv4.1. These are expected to be done as 4143 part of the rfc5661bis effort. 4145 15.5.1. SECINFO ARGUMENTS 4147 [Author Aside]: All unannotated paragraphs in this section are 4148 considered to be part of Consensus Item #33b. 4150 struct SECINFO4args { 4151 /* CURRENT_FH: directory */ 4152 component4 name; 4153 }; 4155 Figure 1 4157 15.5.2. SECINFO RESULTS 4159 [Author Aside]: All unannotated paragraphs in this section are 4160 considered to be part of Consensus Item #33c. 4162 /* 4163 * From RFC 2203 4164 */ 4165 enum rpc_gss_svc_t { 4166 RPC_GSS_SVC_NONE = 1, 4167 RPC_GSS_SVC_INTEGRITY = 2, 4168 RPC_GSS_SVC_PRIVACY = 3 4169 }; 4171 struct rpcsec_gss_info { 4172 sec_oid4 oid; 4173 qop4 qop; 4174 rpc_gss_svc_t service; 4175 }; 4177 /* RPCSEC_GSS has a value of '6' - See RFC 2203 */ 4178 union secinfo4 switch (uint32_t flavor) { 4179 case RPCSEC_GSS: 4180 rpcsec_gss_info flavor_info; 4181 default: 4182 void; 4183 }; 4185 typedef secinfo4 SECINFO4resok<>; 4187 union SECINFO4res switch (nfsstat4 status) { 4188 case NFS4_OK: 4189 /* CURRENTFH: consumed */ 4190 SECINFO4resok resok4; 4191 default: 4192 void; 4193 }; 4195 Figure 2 4197 15.5.3. SECINFO DESCRIPTION 4199 [Author Aside]: All unannotated paragraphs in this section are 4200 considered to be part of Consensus Item #33d. 4202 The SECINFO operation is used by the client determine the appropriate 4203 RPC authentication flavors, security mechanisms and encrypting 4204 transports to access a specific directory filehandle, file name pair. 4205 SECINFO should apply the same access approach used for LOOKUP when 4206 evaluating the name. In consequence, if the requester does not have 4207 the appropriate access to LOOKUP the name, then SECINFO will behave 4208 the same way and return NFS4ERR_ACCESS. 4210 The result will contain an array that represents the security flavor, 4211 security mechanisms and transports available, with an order 4212 corresponding to the server's preferences, the most preferred being 4213 first in the array. The client is free to pick whatever security 4214 flavors, mechanisms and transports it both desires and supports, or 4215 to pick in the server's preference order the first one it supports. 4216 The array entries are represented by the secinfo4 structure. The 4217 field 'flavor' will contain one of the following sorts of values: 4219 * a value of AUTH_NONE, AUTH_SYS (as defined in RFC 5531 [4]). 4221 * AUTH_TLS as described in ... 4223 * A pseudo-flavor defined in Section 18.2 4225 * RPCSEC_GSS (as defined in RFC 2203 [2]). 4227 * Any other security flavor or pseudo-flavor registered with IANA. 4229 For the flavors other than RPCSEC_GSS, no additional security 4230 information is returned. For a return value of RPCSEC_GSS, a 4231 security triple is returned that contains the mechanism object 4232 identifier (OID, as defined in RFC 2743 [3]), the quality of 4233 protection (as defined in RFC 2743 [3]), and the service type (as 4234 defined in RFC 2203 [2]). It is possible for SECINFO to return 4235 multiple entries with flavor equal to RPCSEC_GSS with different 4236 security triple values. 4238 On success, the current filehandle is consumed, so that, if the 4239 operation following SECINFO tries to use the current filehandle, that 4240 operation will fail with the status NFS4ERR_NOFILEHANDLE. 4242 If the name has a length of zero, or if the name does not obey the 4243 UTF-8 definition in circumstances in which UTF-8 names are required, 4244 the error NFS4ERR_INVAL will be returned. 4246 See Sections 15.2 through 15.4 for additional information on the use 4247 of SECINFO. 4249 15.5.4. SECINFO IMPLEMENTATION (general) 4251 [Author Aside]: All unannotated paragraphs in this section are 4252 considered to be part of Consensus Item #33e. 4254 The SECINFO operation is expected to be used by the NFS client when 4255 the error value of NFS4ERR_WRONGSEC is returned from another NFS 4256 operation. This signifies to the client that the server's security 4257 policy is different from what the client is currently using. At this 4258 point, the client is expected to obtain a list of possible security 4259 flavors and choose what best suits its policies. 4261 15.5.5. SECINFO IMPLEMENTATION (for NFSv4.0) 4263 [Author Aside]: All unannotated paragraphs in this section are 4264 considered to be part of Consensus Item #34a. 4266 The server's security policies will determine when a client request 4267 receives NFS4ERR_WRONGSEC. The operations that may receive this 4268 error are LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, PUTPUBFH, PUTROOTFH, 4269 RENAME, RESTOREFH, and, indirectly, READDIR. LINK and RENAME will 4270 only receive this error if the security used for the operation is 4271 inappropriate for the saved filehandle. With the exception of 4272 READDIR, these operations represent the point at which the client can 4273 instantiate a filehandle into the current filehandle at the server. 4274 The filehandle is either provided by the client (PUTFH, PUTPUBFH, 4275 PUTROOTFH) or generated as a result of a name-to-filehandle 4276 translation (LOOKUP and OPEN). RESTOREFH is treated differently 4277 because the filehandle is a result of a previous SAVEFH. Even though 4278 the filehandle, for RESTOREFH, might have previously passed the 4279 server's inspection for a security match, the server will check it 4280 again on RESTOREFH to ensure that the security policy has not 4281 changed. 4283 If the client is to resolve an error return of NFS4ERR_WRONGSEC, the 4284 following will occur: 4286 * For LOOKUP and OPEN, the client will use SECINFO with the same 4287 current filehandle and name as provided in the original LOOKUP or 4288 OPEN to determine the acceptable combinations of transport types, 4289 transport restrictions, and flavor-based triple use to make 4290 requests directed at the specified portion of the server 4291 namespace. 4293 * For LINK, PUTFH, RENAME, and RESTOREFH, the client will use 4294 SECINFO and provide the parent directory filehandle and the object 4295 name that corresponds to the filehandle originally provided by the 4296 PUTFH or RESTOREFH, or, for LINK and RENAME, the SAVEFH. 4298 * For LOOKUPP, PUTROOTFH, and PUTPUBFH, the client will be unable to 4299 use the SECINFO operation since SECINFO requires a current 4300 filehandle and none exist for these three operations. Therefore, 4301 the client must iterate through the security triples expected to 4302 be available at the client for use by the current connection (i.e, 4303 because they are REQUIRED and attempt the PUTROOTFH or PUTPUBFH 4304 operation repeatedly, once for each possible triple. In the 4305 unfortunate event that none of the MANDATORY security triples are 4306 supported by the client and server, the client should try using 4307 others that are believed to be available. It is desirable to do 4308 so in a manner which provides encryption or at least integrity 4309 support integrity. Often his will be possible if the connection 4310 is encrypted. In other cases. the client can try using AUTH_NONE, 4311 but because such forms lack integrity checks, there is an element 4312 of risk in doing so. However the risk can be made small if the 4313 server returns NFS4ERR_WRONGSEC when entering any subdirectory of 4314 the root or public filehandle. 4316 The READDIR operation will not directly return the NFS4ERR_WRONGSEC 4317 error. However, if the READDIR request included a request for 4318 attributes, it is possible that the READDIR request's security triple 4319 does not match that of a directory entry. If this is the case and 4320 the client has requested the rdattr_error attribute, the server will 4321 return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. 4322 This will allow SECINFO to be issued for that entry with the same 4323 current file handle as used for the READDIR and a name derived from 4324 the entry for which the error was noted. 4326 [Author Aside]: The following paragraph seems dubious since it would 4327 best if the server tells the client to use, rather than leaving him 4328 to guess, and the server will know what he supports. Would like to 4329 delete this as part of Consensus Item #47a, unless compatibility 4330 issues make that impossible. 4332 [Previous Treatment (Item #47a)]: Note that a server MAY use the 4333 AUTH_NONE flavor to signify that the client is allowed to attempt to 4334 use authentication flavors that are not explicitly listed in the 4335 SECINFO results. Instead of using a listed flavor, the client might 4336 then, for instance, opt to use an otherwise unlisted RPCSEC_GSS 4337 mechanism instead of AUTH_NONE. It may wish to do so in order to 4338 meet an application requirement for data integrity or privacy. In 4339 choosing to use an unlisted flavor, the client SHOULD always be 4340 prepared to handle a failure by falling back to using AUTH_NONE or 4341 another listed flavor. It cannot assume that identity mapping is 4342 supported and should be prepared for the fact that its identity is 4343 squashed. 4345 15.5.6. SECINFO IMPLEMENTATION (for NFSv4.1 and v4.2) 4347 [Author Aside]: All unannotated paragraphs in this section are 4348 considered to be part of Consensus Item #33f. 4350 As mentioned, the server's security policies will determine when a 4351 client request receives NFS4ERR_WRONGSEC. 4353 See Table 14 of [8] for a list of operations that can return 4354 NFS4ERR_WRONGSEC. in the case of v4.2, there might be extensions 4355 allowed to return NFS4ERR_WRONGSEC. In addition, when READDIR 4356 returns attributes, the rdattr_error (Section 5.8.1.12 of [8]) can 4357 contain NFS4ERR_WRONGSEC. 4359 Note that CREATE and REMOVE MUST NOT return NFS4ERR_WRONGSEC. The 4360 rationale for CREATE is that unless the target name exists, it cannot 4361 have a separate security policy from the parent directory, and the 4362 security policy of the parent was checked when its filehandle was 4363 injected into the COMPOUND request's operations stream (for similar 4364 reasons, an OPEN operation that creates the target MUST NOT return 4365 NFS4ERR_WRONGSEC). If the target name exists, while it might have a 4366 separate security policy, that is irrelevant because CREATE MUST 4367 return NFS4ERR_EXIST. The rationale for REMOVE is that while that 4368 target might have a separate security policy, the target is going to 4369 be removed, and so the security policy of the parent trumps that of 4370 the object being removed. RENAME and LINK MAY return 4371 NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error applies only to the 4372 saved filehandle (see Section 2.6.3.1.2 of [8]). Any 4373 NFS4ERR_WRONGSEC error on the current filehandle used by LINK and 4374 RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or 4375 RESTOREFH operation that injected the current filehandle. 4377 With the exception of LINK and RENAME, the set of operations that can 4378 return NFS4ERR_WRONGSEC represents the point at which the client can 4379 inject a filehandle into the "current filehandle" at the server. The 4380 filehandle is either provided by the client (PUTFH, PUTPUBFH, 4381 PUTROOTFH), generated as a result of a name-to-filehandle translation 4382 (LOOKUP and OPEN), or generated from the saved filehandle via 4383 RESTOREFH. As Section 2.6.3.1.1.1 of [8] states, a put filehandle 4384 operation followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC. Thus, 4385 the RESTOREFH operation, under certain conditions (see 4386 Section 2.6.3.1.1 of [8]), is permitted to return NFS4ERR_WRONGSEC so 4387 that security policies can be honored. 4389 The READDIR operation will not directly return the NFS4ERR_WRONGSEC 4390 error. However, if the READDIR request included a request for 4391 attributes, it is possible that the READDIR request's security triple 4392 did not match that of a directory entry. If this is the case and the 4393 client has requested the rdattr_error attribute, the server will 4394 return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. 4396 To resolve an error return of NFS4ERR_WRONGSEC, the client does the 4397 following: 4399 * For LOOKUP and OPEN, the client will use SECINFO with the same 4400 current filehandle and name as provided in the original LOOKUP or 4401 OPEN to enumerate the available security triples. 4403 * For the rdattr_error, the client will use SECINFO with the same 4404 current filehandle as provided in the original READDIR. The name 4405 passed to SECINFO will be that of the directory entry (as returned 4406 from READDIR) that had the NFS4ERR_WRONGSEC error in the 4407 rdattr_error attribute. 4409 * For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the 4410 client will use SECINFO_NO_NAME { style = 4411 SECINFO_STYLE4_CURRENT_FH }. The client will prefix the 4412 SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or 4413 PUTROOTFH operation that provides the filehandle originally 4414 provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH 4415 operation. 4417 NOTE: In NFSv4.0, the client was required to use SECINFO, and had 4418 to reconstruct the parent of the original filehandle and the 4419 component name of the original filehandle. The introduction in 4420 NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction. 4422 * For LOOKUPP, the client will use SECINFO_NO_NAME { style = 4423 SECINFO_STYLE4_PARENT } and provide the filehandle that equals the 4424 filehandle originally provided to LOOKUPP. 4426 16. Future Security Needs 4428 [Author Aside]: All unannotated paragraphs in this section are 4429 considered part of Consensus Item #35a. 4431 [Author Aside]: This section is basically an outline for now, to be 4432 filled out later based on Working Group input, particularly from 4433 Chuck Lever who suggested this section and has ideas about many of 4434 the items in it. 4436 * Security for data-at-rest, most probably based on facilities 4437 defined within SAN. 4439 * Support for content signing. 4441 * Revision/extension of labelled NFS to provide true 4442 interoperability and server-based authorization. 4444 * Work to provide more security for RDMA-based transports. This 4445 would include the peer authentication infrastructure now being 4446 developed as part of RPC-over-RDMA version 2. In addition, there 4447 is a need for an RPC-based transport that provides for encryption, 4448 which might be provided in number of ways. 4450 * Work, via extensions, to provide attributes describing server 4451 behavior to the client. This is likely to have an important role 4452 in resolving security issues connected with ACLs where there is 4453 both a new preferred approach together with legacy implementations 4454 built when the specifications wither offered no preferred approach 4455 or treated that preference as easily dispensed with. 4457 17. Security Considerations 4459 17.1. Changes in Security Considerations 4461 Beyond the needed inclusion of a threat analysis and the fact that 4462 all minor versions are dealt with together, there are a number of 4463 substantive changes in the approach to NFSv4 security presented in 4464 RFCs 7530 and 8881 and that appearing in this document. 4466 This document will not seek to speculate how the previous treatment, 4467 now viewed as incorrect, came to be written, approved, and published. 4468 However, it will, for the benefit of those familiar with the previous 4469 treatment of these matters, draw attention to the important changes 4470 listed here. 4472 * There is a vastly expanded range of threats being considered as 4473 described in Section 17.1.1 4475 * New facilities available at the RPC transport level can be used to 4476 deal with security issues, as described in Section 17.1.2 4478 17.1.1. Wider View of Threats 4480 Although the absence of a threat analysis in previous treatments 4481 makes comparison most difficult, the security-related features 4482 described in previous specifications and the associated discussion in 4483 their security considerations sections makes it clear that earlier 4484 specifications took a quite narrow view of threats to be protected 4485 against. 4487 One aspect of that narrow view that merits special attention is the 4488 handling of AUTH_SYS, at that time in the clear, with no client peer 4489 authentication. 4491 With regard to specific threats, there is no mention in existing 4492 security consideration sections of: 4494 * Denial-of-service attacks. 4496 * Client-impersonation attacks. 4498 * Server-impersonation attacks. 4500 The handling of data security in-flight is even more troubling. 4502 * Although there was considerable work in the protocol to allow use 4503 of encryption to be negotiated when using RPCSEC_GSS. The 4504 existing security considerations do not mention the potential need 4505 for encryption at all. 4507 It is not clear why this was omitted but it is a pattern that 4508 cannot repeated in this document. 4510 * The case of negotiation of integrity services is similar and uses 4511 the same negotiation infrastructure. 4513 In this case, use of integrity is recommended but not to prevent 4514 the corruption of user data being read or written. 4516 The use of integrity services is recommended in connection with 4517 issuing SECINFO (and for NFSv4.1, SECINFO_NONAME). The presence 4518 of this recommendation in the associated security considerations 4519 sections has the unfortunate effect of suggesting that the 4520 protection of user data is of relatively low importance. 4522 17.1.2. Transport-layer Security Facilities 4524 Such transport-level RPC facilities as RPC-over-TLS provide important 4525 ways of proving better security for all the NFSv4 minor versions. 4527 In particular: 4529 * The presence of encryption by default will deal with security 4530 issue regarding data-in-flight, for both RPCSEC_GSS and AUTH_SYS. 4532 * Peer authentication provided by the server eliminates the 4533 possibility of a server-impersonation attack, even when using 4534 AUTH_SYS. 4536 * When mutual authentication is part of connection establishment, 4537 there is a possibility, where an appropriate trust relationship 4538 exists, of treating the userid's presented in AUTH_SYS, as 4539 effectively authenticated, based on the authentication of the 4540 client peer. 4542 17.1.3. Approach to Implementation Semantic Divergences 4544 [Consensus Needed (Items #36a, #37a)]: For a variety of reasons, 4545 there are many cases in which one approach to security is preferred 4546 where others are allowed, if only to give time for implementers to 4547 adapt to the preferred approach. In such cases the word "SHOULD is 4548 used to introduce the preferred while others are allowed to allow 4549 compatibility by limiting the valid reasons to bypass the 4550 recommendation. Such instances fall into two classes: 4552 * [Consensus Needed (Item #36a)]: In adapting to the availability of 4553 security services provided by the RPC transport, allowance has 4554 been made for implementations for which these new transport are 4555 not available and for which, based on previous standards-track 4556 guidance, AUTH_SYS us used, in the clear, without client-peer 4557 authentication. 4559 * [Consensus Needed (Item #37a)]: In dealing with server 4560 implementations that support both ACLs and the mode attribute, 4561 previous specifications have allowed a wide range of possible 4562 server behavior in coordinating these attributes. While now 4563 clearly defining the recommended behavior in dealing with these 4564 issues, allowance has been made to give times for implementations 4565 to conform to the new recommendations. 4567 [Consensus Needed (Items #36a, #37a)]: The threat analysis within 4568 this Security Considerations section will not deal with older servers 4569 for which allowance has been made but will explore the consequences 4570 of the recommendations made in this document. 4572 17.1.4. Compatibility and Maturity Issues 4574 [Author Aside]: All unannotated paragraphs within this section are 4575 considered part of Consensus Item #38a. 4577 Given the need to drastically change the NFSv4 security approach from 4578 that specified previously, it is necessary for us to be mindful of: 4580 * The difficulty that might be faced in adapting to the newer 4581 guidance because the delays involved in designing, developing, and 4582 testing new transport- level security facilities such as RPC-over- 4583 TLS. 4585 * The difficulty in discarding or substantially modifying previous 4586 existing deployments and practices, developed on the basis of 4587 previous normative guidance. 4589 For these reasons, we will not use the term "MUST NOT" in some 4590 situations in which the use of that term might have been justified 4591 earlier. In such cases, previous guidance together with the passage 4592 of time may have created a situation in which the considerations 4593 mentioned above in this section may be valid reasons to defer, for a 4594 limited time, correction of the current situation making the term 4595 "SHOULD NOT" appropriate, since the difficulties cited would 4596 constitute a valid reason to not allow what had been recommended 4597 against. 4599 17.1.5. Discussion of AUTH_SYS 4601 [Author Aside]: All unannotated paragraphs within this section are 4602 considered part of Consensus Item #39a. 4604 An important change concerns the treatment of AUTH_SYS which is now 4605 divided into two distinct cases given the possible availability of 4606 support from the transport layer. 4608 When such support is not available, AUTH_SYS SHOULD NOT be used, 4609 since it makes the following attacks quite easy to execute: 4611 * The absence of authentication of the server to the client allow 4612 server impersonation in which an imposter server can obtain data 4613 to be written by the user and supply corrupted data to read 4614 requests. 4616 * The absence of authentication of the client user to the server 4617 allow server impersonation in which an imposter client can issue 4618 requests and have them executed as a user designated by imposter 4619 client, vitiating the server's authorization policy. 4621 With no authentication of the client peer, common approaches, such 4622 as using the source IP address can be easily defeated, allowing 4623 unauthenticated execution of requests made by the pseudo clients 4625 * The absence of any support to protect data-in-flight when AUTH_SYS 4626 is used result in further serious security weaknesses. 4628 In connection with the use of the term "SHOULD NOT" above, it is 4629 understood that the "valid reasons" to use this form of access 4630 reflect the Compatibility and Maturity Issue discussed above in 4631 Section 17.1.4 and that it is expected that, over time, these will 4632 become less applicable. 4634 17.2. Security Considerations Scope 4636 17.2.1. Discussion of Potential Classification of Environments 4638 [Author Aside]: All unannotated paragraphs within this section are 4639 considered part of Consensus Item #40a. 4641 This document will not consider different security policies for 4642 different sorts of environments. This is because, 4644 * Doing so would add considerable complexity to this document. 4646 * The additional complexity would undercut our main goal here, which 4647 is to discuss secure use on the internet, which remain an 4648 important NFSv4 goal. 4650 * The ubiquity of internet access makes it hard to treat corporate 4651 network separately from the internet per se. 4653 * While small networks might be sufficiently isolated to make it 4654 reasonable use NFSv4 without serious attention to security issues, 4655 the complexity of characterizing the necessary isolation makes it 4656 impractical to deal with such cases in this document. 4658 17.2.2. Discussion of Environments 4660 [Author Aside]: All unannotated paragraphs within this section are 4661 considered part of Consensus Item #40b. 4663 Although the security goal for Nfsv4 has been and remains "secure use 4664 on the internet", much use of NFSv4 occurs on more restricted IP 4665 networks with NFS access from outside the owning organization 4666 prevented by firewalls. 4668 This security considerations section will not deal separately with 4669 such environments since the threats that need to be discussed are 4670 essentially the same, despite the assumption by many that the 4671 restricted network access would eliminate the possibility of attacks 4672 originating inside the network by attackers who have some legitimate 4673 Nfsv4 access within it. 4675 In organizations of significant size, this sort of assumption of 4676 trusted access is usually not valid and this document will not deal 4677 with them explicitly. In any case, there is little point in doing 4678 so, since, if everyone can be trusted, there can be no attackers, 4679 rendering threat analysis superfluous. 4681 This does not mean that NFSv4 use cannot, as a practical matter, be 4682 made secure through means outside the scope of this document 4683 including strict administrative controls on all software running 4684 within it, frequent polygraph tests, and threats of prosecution. 4685 However, this document is not prepared to discuss the details of such 4686 policies, their implementation, or legal issues associated with them 4687 and treats such matters as out-of-scope. 4689 Nfsv4 can be used in very restrictive IP network environments where 4690 outside access is quite restricted and there is sufficient trust to 4691 allow, for example, every node to have the same root password. The 4692 case of a simple network only accessible by a single user is similar. 4693 In such networks, many thing that this document says "SHOULD NOT" be 4694 done are unexceptionable but the responsibility for making that 4695 determination is one for those creating such networks to take on. 4696 This document will not deal further with NFSv4 use on such networks. 4698 17.3. Major New Recommendations 4700 17.3.1. Recommendations Regarding Security of Data in Flight 4702 [Author Aside]: All unannotated paragraphs within this section are 4703 considered part of Consensus Item #41a. 4705 It is RECOMMENDED that requesters always issue requests with data 4706 security (i.e. with protection from disclosure or modification in 4707 flight) whether provided at the RPC request level or by the RPC 4708 transport, irrespective of the responder's requirements. 4710 It is RECOMMENDED that implementers provide servers the ability to 4711 configure policies in which requests without data security will be 4712 rejected as having insufficient security. 4714 it is RECOMMENDED that servers use such policies over either their 4715 entire local namespace or for all file systems except those clearly 4716 designed for the general dissemination of non-sensitive data. 4718 17.3.2. Recommendations Regarding Client Peer Authentication 4720 [Author Aside]: All unannotated paragraphs within this section are 4721 considered part of Consensus Item #41b. 4723 It is RECOMMENDED that clients provide authentication material 4724 whenever a connection is established with a server capable of using 4725 it to provide client peer authentication. 4727 It is RECOMMENDED that implementers provide servers the ability to 4728 configure policies in which attempts to establish connections without 4729 client peer authentication will be rejected. 4731 it is RECOMMENDED that servers adopt such policies whenever requests 4732 not using RPCSEC_GSS are allowed to be executed. 4734 17.3.3. Issues Regarding Valid Reasons to Bypass Recommendations 4736 [Author Aside]: All unannotated paragraphs within this section are 4737 considered part of Consensus Item #41c. 4739 Clearly, the maturity and compatibility issues mentioned in 4740 Section 17.1.4 are valid reasons to bypass the above recommendations, 4741 as long as these issues continue to exist. 4743 [Author Aside]: The question the working group needs to address is 4744 whether other valid reasons exist. 4746 [Author Aside]: In particular, some members of the group might feel 4747 that the performance cost of encrypted transports constitutes, in 4748 itself, a valid reason to ignore the above recommendations. 4750 [Author Aside]: I cannot agree and feel that accepting that as a 4751 valid reason would undercut Nfsv4 security improvement, and probably 4752 would not be acceptable to the security directorate. However, I do 4753 want to work out an a generally acceptable compromise. I propose 4754 something along the following lines: 4756 In dealing with these issues it needs to be understood that the 4757 transport-based encryption facilities are designed to be compatible 4758 with facilities to offload the work of encryption and decryption. 4759 When such facilities are not available, at a reasonable cost, to 4760 NFSv4 servers and clients anticipating heavy use of NFSv4, then the 4761 lack of such facilities can be considered a valid reason to bypass 4762 the above recommendations, as long as that situation continues. 4764 17.4. Data Security Threats 4766 Will be addressed in a later draft as part of Consensus Item #42a. 4768 17.5. Authentication-based threats 4770 17.5.1. Attacks based on the use of AUTH_SYS 4772 Will be addressed in a later draft as part of Consensus Item #43a. 4774 17.5.2. Attacks on Name/Userid Mapping Facilities 4776 Will be addressed in a later draft as part of Consensus Item #44a. 4778 17.6. Disruption and Denial-of-Service Attacks 4780 17.6.1. Attacks Based on the Disruption of Client-Server Shared State 4782 Will be addressed in a later draft as part of Consensus Item #45a. 4784 17.6.2. Attacks Based on Forcing the Misuse of Server Resources 4786 Will be addressed in a later draft as part of Consensus Item #46a. 4788 18. IANA Considerations 4790 [Author Aside]: All unannotated paragraphs in this section are to be 4791 considered part of Consensus Item #33f. 4793 Because of the shift from implementing security-related services only 4794 in connection with RPCSEC_GSS to one in which transport-level 4795 security has a prominent role, a number if new values need to be 4796 assigned. 4798 These include new authstat values to guide selection of a Transports 4799 acceptable to both client and server, presented in Section 18.1 and 4800 new pseudo-flavors to be used in the process of security negotiation, 4801 presented in Section 18.2. 4803 18.1. New Authstat Values 4805 [Author Aside]: All unannotated paragraphs in this section are to be 4806 considered part of Consensus Item #33g. 4808 The following new authstat values are necessary to enable a server to 4809 indicate that the server's policy does not allows requests to be made 4810 on the current connection because of security issues associated with 4811 the rpc transport. In the event they are received, the client needs 4812 to establish a new connection. 4814 * The value XP_CRYPT indicates that the server will not support 4815 access using unencrypted connections while the current connection 4816 is not encrypted. 4818 * The value XP_CPAUTH indicates that the server will not support 4819 access using connections for which the client peer has not 4820 authenticated itself as part of connection while the current 4821 connection has not been set up in that way. 4823 18.2. New Authentication Pseudo-Flavors 4825 [Author Aside]: All unannotated paragraphs in this section are to be 4826 considered part of Consensus Item #33h. 4828 The new pseudo-flavors described in this section are to be made 4829 available to allow their return as part of the response to SECINFO 4830 operation described in Section 15.5 and for similar operations. 4832 The following transport-specifying flavors are to be defined: 4834 * XPT_TCP denotes use of a TCP transport to support to RPC. The use 4835 of TLS as provided by RPC-with-TLS is orthogonal to the transport 4836 type, as is the use of optional authentication features. Such 4837 facilities are treated as transport characteristics. 4839 When RDMA support is layered on TCP, that fact is not relevant to 4840 the transport type, which is still XPT_RDMA. 4842 * XPT_RDMA denotes use of any version of RPC-over-RDMA to support 4843 RPC. Although Version 1 has no security-support, future version 4844 may have such facilities. 4846 In any case, the specification of the presence or need for such 4847 facilities are handled as transport characteristics. 4849 * XPT_ALL is currently equivalent to XPT_TCP followed by XPT_RDMA. 4850 When new transport types are made available for use wit NFSv4, it 4851 is intended that 4853 The following transport-restricting flavors are to be defined: 4855 * XPCH_ENCRYPT restrict connections to those providing encryption. 4857 * XPCH_SVRAUTH restricts connections allowed to those that provide, 4858 at connection time authentication of the server peer. 4860 * XPCH_CLAUTH restricts connections allowed to those that provide, 4861 at connection time authentication of the server peer. 4863 * XPCH_PEERAUTH is equivalent to XPCH_SVRAUTH combined with 4864 XPCH_CLAUTH. 4866 * XPCH_SECURE is equivalent to XPCH_ENCRYPT combined with 4867 XPCH_PEERAUTH. 4869 The follow connection-specifying flavors are to be defined: 4871 * AUTH_TLS is equivalent to XP_TCP combined with XPCH_ENCRYPT and 4872 XPCH_CLPEERAUTH 4874 * XP_TCP_SECURE is equivalent to XP_TCP combined with XPCH_SECURE. 4876 The following special flavors are to be defined: 4878 * XPCLEAR reset the state of processing to an empty state. This is 4879 useful if the current connection type is not usable for the 4880 specified region of the namespace or if it is of lower server 4881 preference. 4883 * XPBREAK forces the use of a new set transport restrictions, 4884 separate from previous ones and applying to the same set of 4885 transport types. 4887 * XPCURRENT specifies that the type of the current connection is 4888 usable for access, with the preference derived from its location 4889 in the SECINFO response array. 4891 19. References 4893 19.1. Normative References 4895 [1] Bradner, S., "Key words for use in RFCs to Indicate 4896 Requirement Levels", BCP 14, RFC 2119, 4897 DOI 10.17487/RFC2119, March 1997, 4898 . 4900 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 4901 Specification", RFC 2203, DOI 10.17487/RFC2203, September 4902 1997, . 4904 [3] Linn, J., "Generic Security Service Application Program 4905 Interface Version 2, Update 1", RFC 2743, 4906 DOI 10.17487/RFC2743, January 2000, 4907 . 4909 [4] Thurlow, R., "RPC: Remote Procedure Call Protocol 4910 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 4911 May 2009, . 4913 [5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4914 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4915 May 2017, . 4917 [6] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 4918 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 4919 March 2015, . 4921 [7] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 4922 (NFS) Version 4 External Data Representation Standard 4923 (XDR) Description", RFC 7531, DOI 10.17487/RFC7531, March 4924 2015, . 4926 [8] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 4927 Version 4 Minor Version 1 Protocol", RFC 8881, 4928 DOI 10.17487/RFC8881, August 2020, 4929 . 4931 [9] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 4932 "Network File System (NFS) Version 4 Minor Version 1 4933 External Data Representation Standard (XDR) Description", 4934 RFC 5662, DOI 10.17487/RFC5662, January 2010, 4935 . 4937 [10] Haynes, T., "Network File System (NFS) Version 4 Minor 4938 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 4939 November 2016, . 4941 [11] Haynes, T., "Network File System (NFS) Version 4 Minor 4942 Version 2 External Data Representation Standard (XDR) 4943 Description", RFC 7863, DOI 10.17487/RFC7863, November 4944 2016, . 4946 [12] Myklebust, T. and C. Lever, "Towards Remote Procedure Call 4947 Encryption By Default", Work in Progress, Internet-Draft, 4948 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 4949 . 4952 19.2. Informative References 4954 [13] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 4955 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 4956 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 4957 October 2017, . 4959 Appendix A. Changes Made 4961 This section summarizes the substantive changes between the treatment 4962 of security in previous minor version specification documents (i.e. 4963 RFCs 7530 and 8881) and the new treatment applying to NFSv4 as a 4964 whole. 4966 This is expected to be helpful to implementers familiar with previous 4967 specifications but also has an important role in verifying the 4968 working group consensus for these changes and in guiding the search 4969 for potential compatibility issues. 4971 A.1. Motivating Changes 4973 A number of changes reflect the basic motivation for a new treatment 4974 of NFSv4 security. These include the ability to obtain privacy and 4975 integrity services from the RPC transport rather than as a service 4976 ancillary to a specific authentication flavor. 4978 This motivated a major reorganization of the treatment of security 4979 together with a needed emphasis on the security of data in flight. 4980 In addition, the security negotiation framework for NFSv4 has been 4981 significantly enhanced to support the combined negotiation of 4982 authentication-related services and transport characteristics. 4984 Despite these major changes there are not expected to be 4985 compatibility issues between peers supporting secure transport 4986 characteristics and those without such support. 4988 Another such change was in the treatment of AUTH_SYS, previously 4989 described, inaccurately, as an "OPTIONAL means of authentication" 4990 with the unfortunate use of the RFC2119 keyword obscuring the 4991 negative consequences of the typical use of AUTH_SYS (in the clear; 4992 without client-peer authentication) for security by enabling the 4993 execution of unauthenticated requests. 4995 The new treatment avoids the inappropriate use of term 4996 "authentication" for all activities triggered by the use of RPC 4997 authentication flavors and clearly distinguishes those flavors 4998 providing authentication from those providing identification only or 4999 neither identification nor authentication. 5001 A.2. Other Major Changes 5003 The need to make the major changes discussed in Appendix A.1 has 5004 meant that much text dealing with security has needed to be 5005 significantly revised or rewritten. As a result of the process, may 5006 issues involving unclear, inconsistent, or otherwise inappropriate 5007 text were uncovered and needed to be dealt with. 5009 While the author believes such changes are necessary, the fact that 5010 we are changing a document adopted by consensus requires the working 5011 group to be clear about the acceptability of the changes. This 5012 applies to both the troublesome issues discussed in Section 3.4 and 5013 to the other changes included below. 5015 Because of concurrent re-organizations, the ordering of the list 5016 follows the text of the current version which may differ considerably 5017 from that in earlier versions of the I-D. 5019 * In order to deal better with the fact that ACLs have multiple uses 5020 some significant structural changes have been made. 5022 Section 5, a new top-level section describes the the structure of 5023 ACLs, 5025 * In Section 7.2, makes clear that owner and owner group are 5026 essentially REQUIRED attributes. 5028 * Also in Section 7.2, there is added clarity in the discussion of 5029 support for multiple authorization approaches by eliminating use 5030 of the subjective term "reasonable semantics". 5032 In connection with this clarification, we have switched from 5033 describing the needed co-ordination between modes and acls as 5034 "goals" to describing them as "requirements" to give clients some 5035 basis for expecting interopherability in handling these issues. 5037 As a result of this shift to a prescriptive framework applying to 5038 all minor versions it becomes possible to treat all minor versions 5039 together. In earlier versions of this document, it had been 5040 assumed that NFSv4.0 was free to ignore the relevant prescriptions 5041 first put forth in RFC 5661 and only needed to address the "goals" 5042 for this co-ordination. 5044 Appendix B. Issues for which Consensus Needs to be Ascertained 5046 The section helps to keep track of specific changes which the author 5047 has made or intends to make to deal with issues found in RFCs 7530 5048 and 7881. The changes listed here exclude those which are clearly 5049 editorial but includes some that the author believes are editorial 5050 but for which the issues are sufficiently complicated that working 5051 group consensus on the issue is probably necessary. 5053 These changes are presented in the table below, organized into a set 5054 of "Consensus Items" identified by the numeric code appearing in 5055 annotations in the proposed document text. For each such item, a 5056 type code is assigned with the following codes defined: 5058 * "NM" denotes a change which is new material that is not purely 5059 editorial and thus requires Working Group consensus for eventual 5060 publication. 5062 * "BE" denotes a change which the author believes is editorial but 5063 for which the change is sufficiently complex that the judgment is 5064 best confirmed by the Working Group. 5066 * "BC" denotes a change which is a substantive change that the 5067 author believes is correct. This does not exclude the possibility 5068 of compatibility issues becoming an issue but is used to indicate 5069 that the author believes any such issues are unlikely to prevent 5070 its eventual acceptance. 5072 * "CI" denotes a change for which the potential for compatibility 5073 issues is major concern with the expected result that working 5074 group discussion of change will focus on clarifying our knowledge 5075 of how existing clients and server deal with the issue and how 5076 they might be affected by the change or the change modified to 5077 accommodate them. 5079 * "NS" denotes a change which represents the author's best effort to 5080 resolve a difficulty but for which the author is not yet confident 5081 that it will be adopted in its present form, principally because 5082 of the possibility of troublesome compatibility issues. 5084 When the document is promoted to a working group document, there 5085 should be very few issues in this state and, for each such issue, 5086 a clear plan to address the possibility of any compatibility 5087 problems, enabling resolution of the issue to be reasonably 5088 anticipated. 5090 * "NE" denotes change based on an existing issue in the spec but for 5091 which the replacement text is incomplete and needs further 5092 elaboration. 5094 There will be no changes in this state when promotion to a working 5095 group document is requested. 5097 * "WI" denotes a potential change based on an existing issue in the 5098 spec but for which replacement text is not yet available because 5099 further working group input is necessary before drafting. It is 5100 expected that replacement text will be available in a later draft 5101 once that discussion is done. 5103 There will be no changes in this state when promotion to a working 5104 group document is requested. 5106 * "LD" denotes a potential change based on an existing issue in the 5107 spec but for which replacement text is not yet available due to 5108 the press of time. It is expected that replacement text will be 5109 available in a later draft. 5111 There will be no changes in this state when promotion to a working 5112 group document is requested. 5114 When asterisk is appended to a state of "NM", "BE" or "BE" it that 5115 there has been adequate working group discussion leading one to 5116 reasonably expect it will be adopted, without major change, in a 5117 subsequent document revision. 5119 Such general acceptance is not equivalent to a formal working group 5120 consensus and it not expected to result in major changes to the draft 5121 document, 5123 On the other hand, once there is a working group consensus with 5124 regard to a particular issue, the document will be modified to remove 5125 associated annotations, with the previously conditional text 5126 appearing just as other document text does. The issue will be 5127 removed from this table although it will be mentioned in Appendices 5128 A.2 or A.1 5130 It is is expected that these designations will change as discussion 5131 proceeds and new document versions are published. It is hoped that 5132 most such shifts will be upward in the above list or result in the 5133 deletion of a pending item, by reaching a consensus to accept or 5134 reject it. This would enable, once all items are dealt with, an 5135 eventual request for publication as an RFC, with this appendix having 5136 been deleted. 5138 +====+======+==================+===============================+ 5139 | # | Type | ...References... | Substance | 5140 +====+======+==================+===============================+ 5141 | 1 | NM* | #1a in S 4 | Outline of new approach to | 5142 | | | | authetication/identification, | 5143 | | | | replacing confusion about the | 5144 | | | | matter in previous | 5145 | | | | specifications. | 5146 +----+------+------------------+-------------------------------+ 5147 | 2 | NM* | #2a in S 4 | Introduction to and outline | 5148 | | | | of changes needed in | 5149 | | | | negotiation framework to | 5150 | | | | support provision of security | 5151 | | | | by the RPC transport. | 5152 +----+------+------------------+-------------------------------+ 5153 | 3 | BE | #3a in S 5.4 | Conversion of mask bit | 5154 | | | | descriptions from being about | 5155 | | | | "permissions" to being about | 5156 | | | | the action permitted, denied, | 5157 | | | | or specified as being audited | 5158 | | | | or generating alarms. | 5159 +----+------+------------------+-------------------------------+ 5160 | 4 | CI | #4a in S 5.4 | Elimination of uses of SHOULD | 5161 | | | | believed inappropriate in | 5162 | | | | Section 5.4. | 5163 +----+------+------------------+-------------------------------+ 5164 | 5 | BE | #5a in S 5.4 | Explicit inclusion of ACCESS | 5165 | | | | as an operation affected in | 5166 | | | | the mask bit definitions. | 5167 +----+------+------------------+-------------------------------+ 5168 | 6 | CI | #6a in S 5.4 | New/revised description of | 5169 | | | | the role of the "sticky bit" | 5170 | | | #6b in S 5.6 | for directories, both with | 5171 | | | | respect to ACL handling and | 5172 | | | #6c in S 7.3.1 | mode handling. | 5173 +----+------+------------------+-------------------------------+ 5174 | 7 | BE | #7a in S 5.4 | Clarification of relationship | 5175 | | | | between READ_DATA and | 5176 | | | | EXECUTE. | 5177 +----+------+------------------+-------------------------------+ 5178 | 8 | CI | #8a in S 5.4 | Revised discussion of | 5179 | | | | relationship between | 5180 | | | | WRITE_DATA and APPEND_DATA. | 5181 +----+------+------------------+-------------------------------+ 5182 | 9 | BC | #9a in S 5.4 | Clarification of how | 5183 | | | | ADD_DIRECTORY relates to | 5184 | | | | RENAME. | 5185 +----+------+------------------+-------------------------------+ 5186 | 10 | BC | #10a in S 5.4 | Revisions in handling of the | 5187 | | | | masks WRITE_RETENTION and | 5188 | | | #10b in S 5.5 | WRITE_RETENTION_HOLD. | 5189 +----+------+------------------+-------------------------------+ 5190 | 11 | CI | #11a in S 5.4 | Explicit recommendation and | 5191 | | | | requirements for mask | 5192 | | | #11b in S 5.5 | granularity, replacing the | 5193 | | | | previous treatment which gave | 5194 | | | #11c in S 5.11 | the server license to ignore | 5195 | | | | most of the previous section, | 5196 | | | | placing clients in an | 5197 | | | | unfortunate situation. | 5198 +----+------+------------------+-------------------------------+ 5199 | 12 | BC | #12a in S 5.6 | Revised treatment of | 5200 | | | | directory entry deletion. | 5201 | | | #12b in S 5.6.1 | | 5202 +----+------+------------------+-------------------------------+ 5203 | 13 | BC | #13a in 5.7 | Attempt to put some | 5204 | | | | reasonable limits on possible | 5205 | | | | non-support (or variations in | 5206 | | | | the support provided) for the | 5207 | | | | ACE flags. This is to | 5208 | | | | replace a situation in which | 5209 | | | | the client has no real way to | 5210 | | | | deal with the freedom granted | 5211 | | | | to server implementations. | 5212 +----+------+------------------+-------------------------------+ 5213 | 14 | BC | #14a in S 5.11 | Explicit discussion of the | 5214 | | | | case in which aclsupport is | 5215 | | | | not supported. | 5216 +----+------+------------------+-------------------------------+ 5217 | 15 | BC | #15a in S 5.11 | Handling of the proper | 5218 | | | | relationship between support | 5219 | | | #15b in S 7.1 | for ALLOW and DENY ACEs. | 5220 | | | | | 5221 | | | #15c in S 7.2 | | 5222 +----+------+------------------+-------------------------------+ 5223 | 16 | NM | #16a in S 5.1 | Discussion of coherence of | 5224 | | | | acl, sacl, and dacl | 5225 | | | | attributes. | 5226 +----+------+------------------+-------------------------------+ 5227 | 17 | BC | #17a in S 7.1 | Relationship of support for | 5228 | | | | ALLOW and DENY ACEs | 5229 | | | #17b in S 7.2 | | 5230 +----+------+------------------+-------------------------------+ 5231 | 18 | BC | #18a in S 7.1 | Need for support of owner, | 5232 | | | | owner_group. | 5233 | | | #18b in S 7.2 | | 5234 +----+------+------------------+-------------------------------+ 5235 | 19 | CI | #19a in S 7.2 | Revised discussion of | 5236 | | | | coordination of mode and the | 5237 | | | | ACL-related attributes. | 5238 +----+------+------------------+-------------------------------+ 5239 | 20 | WI | #20 in S 7.3.1 | More closely align ACL_based | 5240 | | | | and mode-based semantics with | 5241 | | | | regard to SVTX. | 5242 +----+------+------------------+-------------------------------+ 5243 | 21 | BC | #21a in S 7.3.1 | Introduce the concept of | 5244 | | | | reverse-slope modes and deal | 5245 | | | #21b in S 9.3 | properly with them. The | 5246 | | | | decision as to the proper | 5247 | | | #21c in S 9.6 | handling is addressed as | 5248 | | | | Consensus Item #28. | 5249 +----+------+------------------+-------------------------------+ 5250 | 22 | BC | #22a in S 8.1 | Revise treatment of | 5251 | | | | divergences between AC/mode | 5252 | | | | authorization and server | 5253 | | | | behavior, dividing the | 5254 | | | | treatment between cases in | 5255 | | | | which something authorized is | 5256 | | | | still not allowed (OK), and | 5257 | | | | those in which something not | 5258 | | | | authorized is allowed (highly | 5259 | | | | problematic from a security | 5260 | | | | point of view). | 5261 +----+------+------------------+-------------------------------+ 5262 | 23 | BC | #23a in S 8.2 | Revise discussion of client | 5263 | | | | access to of ACLs. | 5264 +----+------+------------------+-------------------------------+ 5265 | 24 | BE | #24a in S 8.2 | Delete bogus reference. | 5266 +----+------+------------------+-------------------------------+ 5267 | 25 | CI | #25a in S 3.3 | Revised description of co- | 5268 | | | | ordination of acl and mode | 5269 | | | #25b in S 9.1 | attributes to apply to NFSv4 | 5270 | | | | as a whole. While this | 5271 | | | #25d in S 9.7 | includes many aspects of the | 5272 | | | | shift to be more specific | 5273 | | | #25e in S 9.9 | about the co-ordination | 5274 | | | | requirements including | 5275 | | | #25f in S 9.10 | addressing apparently | 5276 | | | | unmotivated uses of the terms | 5277 | | | #25g in S 9.11 | "SHOULD" and "SHOULD NOT", it | 5278 | | | | excludes some arguably | 5279 | | | | related matters dealt with as | 5280 | | | | Consensus Items #26 and #27. | 5281 +----+------+------------------+-------------------------------+ 5282 | 26 | CI | #26a in S 9.2 | Decide how ACEs with who | 5283 | | | | values other than OWNER@, | 5284 | | | #26 in S 9.6.3 | Group, or EVERYONE@ are be | 5285 | | | | dealt with when setting mode. | 5286 +----+------+------------------+-------------------------------+ 5287 | 27 | CI | #27a in S 9.2 | Concerns the possibility of | 5288 | | | | establishing one way of | 5289 | | | #27b in S 9.3 | computing a mode from an acl | 5290 | | | | that clients can depend on, | 5291 | | | #27c in S 9.4 | rather than two or an | 5292 | | | | unbounded number. | 5293 +----+------+------------------+-------------------------------+ 5294 | 28 | WI | #28a in S 9.3 | Decide how to address flaws | 5295 | | | | in mapping to/from reverse- | 5296 | | | #28 in S 9.6.3 | slope modes. | 5297 +----+------+------------------+-------------------------------+ 5298 | 29 | BC | #29 in S 9.6.3 | Address the coordination of | 5299 | | | | mode and ACL-based attributes | 5300 | | | | in unified way for all minor | 5301 | | | | versions. | 5302 +----+------+------------------+-------------------------------+ 5303 | 30 | CI | #30a in S 9.6.1 | New proposed treatment of | 5304 | | | | setting mode incorporating | 5305 | | | #30b in S 9.6.2 | some consequences of | 5306 | | | | anticipated decisions | 5307 | | | #30c in S 9.6.3 | regarding other consensus | 5308 | | | | items (#26, #28, #29) | 5309 +----+------+------------------+-------------------------------+ 5310 | 31 | WI | #31a in S 9.6.3 | Need to deal with mask bits | 5311 | | | | ACE4_READ_ATTRIBUTES, | 5312 | | | | ACE4_WRITE_RETENTION, | 5313 | | | | ACE4_WRITE_RETENTION_HOLD, | 5314 | | | | ACE4_READ_ACL to reflect the | 5315 | | | | semantics of the mode | 5316 | | | | attribute. | 5317 +----+------+------------------+-------------------------------+ 5318 | 32 | BC | #32a in S 15 | Expanded negotiation | 5319 | | | | framework to accomodate | 5320 | | | #32b in S 15.1 | multiple transport types and | 5321 | | | | services derivable from | 5322 | | | #32c in S 15.2 | transport characteristics, | 5323 | | | | i.e. encryption and peer | 5324 | | | #32d in S 15.3 | authentication. | 5325 | | | | | 5326 | | | #32e in S 15.4 | | 5327 +----+------+------------------+-------------------------------+ 5328 | 33 | BE | #33a in S 15.5 | Reorganization of description | 5329 | | | | of SECINFO op to apply to all | 5330 | | | #33b in S 15.5.1 | minor versions. Assumes | 5331 | | | | basics of proposal for Item | 5332 | | | #33c in S 15.5.2 | #32. | 5333 | | | | | 5334 | | | #33d in S 15.5.3 | | 5335 | | | | | 5336 | | | #33e in S 15.5.4 | | 5337 | | | | | 5338 | | | #33f in S 18 | | 5339 | | | | | 5340 | | | #33g in S 18.1 | | 5341 | | | | | 5342 | | | #33h in S 18.2 | | 5343 +----+------+------------------+-------------------------------+ 5344 | 34 | BC | #34a in S 15.5.6 | Revision to NFSv4.0 SECINFO | 5345 | | | | implementation section to be | 5346 | | | | compatible with expanded | 5347 | | | | approach to negotiation. | 5348 | | | | Assumes basics of proposals | 5349 | | | | for Items #32 and #33. | 5350 +----+------+------------------+-------------------------------+ 5351 | 35 | NE | #35a in S 16 | Now has preliminary work on | 5352 | | | | future security needs. | 5353 +----+------+------------------+-------------------------------+ 5354 | 36 | CI | #36a in S 17.1.3 | Threat analysis only dealing | 5355 | | | | with RECOMMENDED behavior | 5356 | | | | regarding use of transport | 5357 | | | | security facilities and | 5358 | | | | handling of AUTH_SYS. | 5359 +----+------+------------------+-------------------------------+ 5360 | 37 | CI | #37a in S 17.1.3 | Threat analysis only dealing | 5361 | | | | with RECOMMENDED behavior | 5362 | | | | with regard to acl support | 5363 | | | | including ACL/mode | 5364 | | | | coordination. | 5365 +----+------+------------------+-------------------------------+ 5366 | 38 | CI | #38a in S 17.1.4 | Address the need to | 5367 | | | | temporarily allow unsafe | 5368 | | | | behavior mistakenly allowed | 5369 | | | | by previous specifications | 5370 +----+------+------------------+-------------------------------+ 5371 | 39 | CI | #39a in S 17.1.5 | Define new approach to | 5372 | | | | AUTH_SYS. | 5373 +----+------+------------------+-------------------------------+ 5374 | 40 | CI | #40a in S 17.2.1 | Discussion of scope for | 5375 | | | | security considerations and | 5376 | | | #40a in S 17.2.2 | the corresponding threat | 5377 | | | | analysis. | 5378 +----+------+------------------+-------------------------------+ 5379 | 41 | CI | #41a in S 17.3.1 | Discuss major new security | 5380 | | | | recommendations regarding | 5381 | | | #41b in S 17.3.2 | protection of data in flight | 5382 | | | | and client peer | 5383 | | | #41c in S 17.3.3 | authentication. Also, covers | 5384 | | | | the circumstances under which | 5385 | | | | such recommendations can be | 5386 | | | | bypassed. | 5387 +----+------+------------------+-------------------------------+ 5388 | 42 | LD | #42a in S 17.4 | Placeholder for threat | 5389 | | | | analysis section regarding | 5390 | | | | security of data in flight. | 5391 +----+------+------------------+-------------------------------+ 5392 | 43 | LD | #43a in S 17.5.1 | Placeholder for threat | 5393 | | | | analysis section dealing with | 5394 | | | | the use of AUTH_SYS. | 5395 +----+------+------------------+-------------------------------+ 5396 | 44 | LD | #44a in S 17.5.2 | Placeholder for threat | 5397 | | | | analysis section dealing with | 5398 | | | | attacks on userid/name | 5399 | | | | mapping. | 5400 +----+------+------------------+-------------------------------+ 5401 | 45 | LD | #45a in S 17.6.1 | Placeholder for threat | 5402 | | | | analysis section dealing with | 5403 | | | | disruption attacks based on | 5404 | | | | attacks on shared state. | 5405 +----+------+------------------+-------------------------------+ 5406 | 46 | LD | #46a in S 17.6.2 | Placeholder for threat | 5407 | | | | analysis section dealing with | 5408 | | | | attacks on shared state | 5409 | | | | design to cause misuse of | 5410 | | | | resources. | 5411 +----+------+------------------+-------------------------------+ 5412 | 47 | CI | #47a in S 15.5.5 | Dubious paragraph which | 5413 | | | | should be deleted if there | 5414 | | | | are no compatibility issues | 5415 | | | | that make that impossible. | 5416 +----+------+------------------+-------------------------------+ 5417 | 48 | CI | #48a in S 15.4.2 | Missing pieces of secinfo | 5418 | | | | processing algorithm that | 5419 | | | #48b in S 15.4.3 | didn't get done in -02. | 5420 +----+------+------------------+-------------------------------+ 5421 | 49 | NE | #49a in S 15.4.1 | Main secinfo processing | 5422 | | | | algorithm that needs to | 5423 | | | | finished in -02. | 5424 +----+------+------------------+-------------------------------+ 5426 Table 3 5428 The following table summarizes the issues in each particular state, 5429 dividing them into those associated with the motivating changes for 5430 this new document and those that derive from other issues, that were 5431 uncovered later, once work on a new treatment of NFSv4 security had 5432 begun. 5434 +========+=====+===============================================+ 5435 | Type | Cnt | Issues | 5436 +========+=====+===============================================+ 5437 | NM*(M) | 2 | 1, 2 | 5438 +--------+-----+-----------------------------------------------+ 5439 | BE(M) | 1 | 33 | 5440 +--------+-----+-----------------------------------------------+ 5441 | BC(M) | 2 | 32, 34 | 5442 +--------+-----+-----------------------------------------------+ 5443 | CI(M) | 7 | 36, 38, 39, 40, 41, 47, 48 | 5444 +--------+-----+-----------------------------------------------+ 5445 | NE(M) | 2 | 35, 49 | 5446 +--------+-----+-----------------------------------------------+ 5447 | LD(M) | 5 | 42, 43, 44, 45, 46 | 5448 +--------+-----+-----------------------------------------------+ 5449 | All(M) | 19 | As listed above. | 5450 +--------+-----+-----------------------------------------------+ 5451 | NM(O) | 1 | 16 | 5452 +--------+-----+-----------------------------------------------+ 5453 | BE(O) | 4 | 3, 5, 7, 24 | 5454 +--------+-----+-----------------------------------------------+ 5455 | BC(O) | 12 | 9, 10, 12, 13, 14, 15, 17, 18, 21, 22, 23, 29 | 5456 +--------+-----+-----------------------------------------------+ 5457 | CI(O) | 11 | 4, 6, 8, 11, 19, 25, 26, 27, 28, 30, 37 | 5458 +--------+-----+-----------------------------------------------+ 5459 | WI(O) | 2 | 20, 31 | 5460 +--------+-----+-----------------------------------------------+ 5461 | All(O) | 30 | As described above | 5462 +--------+-----+-----------------------------------------------+ 5463 | *All* | 49 | Grand total for above table. | 5464 +--------+-----+-----------------------------------------------+ 5466 Table 4 5468 Acknowledgments 5470 The author wishes to thank Tom Haynes for his helpful suggestion to 5471 deal with security for all NFSv4 minor versions in the same document. 5473 The author wishes to draw people's attention to Nico Williams' remark 5474 that NFSv4 security was not so bad, except that there was no 5475 provision for authentication of the client peer. This perceptive 5476 remark, which now seems like common sense, did not seem so when made, 5477 but it has served as a beacon for those putting NFSv4 security on a 5478 firmer footing. We appreciate this perceptive guidance. 5480 The author wishes to acknowledge the important role of the authors of 5481 RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS 5482 security agenda forward and thank them for all their efforts to 5483 improve NFS security. 5485 The author wishes to thank Chuck Lever for his many helpful comments 5486 about nfsv4 security issues, his explanation of many unclear points, 5487 and and much important guidance he provided that is reflected in this 5488 document. 5490 The author wishes to thank Rick Macklem for his role in clarifying 5491 possible server policies regarding RPC-over-TLS and bringing possible 5492 approaches to the attention of the working group. 5494 Author's Address 5496 David Noveck (editor) 5497 NetApp 5498 1601 Trapelo Road, Suite 16 5499 Waltham, MA 02451 5500 United States of America 5502 Phone: +1-781-572-8038 5503 Email: davenoveck@gmail.com