| Internet-Draft | Nfsv4 Security | July 2021 |
| Noveck | Expires 12 January 2022 | [Page] |
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided at the RPC transport level.¶
This prelimimary version of the document, is intended, in large part, to result in working group discussion regarding NFSv4 security issues and ientify issues on which the working group needs to work on achieving consensus.¶
When published as an RFC, it will supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 January 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶
This document presents a new approach to security for the NFSv4 protocols, which, although building on previous treatments of these issues, diverges substantially from them in a number of respects.¶
A new treatment is necessary because:¶
Previous treatments paid insufficient attention to security issues regarding data in flight.¶
The presentation of AUTH_SYS as an "'OPTIONAL' means of authentication" obscured the severe security problems that come with its use.¶
The security considerations sections of existing minor version specifications contain no threat analyses and focus on particular security issues in a way that obscures, rather than clarifying, the security issues that need to be addressed.¶
The availabilty of RPC-with-TLS (described in [12]) provides facilities that NFSv4 clients and servers will need to use to provide security for data in flight and mitigate the lack of authentication when AUTH_SYS is used.¶
This preliminary document contains many notes with headers in brackets, requesting comments regarding confusing or otherwise dubious passages in existing documents and other choices that need to made. Comments and working group discussion of those notes will be important in arriving at an adequate RFC cadidate.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as specified in BCP 14 [1] [5] when, and only when, they appear in all capitals, as shown here.¶
Because this document needs to revise previous treatments of its subject, it will need to cite previous treatments of issues that now need to be dealt with in a different way. This will take the form of quotations from documents whose treatment of the subject is being obsoleted, most often direct but sometimes indirect as well.¶
Such treatments in quotations will involve use of these BCP14-defined terms in two noteworthy ways:¶
The term may have been used inappropriately (i.e not in accord with [1]), as has been the case for the "RECOMMENDED" attributes, which are in fact OPTIONAL.¶
In such cases, the surrounding text will make clear that the quoted text has no normative effect.¶
Some specific issues relating to this case are described below Section 5.2.¶
The term may been used in accord with [1], although the resulting normative statement is now felt to be inappropriate.¶
In such cases, the surrounding text will need to make clear that the text quoted is no longer to be considered normative, often by providing new text that conficts with the quoted, previously nomative, text.¶
An important instance of this situation is the description of AUTH_SYS as an "OPTIONAL" means of authentication. For detailed discussion of this case, see Sections 10 and 13.1.4¶
Because the basic approach to security issues is so similar for all minor versions, this document applies to all NFSv4 minor versions. The details of this transition are discused in Sections 3.1 and 3.2¶
This document is able to take a new approach to security issues because of the work that has been done to provide security features at the transort level, rather than providing security features only by making choices with regard to the authentication flavor and associated mechanisms and services. The effect of this shift is summarized in Section 3.3.¶
In some cases, there are differences between minor versions in that there are security-related features, not present in all minor versions.¶
To deal with this issue, this document will focus on a few major areas listed below which are common to all minor versions.¶
File access authorization (discussed in Section 5) is the same in all minor versions togther with the identification/ authentication infrastructure supporting it (discussed in Section 10) provided by RPC and applying to all of NFS.¶
An exception is made regarding labelled NFS, an optional feature within NFSv4.2, described in [10]. This is discussed as a version-specific feature in this document in Section 8¶
Features to secure data in-flight, all provided by RPC, together with the negotation infrastructure to support them are common to all NFSv4 minor versions, are discussed in Section 12¶
However, the use of SECINFO_NONAME, together with changes needed for transport level encryption, paralleling those proposed here for SECINFO, is treated as a version-specfic feature and, while mentioned here, will be fully documented in new v4.1 specification documents.¶
The Protection of state data from unauthorized modification is discussed in Section 9) is the same in all minor versions togther with the identification/ authentication infrastructure supporting it (discussed in Section 10) provided by secure transports such as RPC-over-TLS.¶
It should be noted that state protection based on RPCSEC_GSS is treated as a version-specific feature and will continue to be described by [8] or its successors. Also, it needs to be noted that the use of state protection is not discussed in [6].¶
There are a number of areas in which security features differ among minor versions, as discussed below. In some cases, a new feature requires specific security support while in others one version will have a new feature related to enhancing the security infrastructure.¶
How such features are dealt with in this document depends on the specific feature.¶
[Working group discussion advisable]: There's a lot of opportnities to make mistakes. I'd prefer to find out sooner rather than later.¶
In addition to SECINFO, whose enhanced description appears in this document, NFSv4.1 added a new SECINFO_NONAME operation, useful for pNFS file as well as having some non-pNFS uses.¶
While the enhanced description of SECINFO mentions SECINFO_NONAME, this is handled as one of a number of cases in which the description has to indicate that different actions need to be taken for different minor versions.¶
The definitive description of SECINFO_NONAME, now appearing in RFC8881 needs to be modified to match the description of SECINFO appearing in this document. It is expected that this will be done as part of the rfc5661bis process.¶
The security implications of the security negotiation facilities as a whole will be addressed in the security considerations section of this document.¶
The pNFS optional feature added in NFSv4.1 has its own security needs which parallel closely those of non-pNFS access. As a result, these needs and the means to satisfy them are not discussed in this document.¶
The definitive description of pNFS security will remain in RFC8881 and its successors (i.e. the rfc5661bis document suite). However, because pNFS sucurity relies heavily on the infrastructure discussed here, it is anticipated that the new treatment of pNFS security will deal with many matters by referencing the overall NFS security document.¶
The security considerations section of rfc5661bis will deal with pNFS security issues.¶
In addition to the state protection facilities described in this document, NFS has another set of such facilities that are not usable in NFSv4.0.¶
While this document will discuss the security implications of protection against state modification, it will not discuss the details of the v4.1-specfic features to accomplicsh it.¶
The additional v4.1 acl attributes, sacl and dacl, are mentioned in this document, but do not affect the treatment of security, since the acl entries, whether in the acl attribute or separated into sacl and dacl attributes continue to have the same effect.¶
Nfsv4.1 introduced detailed description of methods of co-ordinating the values of the authorization-related attributes mode and acl. this is in contrast to Nfsv4.0, which while expecting such co-ordination to be provide somehow, did not provide any detils, allowing a number of different approaches to meat the goal of providing appopriate co-ordination.¶
This document will provide separate sections describing each of the approaches, together with a common section describing the goals of providing co-ordination when both are supported.¶
As a result, this document will override the treatment within RFC8881 and this material will be removed in the rfc5661bis document suite and replaced by a reference to the treatment in the NFSv4 security RFC.¶
Simiarly, this doument will supersede the corresponding treatment in RFC7530 as well. As a result, v4.0 server implementers reading any successor document will be aware of the possibility of the v4.1 approach even though it is clear that this only one of the possible approaches to this issue. V4.1 client implementers will be made aware of the goals and that there is little that can be relied upon with regard to v4.0 servers' attempts to address those goals.¶
The protocol extension defined in [13], now part of NFSv4.2, is also related to the issue of co-ordination of acl and mode attributes and will be discussed in that context.¶
Nevertheless, the description in [13] will remain definitive.¶
The the v4.1 attribute set-mode-masked attribute is mentioned together with the other attributes implementing the POSIX authorization model.¶
Because this attribute. while related to security, does not substantively modify the security properties of the protocol, the full description of this attribute, will continue to be the province of the v4.1 specification proper.¶
There is a brief description of the v4.2 Labelled NFS feature in Section 8. Part of that description discusses the limitations in the desciption of that feature within [10].¶
Because of some limitations in the desription, it is not possible to provide an appropriate security considerations section for that feature in this document.¶
As a result, the responsibility to provide an apprpriate Security Considerations section remains, unrealized for now, with the NFSv4.2 specification document.¶
There are a number of security-related facilities that can be provided at the transport layer eliminating the need for or or proving support to processing done as part of RPC proper.¶
These will initially be provided by RPC-over-TLS but similar facilties might be provided on new versions of existing transports or new RPC transports.¶
The transport might provide encryption of requests and replies, eliminating the need for privacy and integrity services to be negotiated later and applied on a per-request basis.¶
While clients might chooose to establish connections with such encryption, servers can establish policies allowing access to certain pieces of the namespace using such transports, or limiting access to those providing privacy, allowing the use of either transport-based encryption or privacy servicies provided by RPCSEC_GSS.¶
The transport might provide mutual authentication of the client and server peers as part of the establishment of the connection This authentication is distinct from the the mutual authentication of the client user and server peer, implemented within the GSSSEC_RPC framework.¶
This form of authentication is of particular importance when the when the server allows the use of the flavors AUTH_SYS and AUTH_NONE, which have no provision for the authentication of the user requesting the operation.¶
While clients might chooose to establish connections with such peer authentication, servers can establish policies a limiting access to certain pieces of the namespace without such peer authentication or only allowing it using RPCSEC_GSS.¶
To enable server policies to be effectively communicated to clients, the seurity negotiation framework now allows connection chacteristics to be specified using pseudo-flavors. See Section 12 for details.¶
There are three distinct methods of checking whether NFSv4 requests are authorized:¶
The most important method of authorization is used to effect user-based file access control, as described in Section 5.¶
This requires the identification of the user making the request. Because of the central role of such access control in providing NFSv4 security, server implementations SHOULD NOT use such identifications when they are not authenticated. In this context, valid reasons to do otherwise are limited to the compatibility and maturity issues discussed in Section 13.1.3¶
NFSv4.2, via the labelled NFS feature, provides an additional potential requirement for request authorization.¶
For reasons made clear in Section 8, there is no realistic possibility of the server using the data defined by existing specifications of this feature to effect request authorization. While it is possible for clients to provide this authorization, the lack of detailed specfication makes it impossible to determine the nature of the identification used and whether it can be described as "authentication".¶
Since undesired changes to server-mintained locking state (and, for NFSv4.1, session state) can result in denial of service attacks (see Section 13.6), server implementations SHOULD take steps to prevent unauthorized state changes. This can be done by implementing the state authorization restrictions discussed in Section 9¶
ACLs and modes represent two well-established models for specifying user-based file access permissions. NFSv4 provides support for either or both depending on the attributes supported by the server:¶
When the attributes mode, owner, owner group are all supported, the posix-based authorization model, described in Section 5.3 can be used.¶
When the acl (or dacl) attribute is supported, the acl based authorization model, described in Section 5.4 can be used.¶
[Working group discussion needed]: Existing specifications neither require that owner and owner group be supported nor provide useful guidance about how clients might deal with servers that support the acl attribute but do not support owner or owner_group (e.g how such a server might deal with acl containing "OWNER@" or "GROUP@"). In addition, the use of acl's to generate a corresponding mode seems poinless in the absence of the owner and owner-group attributes.¶
[Working group decision needed]: It apppears that, despite what RFC7530 and RFC8881 say, owner and owner_group are essentially REQUIRED attributes, but while our successor RFC will update both RFC7530 and RFC8881, that document may not be the place to rectify that mistake. I'm thinking of something like the following:¶
When both authorization models can be used, there are difficulties that can arise because the ACL-base model provides finer-grained access control than the POSIX model. Some goals for dealing with these difficulties appear later in this section while more detail on the appropriate handlin of this situation, which may depend on the minor version used, appears in Section 7.¶
The following lists the goals of NFSv4 in supporting multiple authorization models for file access.¶
If a server supports the mode attribute, it should provide the appropriate POSIX semantics to clients that only set and retrieve the mode attribute.¶
[WG Discussion might be needed]: The above substitutes for the requirement that the server provide "reasonable semantics". Are there suggestions for other approaches to this passage?¶
If a server supports ACL attributes, it should provide reasonable semantics to clients that only set and retrieve those attributes.¶
[WG Discussion might be needed]: Similarly we need a replacement for "reasonable semantics". I'm supposing "the semantics described in this document" is a reasonable replacement.¶
On servers that support the mode attribute, if the ACL attributes have been previously set on an object, either explicitly or via inheritance:¶
Setting only the mode attribute should effectively control the traditional UNIX-like permissions of read, write, and execute on owner, owner_group, and other.¶
[Working group discussion needed]: It isn't really clear what the above paragraph means, especially as it governs the handling of aces designating specific users and groups which are not the owner and have no overlap with the owning¶
While it would be possible to substitute a three-ace acl with one ace for each of owner, group and others, I'm not sure that is what is intened. In particular, I'm unsure why would need a second bullet item if we had a clear statement to that effect.¶
It is particularly important to resolve this now, since this is part of the goals that apply to all minor versions.¶
Setting only the mode attribute should provide reasonable security. For example, setting a mode of 000 should be enough to ensure that future OPEN operations for OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any principal fail, regardless of a previously existing or inherited ACL.¶
[Working group discussion needed]: We need some replacement for the subjective first sentence. While the specfic example give is unexceptionable, it raises question about other case in which what constitutes "reasonable semantics" might subect to dispute.¶
In regard to the interaction of the mode and ACL attributes:¶
As discussed in Section 7.1, the specfic semanric requirements specified for v4.1 could be adopted by v4.0, although some modification might be necessary to deal with the absence of the mode_set_masked attribute.¶
V4.0 clients would have to be able to interact with servers that different approaches to these goals.¶
V4.1 servers have specfic rules for handling these issues as discussed in Section 7.2. However, despite this, the rules are, in many places, fairly loosely drawn and allow a range of server behaviors.¶
To deal with issues related to the perceived overuse of modes derived from the umask in vitiating needed acl inheritance, a V4.2 extension was provided, allowing the separation of the application-specfed mode from the umask. This is discussed in Section 7.3¶
NFSv4.1 provides for multiple authentication models, controlled by the support for particular Recommended attributes implemented by the server, as discussed below:¶
The attributes owner, owning_group, and mode enable use of a POSIX-based authorization model, as described in Section 5.3. When all of these attributes are supported, this authorization model can be implemented. When none of these attributes or only a proper subset of them are supported, this attribute model is unavailable.¶
The acl attribute (or the attributes sacl and dacl in v4.1) provide an ACL-based authorization model as described in Section 5.4.¶
The NFSv4.1 mode attribute is based on the UNIX mode bits. The following bits are defined:¶
const MODE4_SUID = 0x800; /* set user id on execution */ const MODE4_SGID = 0x400; /* set group id on execution */ const MODE4_SVTX = 0x200; /* save text even after use */ const MODE4_RUSR = 0x100; /* read permission: owner */ const MODE4_WUSR = 0x080; /* write permission: owner */ const MODE4_XUSR = 0x040; /* execute permission: owner */ const MODE4_RGRP = 0x020; /* read permission: group */ const MODE4_WGRP = 0x010; /* write permission: group */ const MODE4_XGRP = 0x008; /* execute permission: group */ const MODE4_ROTH = 0x004; /* read permission: other */ const MODE4_WOTH = 0x002; /* write permission: other */ const MODE4_XOTH = 0x001; /* execute permission: other */¶
Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal identified in the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP apply to principals identified in the owner_group attribute but who are not identified in the owner attribute. Bits MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any principal that does not match that in the owner attribute and does not have a group matching that of the owner_group attribute.¶
Bits within a mode other than those specified above are not defined by this protocol. A server MUST NOT return bits other than those defined above in a GETATTR or READDIR operation, and it MUST return NFS4ERR_INVAL if bits other than those defined above are set in a SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation.¶
[Working group input needed]: It is my impression that the three high-order bits do not affect server behavior. Is this so? If it is, should that be stated explicitly? I there a need to more clearly define what the client does with these or is this somehow out of scope.¶
The mode_set_masked attribute is a write-only attribute that allows individual bits in the mode attribute to be set or reset, without changing others. It allows, for example, the bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified any of the nine low-order mode bits devoted to permissions.¶
In instances such that none of the nine low-order bits are subject to modification, then neither the acl nor the dacl attribute should be automatically modified as discussed in Sections 7.2.4 and 7.2.6.¶
The mode_set_masked attribute consists of two words, each in the form of a mode4. The first consists of the value to be applied to the current mode value and the second is a mask. Only bits set to one in the mask word are changed (set or reset) in the file's mode. All other bits in the mode remain unchanged. Bits in the first word that correspond to bits that are zero in the mask are ignored, except that undefined bits are checked for validity and can result in NFS4ERR_INVAL as described below.¶
The mode_set_masked attribute is only valid in a SETATTR operation. If it is used in a CREATE or OPEN operation, the server MUST return NFS4ERR_INVAL.¶
Bits not defined as valid in the mode attribute are not valid in either word of the mode_set_masked attribute. The server MUST return NFS4ERR_INVAL if any such bits are set to one in a SETATTR. If the mode and mode_set_masked attributes are both specified in the same SETATTR, the server MUST also return NFS4ERR_INVAL.¶
The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each contain an array of Access Control Entries (ACEs) that are associated with the file system object. The client can set and get these attributes attribute, the server is responsible for using the ACL-related attributes to perform access control. The client can use the OPEN or ACCESS operations to check access without modifying or expliitly reading data or metadata.¶
The NFS ACE structure is defined as follows:¶
typedef uint32_t acetype4;
typedef uint32_t aceflag4;
typedef uint32_t acemask4;
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
¶
To determine if a request succeeds, the server processes each nfsace4 entry in turnn as ordered in the array. Only ACEs that have a "who" that matches the requester are considered. An ACE is consider to match a given requester if at least one of the following is true:¶
Each ACE is processed until all of the bits of the requester's access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester's access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. When the ACL is fully processed, if there are bits in the requester's mask that have not been ALLOWED or DENIED, access is denied.¶
Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do not affect a requester's access, and instead are for triggering events as a result of a requester's access attempt. Therefore, AUDIT and ALARM ACEs are processed only after processing ALLOW and DENY ACEs.¶
The NFSv4.1 ACL model is quite rich. Some server platforms may provide access-control functionality that goes beyond the UNIX-style mode attribute, but that is not as rich as the NFS ACL model. So that users can take advantage of this more limited functionality, the server may support the acl attributes by mapping between its ACL model and the NFSv4.1 ACL model. Servers must ensure that the ACL they actually store or enforce is at least as strict as the NFSv4 ACL that was set. It is tempting to accomplish this by rejecting any ACL that falls outside the small set that can be represented accurately. However, such an approach can render ACLs unusable without special client-side knowledge of the server's mapping, which defeats the purpose of having a common NFSv4 ACL protocol. Therefore, servers should accept every ACL that they can without compromising security. To help accomplish this, servers may make a special exception, in the case of unsupported permission bits, to the rule that bits not ALLOWED or DENIED by an ACL must be denied. For example, a UNIX-style server might choose to silently allow read attribute permissions even though an ACL does not explicitly allow those permissions. (An ACL that explicitly denies permission to read attributes should still be rejected.)¶
The situation is complicated by the fact that a server may have multiple modules that enforce ACLs. For example, the enforcement for NFSv4.1 access may be different from, but not weaker than, the enforcement for local access, and both may be different from the enforcement for access through other protocols such as SMB (Server Message Block). So it may be useful for a server to accept an ACL even if not all of its modules are able to support it.¶
The guiding principle with regard to NFSv4 access is that the server must not accept ACLs that appear to make access to the file more restrictive than it really is.¶
The constants used for the type field (acetype4) are as follows:¶
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;¶
Only the ALLOWED and DENIED bits may be used in the dacl attribute, and only the AUDIT and ALARM bits may be used in the sacl attribute. All four are permitted in the acl attribute.¶
| Value | Abbreviation | Description |
|---|---|---|
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants the access defined in acemask4 to the file or directory. |
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies the access defined in acemask4 to the file or directory. |
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system-dependent way) any access attempt to a file or directory that uses any of the access methods specified in acemask4. |
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm (in a system-dependent way) when any access attempt is made to a file or directory for the access methods specified in acemask4. |
The "Abbreviation" column denotes how the types will be referred to throughout the rest of this section.¶
The bitmask constants used for the access mask field are as follows:¶
const ACE4_READ_DATA = 0x00000001; const ACE4_LIST_DIRECTORY = 0x00000001; const ACE4_WRITE_DATA = 0x00000002; const ACE4_ADD_FILE = 0x00000002; const ACE4_APPEND_DATA = 0x00000004; const ACE4_ADD_SUBDIRECTORY = 0x00000004; const ACE4_READ_NAMED_ATTRS = 0x00000008; const ACE4_WRITE_NAMED_ATTRS = 0x00000010; const ACE4_EXECUTE = 0x00000020; const ACE4_DELETE_CHILD = 0x00000040; const ACE4_READ_ATTRIBUTES = 0x00000080; const ACE4_WRITE_ATTRIBUTES = 0x00000100; const ACE4_WRITE_RETENTION = 0x00000200; const ACE4_WRITE_RETENTION_HOLD = 0x00000400; const ACE4_DELETE = 0x00010000; const ACE4_READ_ACL = 0x00020000; const ACE4_WRITE_ACL = 0x00040000; const ACE4_WRITE_OWNER = 0x00080000; const ACE4_SYNCHRONIZE = 0x00100000;¶
Note that some masks have coincident values, for example, ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are intended to be used with directory objects, while ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with non-directory objects.¶
ACE4_READ_DATA¶
ACE4_LIST_DIRECTORY¶
ACE4_WRITE_DATA¶
ACE4_ADD_FILE¶
CREATE¶
LINK¶
OPEN¶
RENAME¶
ACE4_APPEND_DATA¶
WRITE¶
OPEN¶
SETATTR of size¶
ACE4_ADD_SUBDIRECTORY¶
ACE4_READ_NAMED_ATTRS¶
OPENATTR¶
ACE4_WRITE_NAMED_ATTRS¶
OPENATTR¶
ACE4_EXECUTE¶
READ¶
OPEN¶
REMOVE¶
RENAME¶
LINK¶
CREATE¶
Permission to execute a file.¶
Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is allowed. This is because there is no way to execute a file without reading the contents. Though a server may treat ACE4_EXECUTE and ACE4_READ_DATA bits identically when deciding to permit a READ operation, it SHOULD still allow the two bits to be set independently in ACLs, and MUST distinguish between them when replying to ACCESS operations. In particular, servers SHOULD NOT silently turn on one of the two bits when the other is set, as that would make it impossible for the client to correctly enforce the distinction between read and execute permissions.¶
As an example, following a SETATTR of the following ACL:¶
A subsequent GETATTR of ACL for that file SHOULD return:¶
Rather than:¶
ACE4_EXECUTE¶
ACE4_DELETE_CHILD¶
REMOVE¶
RENAME¶
ACE4_READ_ATTRIBUTES¶
GETATTR of file system object attributes¶
VERIFY¶
NVERIFY¶
READDIR¶
ACE4_WRITE_ATTRIBUTES¶
SETATTR of time_access_set, time_backup,¶
time_create, time_modify_set, mimetype, hidden, system¶
ACE4_WRITE_RETENTION¶
ACE4_WRITE_RETENTION_HOLD¶
ACE4_DELETE¶
ACE4_READ_ACL¶
ACE4_WRITE_ACL¶
ACE4_WRITE_OWNER¶
ACE4_SYNCHRONIZE¶
Permission to use the file object as a synchronization primitive for interprocess communication. This permission is not enforced or interpreted by the NFSv4.1 server on behalf of the client.¶
Typically, the ACE4_SYNCHRONIZE permission is only meaningful on local file systems, i.e., file systems not accessed via NFSv4.1. The reason that the permission bit exists is that some operating environments, such as Windows, use ACE4_SYNCHRONIZE.¶
For example, if a client copies a file that has ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 server, and then later copies the file from the NFSv4.1 server to a local file system, it is likely that if ACE4_SYNCHRONIZE was set in the original file, the client will want it set in the second copy. The first copy will not have the permission set unless the NFSv4.1 server has the means to set the ACE4_SYNCHRONIZE bit. The second copy will not have the permission set unless the NFSv4.1 server has the means to retrieve the ACE4_SYNCHRONIZE bit.¶
Server implementations need not provide the granularity of control that is implied by this list of masks. For example, POSIX-based systems might not distinguish ACE4_APPEND_DATA (the ability to append to a file) from ACE4_WRITE_DATA (the ability to modify existing contents); both masks would be tied to a single "write" permission bit. When such a server returns attributes to the client that contain such masks, it would show ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the the write permission bit is enabled.¶
If a server receives a SETATTR request that it cannot accurately implement, it should err in the direction of more restricted access, except in the previously discussed cases of execute and read. For example, suppose a server cannot distinguish overwriting data from appending new data, as described in the previous paragraph. If a client submits an ALLOW ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice versa), the server should either turn off ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP.¶
Two access mask bits govern the ability to delete a directory entry: ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD on the containing directory (the "parent").¶
Many systems also take the "sticky bit" (MODE4_SVTX) on a directory to allow unlink only to a user that owns either the target or the parent; on some such systems the decision also depends on whether the target is writable.¶
Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that this is true even if the parent or target explicitly denies one of these permissions.)¶
If the ACLs in question neither explicitly ALLOW nor DENY either of the above, and if MODE4_SVTX is not set on the parent, then the server SHOULD allow the removal if and only if ACE4_ADD_FILE is permitted. In the case where MODE4_SVTX is set, the server may also require the remover to own either the parent or the target, or may require the target to be writable.¶
This allows servers to support something close to traditional UNIX-like semantics, with ACE4_ADD_FILE taking the place of the write bit.¶
The bitmask constants used for the flag field are as follows:¶
const ACE4_FILE_INHERIT_ACE = 0x00000001; const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; const ACE4_INHERIT_ONLY_ACE = 0x00000008; const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; const ACE4_IDENTIFIER_GROUP = 0x00000040; const ACE4_INHERITED_ACE = 0x00000080;¶
A server need not support any of these flags. If the server supports flags that are similar to, but not exactly the same as, these flags, the implementation may define a mapping between the protocol-defined flags and the implementation-defined flags.¶
For example, suppose a client tries to set an ACE with ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form of ACL inheritance, the server should reject the request with NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE" flag that applies to both files and directories, the server may reject the request (i.e., requiring the client to set both the file and directory inheritance flags). The server may also accept the request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag.¶
Can be placed on a directory and indicates that this ACE should be added to each new directory created.¶
If this flag is set in an ACE in an ACL attribute to be set on a non-directory file system object, the operation attempting to set the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP.¶
Can be placed on a directory but does not apply to the directory; ALLOW and DENY ACEs with this bit set do not affect access to the directory, and AUDIT and ALARM ACEs with this bit set do not trigger log or alarm events. Such ACEs only take effect once they are applied (with this bit cleared) to newly created files and directories as specified by the ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE flags.¶
If this flag is present on an ACE, but neither ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, then an operation attempting to set such an attribute SHOULD fail with NFS4ERR_ATTRNOTSUPP.¶
The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE types. If during the processing of the file's ACL, the server encounters an AUDIT or ALARM ACE that matches the principal attempting the OPEN, the server notes that fact, and the presence, if any, of the SUCCESS and FAILED flags encountered in the AUDIT or ALARM ACE. Once the server completes the ACL processing, it then notes if the operation succeeded or failed. If the operation succeeded, and if the SUCCESS flag was set for a matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. If the operation failed, and if the FAILED flag was set for the matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. Either or both of the SUCCESS or FAILED can be set, but if neither is set, the AUDIT or ALARM ACE is not useful.¶
The previously described processing applies to ACCESS operations even when they return NFS4_OK. For the purposes of AUDIT and ALARM, we consider an ACCESS operation to be a "failure" if it fails to return a bit that was requested and supported.¶
The "who" field of an ACE is an identifier that specifies the principal or principals to whom the ACE applies. It may refer to a user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying which.¶
There are several special identifiers that need to be understood universally, rather than in the context of a particular DNS domain. Some of these identifiers cannot be understood when an NFS client accesses the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over NFS, even if none of the access methods on the server understands the identifiers.¶
| Who | Description |
|---|---|
| OWNER | The owner of the file. |
| GROUP | The group associated with the file. |
| EVERYONE | The world, including the owner and owning group. |
| INTERACTIVE | Accessed from an interactive terminal. |
| NETWORK | Accessed via the network. |
| DIALUP | Accessed as a dialup user to the server. |
| BATCH | Accessed from a batch job. |
| ANONYMOUS | Accessed without any authentication. |
| AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). |
| SERVICE | Access from a system service. |
To avoid conflict, these special identifiers are distinguished by an appended "@" and should appear in the form "xxxx@" (with no domain name after the "@"), for example, ANONYMOUS@.¶
The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.¶
[working group input needed]: I don't understand what might be valid reasons to ignore this. Would "MUST" be appropriate here?¶
It is important to note that "EVERYONE@" is not equivalent to the UNIX "other" entity. This is because, by definition, UNIX "other" does not include the owner or owning group of a file. "EVERYONE@" means literally everyone, including the owner or owning group.¶
[working group input needed]: Some of these require that changes be made as discussed below:¶
For "ANONYMOUS", clearly requests using AUTH_NONE fit but what else?¶
Request by nobody and by users root-squashed to nobody are probably OK, although you could argue about the case of a user "nobody" authenticated by ROCSEC_GSS>¶
ON a more contentious note, I would argue that users "authenticated" using AUTH_SYS, in the clear, without client-peer authentication fit here, but we need to get to consensus on this point.¶
The acl attribute consists only of an array of ACEs, but the sacl (Section 5.8) and dacl (Section 5.7) attributes also include an additional flag field.¶
struct nfsacl41 {
aclflag4 na41_flag;
nfsace4 na41_aces<>;
};
¶
The flag field applies to the entire sacl or dacl; three flag values are defined:¶
const ACL4_AUTO_INHERIT = 0x00000001; const ACL4_PROTECTED = 0x00000002; const ACL4_DEFAULTED = 0x00000004;¶
and all other bits must be cleared. The ACE4_INHERITED_ACE flag may be set in the ACEs of the sacl or dacl (whereas it must always be cleared in the acl).¶
Together these features allow a server to support automatic inheritance, which we now explain in more detail.¶
Inheritable ACEs are normally inherited by child objects only at the time that the child objects are created; later modifications to inheritable ACEs do not result in modifications to inherited ACEs on descendants.¶
However, the dacl and sacl provide an OPTIONAL mechanism that allows a client application to propagate changes to inheritable ACEs to an entire directory hierarchy.¶
A server that supports this feature performs inheritance at object creation time in the normal way, and SHOULD set the ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to the new object.¶
A client application such as an ACL editor may then propagate changes to inheritable ACEs on a directory by recursively traversing that directory's descendants and modifying each ACL encountered to remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It uses the existing ACE inheritance flags in the obvious way to decide which ACEs to propagate. (Note that it may encounter further inheritable ACEs when descending the directory hierarchy and that those will also need to be taken into account when propagating inheritable ACEs to further descendants.)¶
The reach of this propagation may be limited in two ways: first, automatic inheritance is not performed from any directory ACL that has the ACL4_AUTO_INHERIT flag cleared; and second, automatic inheritance stops wherever an ACL with the ACL4_PROTECTED flag is set, preventing modification of that ACL and also (if the ACL is set on a directory) of the ACL on any of the object's descendants.¶
This propagation is performed independently for the sacl and the dacl attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may be independently set for the sacl and the dacl, and propagation of one type of acl may continue down a hierarchy even where propagation of the other acl has stopped.¶
New objects should be created with a dacl and a sacl that both have the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to the same value as that on, respectively, the sacl or dacl of the parent object.¶
Both the dacl and sacl attributes are Recommended, and a server may support one without supporting the other.¶
A server that supports both the old acl attribute and one or both of the new dacl or sacl attributes must do so in such a way as to keep all three attributes consistent with each other. Thus, the ACEs reported in the acl attribute should be the union of the ACEs reported in the dacl and sacl attributes, except that the ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl. And of course a client that queries only the acl will be unable to determine the values of the sacl or dacl flag fields.¶
When a client performs a SETATTR for the acl attribute, the server SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the dacl. By using the acl attribute, as opposed to the dacl or sacl attributes, the client signals that it may not understand automatic inheritance, and thus cannot be trusted to set an ACL for which automatic inheritance would make sense.¶
When a client application queries an ACL, modifies it, and sets it again, it should leave any ACEs marked with ACE4_INHERITED_ACE unchanged, in their original order, at the end of the ACL. If the application is unable to do this, it should set the ACL4_PROTECTED flag. This behavior is not enforced by servers, but violations of this rule may lead to unexpected results when applications perform automatic inheritance.¶
If a server also supports the mode attribute, it SHOULD set the mode in such a way that leaves inherited ACEs unchanged, in their original order, at the end of the ACL. If it is unable to do so, it SHOULD set the ACL4_PROTECTED flag on the file's dacl.¶
Finally, in the case where the request that creates a new file or directory does not also set permissions for that file or directory, and there are also no ACEs to inherit from the parent's directory, then the server's choice of ACL for the new object is implementation-dependent. In this case, the server SHOULD set the ACL4_DEFAULTED flag on the ACL it chooses for the new object. An application performing automatic inheritance takes the ACL4_DEFAULTED flag as a sign that the ACL should be completely replaced by one generated using the automatic inheritance rules.¶
The acl attribute, as opposed to the sacl and dacl attributes, consists only of an ACE array and does not support automatic inheritance.¶
The acl attribute is recommende and there is no requirement that a server support. However, when the dacl attribute is supported, it is a good idea to provide support for the acl attributes as well, in order to accommodate clients that have not been upgraded to use the dacl attribute.¶
A server need not support all of the above ACE types. This attribute indicates which ACE types are supported for the current file system. The bitmask constants used to represent the above definitions within the aclsupport attribute are as follows:¶
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; const ACL4_SUPPORT_DENY_ACL = 0x00000002; const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; const ACL4_SUPPORT_ALARM_ACL = 0x00000008;¶
Servers that support either the ALLOW or DENY ACE type SHOULD support both ALLOW and DENY ACE types.¶
[Working group input needed]: What are the valid reasons not do this?¶
Clients should not attempt to set an ACE unless the server claims support for that ACE type. If the server receives a request to set an ACE that it cannot store, it MUST reject the request with NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE that it can store but cannot enforce, the server SHOULD reject the request with NFS4ERR_ATTRNOTSUPP.¶
[Working group input needed]: I might be mistaken but this might contradict material in Section 5.4.1¶
Support for any of the ACL attributes is OPTIONAL, although Recommended. However, a server that supports either of the new ACL attributes (dacl or sacl) MUST allow use of the new ACL attributes to access all of the ACE types that it supports. In other words, if such a server supports ALLOW or DENY ACEs, then it MUST support the dacl attribute, and if it supports AUDIT or ALARM ACEs, then it MUST support the sacl attribute.¶
The dacl attribute is like the acl attribute, but dacl allows only ALLOW and DENY ACEs. The dacl attribute supports automatic inheritance (see Section 5.4.9).¶
The sacl attribute is like the acl attribute, but sacl allows only AUDIT and ALARM ACEs. The sacl attribute supports automatic inheritance (see Section 5.4.9).¶
[Important structural change to be noted]: This section is derived from Section 6.3 of 8881, entitled "Common Methods. However, its content is different because it has been rewritten to deal with issues common to both file access models, which now appears to have not been the original intention. Nevertheless, the following changes have been made:¶
The section "Server Considerations" has been revised to deal with both the mode and acl attributes, since the points being made apply, in almost all cases, to both attributes.¶
The section "Client Considerations" has been heavily revised, since what had been there did not make any sense to me.¶
The section "Computing a Mode Attribute from an ACL" has been moved to Section 7.2.1 since it deals with the co-ordination of the posix and acl authorization models.¶
The server uses the mode attribute or the acl attibute applying the algorithm described in Section 5.4.1 to determine whether an ACL allows access to an object.¶
However, these attributes might not be the sole determiner of access. For example:¶
Clients SHOULD NOT do their own access checks based on their interpretation of the ACL, but rather use the OPEN and ACCESS operations to do access checks. This allows the client to act on the results of having the server determine whether or not access should be granted based on its interpretation of the ACL.¶
[Working group discussion needed]: With regard to the use of "SHOULD NOT" in the paragraph above, it is not clear what might be valid reasons to bypass this recommendation. Perhaps "MUST NOT" or "should not" would be more appropriate.¶
Clients must be aware of situations in which an object's ACL will define a certain access even though the server will not enforce it. In general, but especially in these situations, the client needs to do its part in the enforcement of access as defined by the ACL.¶
[Working group input needed]: Despite what is said later, the only such case I know of is the use of READ and EXECUTE where the client, but not the server, has any means of distinguishing these. don't know of any others. If there were, houw could ACESS or OPEN be used to verify access?¶
To do this, the client MAY send the appropriate ACCESS operation prior to servicing the request of the user or application in order to determine whether the user or application should be granted the access requested.¶
For examples in which the ACL may define accesses that the server doesn't enforce, see Section 6.1.¶
[Working group discussion needed]: The sentence above is clearly wrong since that section is about enforcement the server does do. Sigh!¶
[To be checked]: The section on computing mode from ACL in RFC3530 is quite similar to that in RFC8881. If they are essentially identical, Section 7.2.1 could be moved out of Section 7.2 and apply to all minor versions :-). In addition, there may be additional material that could be generalized in this way.¶
V4.0 servers that support both the mode and acl attributes, like servers for other minor versions, have to appropriately co-ordinate the values. Because much of the material in Section 7.2 does not apply to v4.0, the server is relatively free about how it does this. Nevertheless, that materal is one useful approach and v4.0 implementers may want to consult it, even though the requirements in it do not apply and threcommendations have no normative force.¶
One likely source of a need for different treatment is the absence of a set_mode_masked attribute in v4.0.¶
Clients need to be aware that the v4.1 handling may nor may not be adopted by the server and that the client needs to adapt accordingly.¶
The server that supports both mode and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@". This way, the client can see if semantically equivalent access permissions exist whether the client asks for the owner, owner_group, and mode attributes or for just the ACL.¶
In this section, much depends on the method in specified Section 7.2.1. Many requirements refer to this section. It should be noted that the methods have behaviors specified with "SHOULD" and that alternate approaches are discussed in Section 7.2.2. This is intentional, to avoid invalidating existing implementations that compute the mode according to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by actual permissions on owner, group, and other.¶
[Working group discussion needed]: Given the mixture of RFC2219 terms, I think all of them in Section 7 need review. Further, given the effort that has gone into Section 7, to accommodate these implementations of a draft that was withdrawn decades ago. The idea of trying to make mode and acl match is undercut when there are different valid ways of computing the mode. There shouldn't be. To specify one way to do this is necessary to accomplish the goal here and to do so would not "invalidate" anything. Rather, it would establish, correctly, that such implementations are not implementations of the NFSv4 ACL model, but of the withdrawn POSIX ACL draft.¶
The following method can be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode attribute, based upon an ACL.¶
[Working group discussion needed]: "can be used" says essentially "do whatever you choose" and would make Section 7 essentially pointless. Would prefer "is to be used", "MUST", or "SHOULD" if valid reasons to do otherwise can be found.¶
First, for each of the special identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration. The result of the evaluation will be an NFSv4 ACL mask showing exactly which bits are permitted to that identifier.¶
Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@ into mode bits for, respectively, the user, group, and other, as follows:¶
Some server implementations also add bits permitted to named users and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).¶
Implementations are discouraged from doing this, because it has been found to cause confusion for users who see members of a file's group denied access that the mode bits appear to allow. (The presence of DENY ACEs may also lead to such behavior, but DENY ACEs are expected to be more rarely used.)¶
[Working group decision needed]; the text does not seem to really discourage this practice and makes no reference to the need to standardize behavior or any impediement to doing so. "SHOULD NOT" needs to be considered if valid reasons to do otherwise can be found.¶
The same user confusion seen when fetching the mode also results if setting the mode does not effectively control permissions for the owner, group, and other users; this motivates some of the requirements that follow.¶
In the case where a server supports the sacl or dacl attribute, in addition to the acl attribute, the server MUST fail a request to set the acl attribute simultaneously with a dacl or sacl attribute. The error to be given is NFS4ERR_ATTRNOTSUPP.¶
When any of the nine low-order mode bits are subject to change, either because the mode attribute was set or because the mode_set_masked attribute was set and the mask included one or more bits from the nine low-order mode bits, and no ACL attribute is explicitly set, the acl and dacl attributes must be modified in accordance with the updated value of those bits. This must happen even if the value of the low-order bits is the same after the mode is set as before.¶
Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl attribute) are unaffected by changes to the mode.¶
In cases in which the permissions bits are subject to change, the acl and dacl attributes MUST be modified such that the mode computed via the method in Section 7.2.1 yields the low-order nine bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as modified by the attribute change. The ACL attributes SHOULD also be modified such that:¶
Access mask bits other than those listed above, appearing in ALLOW ACEs, MAY also be disabled.¶
Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect the permissions of the ACL itself, nor do ACEs of the type AUDIT and ALARM. As such, it is desirable to leave these ACEs unmodified when modifying the ACL attributes.¶
Also note that the requirement may be met by discarding the acl and dacl, in favor of an ACL that represents the mode and only the mode. This is permitted, but it is preferable for a server to preserve as much of the ACL as possible without violating the above requirements. Discarding the ACL makes it effectively impossible for a file created with a mode attribute to inherit an ACL (see Section 7.2.8).¶
When setting the acl or dacl and not setting the mode or mode_set_masked attributes, the permission bits of the mode need to be derived from the ACL. In this case, the ACL attribute SHOULD be set as given. The nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result of the method in Section 7.2.1. The three high-order bits of the mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.¶
When setting both the mode (includes use of either the mode attribute or the mode_set_masked attribute) and the acl or dacl attributes in the same operation, the attributes MUST be applied in this order: mode (or mode_set_masked), then ACL. The mode-related attribute is set as given, then the ACL attribute is set as given, possibly changing the final mode, as described above in Section 7.2.5.¶
Some server implementations may provide for the existence of "objects without ACLs", meaning that all permissions are granted and denied according to the mode attribute and that no ACL attribute is stored for that object. If an ACL attribute is requested of such a server, the server SHOULD return an ACL that does not conflict with the mode; that is to say, the ACL returned SHOULD represent the nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as described in Section 7.2.1.¶
For other server implementations, the ACL attribute is always present for every object. Such servers SHOULD store at least the three high-order bits of the mode attribute (MODE4_SUID, MODE4_SGID, MODE4_SVTX). The server SHOULD return a mode attribute if one is requested, and the low-order nine bits of the mode (MODE4_R*, MODE4_W*, MODE4_X*) MUST match the result of applying the method in Section 7.2.1 to the ACL attribute.¶
If a server supports any ACL attributes, it may use the ACL attributes on the parent directory to compute an initial ACL attribute for a newly created object. This will be referred to as the inherited ACL within this section. The act of adding one or more ACEs to the inherited ACL that are based upon ACEs in the parent directory's ACL will be referred to as inheriting an ACE within this section.¶
Implementors should standardize the behavior of CREATE and OPEN depending on the presence or absence of the mode and ACL attributes by following the directions below:¶
If just the mode is given in the call:¶
In this case, inheritance SHOULD take place, but the mode MUST be applied to the inherited ACL as described in Section 7.2.4, thereby modifying the ACL.¶
If just the ACL is given in the call:¶
In this case, inheritance SHOULD NOT take place, and the ACL as defined in the CREATE or OPEN will be set without modification, and the mode modified as in Section 7.2.5.¶
If both mode and ACL are given in the call:¶
In this case, inheritance SHOULD NOT take place, and both attributes will be set as described in Section 7.2.6.¶
If neither mode nor ACL is given in the call:¶
In the case where an object is being created without any initial attributes at all, e.g., an OPEN operation with an opentype4 of OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD NOT take place (note that EXCLUSIVE4_1 is a better choice of createmode4, since it does permit initial attributes). Instead, the server SHOULD set permissions to deny all access to the newly created object. It is expected that the appropriate client will set the desired attributes in a subsequent SETATTR operation, and the server SHOULD allow that operation to succeed, regardless of what permissions the object is created with. For example, an empty ACL denies all permissions, but the server should allow the owner's SETATTR to succeed even though WRITE_ACL is implicitly denied.¶
In other cases, inheritance SHOULD take place, and no modifications to the ACL will happen. The mode attribute, if supported, MUST be as computed in Section 7.2.1, with the MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no inheritable ACEs exist on the parent directory, the rules for creating acl, dacl, or sacl attributes are implementation defined. If either the dacl or sacl attribute is supported, then the ACL4_DEFAULTED flag SHOULD be set on the newly created attributes.¶
If the object being created is not a directory, the inherited ACL SHOULD NOT inherit ACEs from the parent directory ACL unless the ACE4_FILE_INHERIT_ACE flag is set.¶
If the object being created is a directory, the inherited ACL should inherit all inheritable ACEs from the parent directory, that is, those that have the ACE4_FILE_INHERIT_ACE or ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear, the inherited ACE on the newly created directory MUST have the ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being affected by ACEs meant for non-directories.¶
When a new directory is created, the server MAY split any inherited ACE that is both inheritable and effective (in other words, that has neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set), into two ACEs, one with no inheritance flags and one with ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute, both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.) This makes it simpler to modify the effective permissions on the directory without modifying the ACE that is to be inherited to the new directory's children.¶
The v4.1 server implementation requirements described in Section 7.2 apply to v4.2 as well and v4.2 clients can assume that the server follows them.¶
V4.2 contains an OPTIONAL extension, defined in [13], which is intended to reduce the interference of modes, restricted by the umask mechanism, with the acl inheritance mechanism. The extension allows the client to specify the umask separately from the mask attribute.¶
The labelled NFS feature of NFSv4.2 is designed to support Mandatory Access control.¶
The attribute sec_label enables an authorization model focused on Mandatory Access Control and is described in Section 8.¶
Not much can be said about this feature because the specification, in the intrest of fexibility has left important features undefined in order to alllow future. As a result, we have something that is a framework to allow Mandatory Acces Control rather than one to provide it. In particular,¶
The sec_label attribute, which provides the objects label has no existing specfication.¶
There is no specfication of the of the format of the subject label or way to authenticate them.¶
As a result, all authorization takes place on the client, and the server simply accepts the client's determination.¶
This arrangements shares important similarities with AUTH_SYS. As such it makes sense:¶
Modification of locking and session state data should not be done by a client other than the one that created the lock. For this form of authorization, the server needs to identify and authenticate client peers rather than client users.¶
Such authentication is not directly provided by any RPC authentication flavor. However, RPC-based transport, when sitable configured. can provide this authenication.¶
NFSv4.1 defines a number of ways to provide appropriate authorization facilities. These will not be discussed in detail her but the follwing points should be noted:¶
NFSv4.1 defines the MACHCRED mechanism which uses the RPCSEC_GSS indrastrucure to provide authentication of the clients peer. However, this is of no value when AUTH_SYS is being used.¶
NFSv4.1 also defines the SSV mechanism which uses the RPCSEC_GSS infrastructure to enable it to be reliably determined whether two different client connections are connected to the same client. It is unclear whether the word "authentication" is appropriate in this case. As with MACHCRED, this is of no value when AUTH_SYS is being used.¶
Because of the lack of support for AUTH_SYS and for NFSv4.0, it is quite desirable for clients to use and for servers to require the use of client-peer authentication as part of connection establishment.¶
When unauthenticated clients are allowed, their state is expsed to unwanted modification as part of disruptuion or denial-of-service attcks. as a resul the potential burdens of such attacks are felt principally by client not to provide such authentication.¶
Various objects and subjects need to be identified for a protocol to function. For it to be secure, many of these need to be authenticated so that incorrect idenifification is not the basis for attacks.¶
It is necessary to be clear about this distinction which has been obscured in the past, by the use of the term "RPC Authentification Flavor" in connection with situation in which identification without authentication occrred or in which there was neither identification nor authentication involved. As a result, we will use the term "RPC Flavors" instead¶
Some identifier are not security-relevant and can used be used without authentication, given that, in the authorization decision, the object acted upon needs only to be properly identified¶
File names are of this type.¶
Unlike the case for some other protocols, confusion of names that result frominternationalization issue, while an annoyance are not relevant to security. If the confusion between LATIN CAPITAL LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file being accessed, the mechanisms dscribed in Section 5 prevent in appropriate access being granted.¶
Despite the above, it is desirable if file names togeter with similar are not transferred in the clear as the information exposed may give atackers useful information helpful in planning and executing atacks.¶
The case of file handles is similar.¶
Identifier that refer to state shared between client and server can be the basis of disruption attacks since clients and server necessaily assume that neither side will change the state corpus without appropriate notice.¶
While these identifiers do not need to be authenticated, they are associated with higher-level entities for which change of the state represented by those entities is subject to peer authentication.¶
Unexpected closure of stateids or changes in state sequence values can disrupt client access as no clients have provision to deal with this source of interference.¶
While encryption may make it more difficult to execute such attacks attackers can often guess stateid's since server generally not randomize them.¶
Similarly, modification to v4.1 session state information can result in confusion if an attacker changes the slot sequence by assuing spurious requests. Even if the request is rejected, the slot sequence is changed and clients may a difficult time getting back in sync with the server.¶
While encryption may make it more difficult to execute such attacks attackers can often guess slot id's and obtain sessinid's since server generally do not randomize them.¶
it is necessary that modification of the higher-levell entities be restricted to the client that created them.¶
Identifiers describing the issuer of the request, whether in numeric or string form always require authentication.¶
Different flavors differ quite consderably, as discussed below;¶
When AUTH_NONE is used, the user making the request is neither authenticated nor identified to the server.¶
Also, the server is not authenticated to the client and has no way to determine whether the server it is communicating with is an imposter.¶
When AUTH_SYS is used, the user making is the request identified but there no authentication of that identification.¶
As in the previous case, the server is not authenticated to the client and has no way to determine whether the server it is communicating with is an imposter.¶
When RPCSEC_GSS is used, the user making the request is authenticated as is the server peer responding.¶
Different transports differ quite consderably, as discussed below. In contrast to the case of RPC flavors, any authentication happens once, at connection establishment, rather than on each RPC request. As a result, it is the client and server peers, rather than individual users that is authenticated.¶
The only flavor providing these facilities is RPCSEC_GSS. When this flavor is used, data security can be negotiated between client and server as described in Section 12.2. However, when data security is provided at the transport level, as described in Section 11.2, the negotiation of privacy and integrity support is unnecessary,¶
Other flavors, such as AUTH_SYS and AUTH_NONE have no such data security facilities. When these flavor are used, the only data security is provided by the transport.¶
Some transports provide data security for all transactions performed on them, eliminating the need for that security to be provided or negotiated by the selection of particular flavors, mechanism, or services.¶
As previously in NFSv4, we use the term "negotiation" to characterize the process of the server providing a set of options and the client selecting one.¶
The use of SECINFO, possibly with SECINFO_NONAME, remains the primary means by which the security parameters are determined. The addition of transports to flavors in providing security has resulted in the following changes:¶
Transport-related security choices are typically decided at connection-establishment so there needs to be provision for negotiation at this point.¶
Despite the above, because the choices of flavor and transport affect one another, SECINFO has been extended by the addition of pseudo-flavors, while retaining the existing XDR, to allow negotiation of transport choices and accompanying connection establishment options, in addition to selection of flavors and accompanying services. This allows server policies for such matters to be different for different portions of the namespace.¶
The flavor field of the secinfo4 items returned by SECINFO and SECINO_NONAME have always allowed pseudo flavors to be included. However, previous treatments of these operations have not provided information about how responses containing such pseudo-flavors are to be interpreted.¶
Those pseudo-flavors now provide a means of extending the negotiation process so it is capable of providing for the negotiation of the use particular RPC transports and security-related options for the connections established using those transports.¶
The flavors AUTH_NONE, AUTH_SYS and RPCSEC_GSS continue to indicate the acceptability of the corresponding method of user authentication, user identification, or user non-identification, when used with a particular RPC transport.¶
The flavor AUTH_TLS, which is not used as part of issuing requests is not included in this list and is treated as a connetion-type--specifying pseudo-flavor.¶
secinfo4s for the flavor RPCSEC_GSS contains additional information describing the specific secrity lgorithm to be used and the ancillary services to be provided (e.g. integrity, privacy) when these services are not provided by the trnsport.¶
Such flavors are referred to as "flavor-specifying flavors"¶
The classification below organizes the flavors and pseudo-flavors used in security negotiation while Section 12.4 describes how the set of secinfos in a response can be used by the client to select acceptble combinations of security flavor, security mechanism, security services, security-related transports, and security-related connection chractertics.¶
The pseudo-flavors designating a security-relevant transport type, together with AUTH-TLS, nominally a flavor but used as a pseudo-flavor in connection with SECINFO.¶
Such pseudo-flavors are referred to as "transport- specifying flavors".¶
The pseudo-flavors designating restrictions on acceptble connnection characteristics include XPCH_ENCRYPT, XPCH_PEERAUTH, and XPCH_SECURE.¶
Such pseudo-flavors are referred to as "transport-restriction flavors".¶
The pseudo-flavors combining a flavor designation together with a restriction conerninng the connections it is relevant to include AUTHXP_CLIENTPEER, AUTHXP_ENCRYPT, AUTHXP_SECURE.¶
Such pseudo-flavors are referred as tranport-hybridized flavors.¶
The special pseudo-flavors, XPBREAK and XPCURRENT¶
Such pseudo-flavors are referred to connection-organizing flavors.¶
For the current connection, this proceeds as it has previously, when security-relevant transports were not available. Flavor entties, including those including mechanism information are listed in order of server preference and apply, by default, to the current connection, which normally is favored by the server.¶
When other transport-identifying pseudo-flavors appear before the flavor entries, then the server is indicating that these transport types, with the server preference following the ordering of the entries. In this case, any flavor entries that follow a transport entry specify that flavor is usable with the transport types denoted by that transport entry.¶
First we define some necessary terminology.¶
A transport type specifies one of a small set of RPC transport types such as TCP or RDMA. Each such transport type has an associated pseudoflavor. There are also pseudo-flavors that specify a set of transport types such as XPT_ALL.¶
Connection characteristics are designations of security-relevant characteristics or sets of characteristics that connections might have.¶
There are pseudo-flavors associated with connection characteristics such as CONCH_CPAUTH, denoting client-peer authentication and CONCH_ENCRYPT, denoting the presence of an encrypted channel. The pseudo-flavor CONCH_SECURE denotes the presence of peer mutual authentication together with the use of an encrypted channel.¶
The combination of a transport type with a set of connection chracteristics is considered a connection type..while many connection types are designated by a combination of a flavor designating a transport with on designating a set of connection chacteristics, ther are pseudo flavor that designate a connection type directly.¶
For example, the flavor AUTH_TLS is equivalent to XP_TCP combined with CONCH_ENCRYPT, while the pseudo-flavor XP_TCP_SECURE equivalent to XP_TCP comnined with CONCH_SECURE.¶
A flavor specification designates a specific flavor, or, in the case of RPCSEC_GSS, a flavor combined with additional mechanism and service information.¶
A flavor assigment denote the assiciation of a specfic flavor specification with a connection type.¶
A secinfo response will designate a set of valid flavor assigments with an implied server ordering derived from the order that the entries appear in.¶
In interpreting the response array the client is to maintain sets of designated transport typtes, connection characteristics and connection types specfied indidually (i.e. without separately specifying transport types and connection characteristics). When a flavor soecfication is encuntered, that flavor is considered valid when used with all curently active connection types, defined by the unionof the individually specified connection types and the cartesian product of the current transport types and current connection types.¶
The presumed ordering of these assigments is as follows:¶
[TBD in -01]¶
The description in the sub-sections below, while it adheres to the XDR appearing [6], [7], [8], [9] and [11]. will supersede the descriptions in [7] and [8].¶
This is necessary to adapt the security negotiation process to the presence of transport-level security services such as encryption and peer authentication.¶
Sumilar changes are necessary in the parallel SECINFO_NONAME operation introduced in NFSv4.1. These are expected to be done as part of the rfc5661bis effort.¶
struct SECINFO4args {
/* CURRENT_FH: directory */
component4 name;
};
/*
* From RFC 2203
*/
enum rpc_gss_svc_t {
RPC_GSS_SVC_NONE = 1,
RPC_GSS_SVC_INTEGRITY = 2,
RPC_GSS_SVC_PRIVACY = 3
};
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
/* RPCSEC_GSS has a value of '6' - See RFC 2203 */
union secinfo4 switch (uint32_t flavor) {
case RPCSEC_GSS:
rpcsec_gss_info flavor_info;
default:
void;
};
typedef secinfo4 SECINFO4resok<>;
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
/* CURRENTFH: consumed */
SECINFO4resok resok4;
default:
void;
};
The SECINFO operation is used by the client determine the appropriate RPC authentication flavors, security mechanisms and encrypting transports to access a specific directory filehandle, file name pair. SECINFO should apply the same access approach used for LOOKUP when evaluating the name. In consequence, if the requester does not have the appropriate access to LOOKUP the name, then SECINFO will behave the same way and return NFS4ERR_ACCESS.¶
The result will contain an array that represents the security flavor, security mechanisms and transports available, with an order corresponding to the server's preferences, the most preferred being first in the array. The client is free to pick whatever security flavors, mechanisms and transports it both desires and supports, or to pick in the server's preference order the first one it supports. The array entries are represented by the secinfo4 structure. The field 'flavor' will contain one of the following sorts of values:¶
a value of AUTH_NONE, AUTH_SYS (as defined in RFC 5531 [4]).¶
AUTH_TLS as described in ...¶
A pseudo-flavor defined in Section 14.2¶
Any other security flavor or pseudo-flavor registered with IANA.¶
For the flavors other than RPCSEC_GSS, no additional security information is returned. For a return value of RPCSEC_GSS, a security triple is returned that contains the mechanism object identifier (OID, as defined in RFC 2743 [3]), the quality of protection (as defined in RFC 2743 [3]), and the service type (as defined in RFC 2203 [2]). It is possible for SECINFO to return multiple entries with flavor equal to RPCSEC_GSS with different security triple values.¶
On success, the current filehandle is consumed, so that, if the operation following SECINFO tries to use the current filehandle, that operation will fail with the status NFS4ERR_NOFILEHANDLE.¶
If the name has a length of zero, or if the name does not obey the UTF-8 definition in cirsumstanes in which UTF-8 names are required, the error NFS4ERR_INVAL will be returned.¶
See Sections 12.2 through 12.4 for additional information on the use of SECINFO.¶
The SECINFO operation is expected to be used by the NFS client when the error value of NFS4ERR_WRONGSEC is returned from another NFS operation. This signifies to the client that the server's security policy is different from what the client is currently using. At this point, the client is expected to obtain a list of possible security flavors and choose what best suits its policies.¶
[TBD in -01]¶
As mentioned, the server's security policies will determine when a client request receives NFS4ERR_WRONGSEC.¶
See Table 14 of [8] for a list of operations that can return NFS4ERR_WRONGSEC. in the case of v4.2, there might be extensions alloed to return NFS4ERR_WRONGSEC. In addition, when READDIR returns attributes, the rdattr_error (Section 5.8.1.12 of [8]) can contain NFS4ERR_WRONGSEC.¶
Note that CREATE and REMOVE MUST NOT return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the target name exists, it cannot have a separate security policy from the parent directory, and the security policy of the parent was checked when its filehandle was injected into the COMPOUND request's operations stream (for similar reasons, an OPEN operation that creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target name exists, while it might have a separate security policy, that is irrelevant because CREATE MUST return NFS4ERR_EXIST. The rationale for REMOVE is that while that target might have a separate security policy, the target is going to be removed, and so the security policy of the parent trumps that of the object being removed. RENAME and LINK MAY return NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error applies only to the saved filehandle (see Section 2.6.3.1.2 of [8]). Any NFS4ERR_WRONGSEC error on the current filehandle used by LINK and RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH operation that injected the current filehandle.¶
With the exception of LINK and RENAME, the set of operations that can return NFS4ERR_WRONGSEC represents the point at which the client can inject a filehandle into the "current filehandle" at the server. The filehandle is either provided by the client (PUTFH, PUTPUBFH, PUTROOTFH), generated as a result of a name-to-filehandle translation (LOOKUP and OPEN), or generated from the saved filehandle via RESTOREFH. As oSection 2.6.3.1.1.1 of [8] states, a put filehandle operation followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC. Thus, the RESTOREFH operation, under certain conditions (see Section 2.6.3.1.1 of [8]), is permitted to return NFS4ERR_WRONGSEC so that security policies can be honored.¶
The READDIR operation will not directly return the NFS4ERR_WRONGSEC error. However, if the READDIR request included a request for attributes, it is possible that the READDIR request's security triple did not match that of a directory entry. If this is the case and the client has requested the rdattr_error attribute, the server will return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.¶
To resolve an error return of NFS4ERR_WRONGSEC, the client does the following:¶
For LOOKUP and OPEN, the client will use SECINFO with the same current filehandle and name as provided in the original LOOKUP or OPEN to enumerate the available security triples.¶
For the rdattr_error, the client will use SECINFO with the same current filehandle as provided in the original READDIR. The name passed to SECINFO will be that of the directory entry (as returned from READDIR) that had the NFS4ERR_WRONGSEC error in the rdattr_error attribute.¶
For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the client will use SECINFO_NO_NAME { style = SECINFO_STYLE4_CURRENT_FH }. The client will prefix the SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or PUTROOTFH operation that provides the filehandle originally provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH operation.¶
NOTE: In NFSv4.0, the client was required to use SECINFO, and had to reconstruct the parent of the original filehandle and the component name of the original filehandle. The introduction in NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction.¶
For LOOKUPP, the client will use SECINFO_NO_NAME { style = SECINFO_STYLE4_PARENT } and provide the filehandle that equals the filehandle originally provided to LOOKUPP.¶
[To be fleashed out in -01]: This section is basically an outline for now, to be filled out laater based on Working Group input, particularly from Chuck lever who suggested this section and has ideas about many of the items in it.¶
Security for data-at-rest, most probably based on facilities defined within SAN.¶
Support for content signing.¶
Revision/extension of labelled NFS to provide true interoperability and server-based authorization.¶
Work to provide more security for RDMA-based transports. This would include the peer authentication infrastructure now being developed as part of RPC-over-RDMA version 2. In addition, there is a need for an RPC-based transport that provides for encyption, which might be provided in number of ways.¶
Beyond the needed inclusion of a threat analysis and the fact that all minor versions are dealt with together, there are a number of substantive changes in the approach to NFSv4 security presented in RFCs 7530 and 8881 and that appearing in this document.¶
This document will not seek to speculate how the previous treatment, now viewed as incorrect, came to be written, approved, and published. However, it will, for the benefit of those familiar with the previous treatment of these matters, draw attention to the important changes listed here.¶
There is a vastly expanded range of threats being considered as described in Section 13.1.1¶
New facilities available at the RPC transport level can be used to deal with security issues, as described in Section 13.1.2¶
Although the absence of a threat analysis in previous treatments makes comparison most difficult, the security-related features described in previous specifications and the associated discussion in their security considerations sections makes it clear that earlier specifications took a quite narrow view of threats to be protected against.¶
One aspect of that narrow view that merits special attention is the handling of AUTH_SYS, at that time in the clear, with no client peer authentication.¶
With regard to specific threats, there is no mention in existing security consideration sections of:¶
The handling of data security in-flight is even more troubling.¶
Although there was considerable work in the protocol to allow use of encryption to be negotiated when using RPCSEC_GSS. The existing security considerations do not mention the potential need for encryption at all.¶
It is not clear why this was omitted but it is a pattern that cannnot repeated in this document.¶
The case of negotiation of integrity services is similar and uses the same negotiation infrastructure.¶
In this case, use of integrity is recommended but not to prevent the corruption of user data being read or written.¶
The use of integrity services is recommended in connetion with issuing SECINFO (and for NFSv4.1, SECINFO_NONAME). The presence of this recommendation in the associated security considerations sections has the unfortunate effect of suggesting that the protection of user data is of relatively low impotance.¶
Such transport-level RPC facilitites as RPC-over-TLS provide important ways of proving better security for all the NFSv4 minor versions.¶
In particular:¶
The presence of encryption by default will deal with security issue regarding data-in-flight, for both RPCSEC_GSS and AUTH_SYS.¶
Peer authentication provided by the server eliminates the possibility of a server-impersonation attack, even when using AUTH_SYS.¶
When mutual authentication is part of connection establishment, there is a possibility, where an appropriate trust relationship exisrts of treating the userid's presented in AUTH_SYS, as effectively authenticated, based on the authetication of the client peer.¶
Given the need to drastically change the NFSv4 security approach from that specified previously, it is necessary for us to be mindful of:¶
The difficulty that might be faced in adapting to the newer guidance because the delays involved in designing, developing, and testing new transport- level security facilities such as RPC-over-TLS.¶
The difficulty in discarding or substantially modifying previous existing deployments and practices, developed on the basis of previous normative guidance.¶
For these reasons, we will not use the term "MUST NOT" in some situations in which the use of that term might have been justified earlier. In such cases, previous guidance together with the passsage of time may have created a situation in which the considerations mentioned above in this section may be valid reasons to defer, for a limited time, correction of the current sitution making the term "SHOULD NOT" appropriate, since the difficulties cited would constitute a valid reason to not allow what hsd been recommended against.¶
An important change concerns the treatment of AUTH_SYS which is now divided into two subcases given the possible availabillity of support from the transport layer.¶
When such support is not available, AUTH_SYS SHOULD NOT be used, since it makes the following attacks quite easy to execute:¶
The absence of authentication of the server to the client allow server impersonation in which an imposter server can obtain data to be written by the user and supply corrupted data to read requests.¶
The absence of authentication of the client user to the server allow server impersonation in which an imposter client can issue requests and have them executed as a user designated by imposter client, vitiating the server's authorization policy.¶
With no authentication of the client peer, common approaches, such as using the source IP address can be easily defeated, allowing unauthenticated execution of requests made by the pseudo clients¶
The absence of any support to protect data-in-flight when AUTH_SYS is used result in further serious security weaknesses.¶
In connection with the use of the term "SHOULD NOT" above, it is understood that the "valid reasons" to use this form of access reflect the Compatibility and Maturity Issue discussed above in Section 13.1.3 and that it is expected that, over time, these will become less applicable.¶
[Working group discussion needed]: For now, we will not consider different security policies for different sorts of environments. This is because of:¶
Although the security goal for Nfsv4 has been and remains "secure use on the internet", much use of NFSv4 occurs on more restricted IP networks with NFS access from outside the owning organization prevented by firewalls.¶
This security considerations section will not deal separately with such environments since the threats that need to be discussed are essentially the same, despite the assumption by many that the restricted network access would eliminate the possibility of attacks originating inside the network by attackers who have some legitimate Nfsv4 access within it.¶
In organizations of significant size, this sort of assumption of trusted access is usually not valid and this document will not deal with them explicitly. In any case, there is little point in doing so, since, if everyone can be trusted, there can be no attackers, rendering threat analysis superfluous.¶
This does not mean that NFSv4 use cannot, as a practical matter, be made secure through means outside the scope of this document including strict administrative controls on all software running within it, frequent polygraph tests, and threats of prosecution. However, this document is not prepared to discuss the details of such policies, their implementation, or legal issues associated with them and treats such matters as out-of-scope.¶
Nfsv4 can be used in very restrictive IP network environments where outside access is quite restricted and there is sufficient trust to allow, for example, every node to have the same root password. The case of a simple network only accessible by a single user is similar. In such networks, many thing thats this document says "SHOULD NOT" be done are unexceptionable but the responsibility for making that determination is one for those creating such networks to take on. This document will not deal further with NFSv4 use on such networks.¶
We RECOMMEND that requesters always issue requests with data security (i.e. with protection from disclosure or modification in flight) whether provided at the RPC request level or by the RPC transport, irrespective of the responder's requirements.¶
We RECOMMEND that implementers provide servers the ability to configure policies in which requests without data security will be rejected as having insufficient security.¶
We RECOMMEND that servers use such policies over either their entire local namespace or for all file systems except those clearly designed for the general dissemination of non-sensitive data.¶
We RECOMMEND that clients provide authentication material whenever a connection is established with a server capable of using it to provide client peer authentication.¶
We RECOMMEND that implementers provide servers the ability to configure policies in which attempts to establish connections without client peer authentication will be rejected.¶
We RECOMMEND that servers adopt such policies whenever requests not using RPCSEC_GSS are allowed to be executed.¶
Clearly, the maturity and compatibility issues mentioned in Section 13.1.3 are valid reasons to nypass the above recommenations, as loong as thse issues continue to exist.¶
[Working group discussion needed}: The question the working group needs to address is whether other valid reasons exist.¶
[Working group discussion needed}: In particular, some members of the group might feel that the performance cost of encrypted transports constitutes, in itself, a valid reason to ignore the above recommendations.¶
[Working group discussion needed}: I cannot agree and feel that accepting that as a valid reason would undercut Nfsv4 security improvement, and probably would not be acceptable to the security directorate. However, I do want to work out an a generally acceptable compromise. I propose something along the following lines:¶
[TBD in -01]¶
Because of the shift from implementing security-related services only in connection with RPCSEC_GSS to one in which transport-level security has a prominent role, a number if new values need to be assigned.¶
These include new authstat values to guide selection of a Transports aceptable to both client and server, presented in Section 14.1 and new pseudo-flavors to be used in the process of security negotion, presented in Section 14.2.¶
The following new authstat values are necessary to enable a server to indicte that the server's policy does not allows requests to be made on the current connection because of security issues associated with the rpc transport. In the event they are received, the client need to establish a new connection.¶
The value XP_CRYPT indicates that the server will not support access using unencrypted connections while the current connection is not encrypted.¶
The value XP_CPAUTH indicates that the server will not support access using connections for which the client peer has not authenticad itelf as part of connection while the current connection has not been set up in that way.¶
The following new pseudo-flavors are made available to allow their return as part of the response to SECINFO operation described in Section 12.5 and for similar operations.¶
[TBD in -01]¶
The author wishes to thanl tom haynes for his helpful suggestion to deal with security for all NFSv4 minor versions in the same document.¶
The author wishes to draw people's attention to Nico Williams' remark that NFSv4 security was not so bad, except that there was no provision for authentication of the client peer. This perceptive remark, which now seems like common sense, did not seem so when made, but it has served as a beacon for those putting NFSv4 security on a firmer footing. Our gratitude is appropriate.¶
The author wishes to acknowledge the important role of the authors of RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS security agenda forward and thank them for all their efforts to improve NFS security.¶
The author wishes to thank Chuck Lever for his many helpful comments about nfsv4 security issues, his explanation of many unclear points, and and much important guidance he provided that is reflected in this document.¶
The author wishes to thank Rick Macklem for his role in clarifying possible server policies regarding RPC-over-TLS and bringing possible approaches to the attention of the working group.¶