Re: [nfsv4] Going forward on the security document

[Jeff Layton <[e-mail]>]

On Wed, 2024-02-14 at 11:07 -0500, David Noveck wrote:
> This message is my attempt to summarize the results of discussion of the v4 security document that occurred at the interim meeting this afternoon. 
> This email is  my attempt to summarize  the results of discussion of the security document that occurred at the 2/13 Interim Wrorking Group meeting.   This document is being done as part of the rfc5661bis effort .
> 
> Although I have tried to be accurate, it should be noted that I have made no attempt to coordinate with others present and that others may have different views as to what was discussed/decided.
>  
> I decided to try to simplify processing, as suggested by a number of people, by splitting out the ACL-related material from the security document proper .  I will then try to address the difficult issues created when ACLs were added to NFSv4 without clear semantic requirements in a separate document, devoted to ACLs
>  
> As a result, the next draft of the security document, draft-dnoveck-nfsv4-security-08, will limit the discussion of acl-related issues by treating acls as an EXPERIMENTAL feature to be described in a separate document.  
>  
> That document, initially draft-dnoveck-nfsv4-acls-00 will explain why the experiment adopted initially in rfc3010 and propagated without major changes to rfcs 3530, 5661, 7530, and 8881 was a failure which it does not make sense to continue.  Instead, I will, as I proposed at the meeting, change the focus of the focus ACL description on a simplified core baased on the withdrawn draft POSIx ACLs with provisions for extensions of that model that have actually.   I will be sending out in the week, a description of ONTAP ACL support  which includes a number of such extensions.
> 
> This approach is the reverse of the one adopted in rfc3010 and subsequent rfcs in which ACLs including a massive set of extensions was presented as canonical, but was supplemented by some dubious material which essentially said "Oh by the way, if any of this inconvenient, feel free to ignore it. " 
> 
> We will be needing information about actual implementations of some of the ACL extensions discussed in existing documents and have to be prepared to simply drop material that was never implemented.  In particular,  as far as I know, the troublesome behavior, derived from windows acl implementation, mentioned in the meeting in which deny ACL are scanned and effected after all requested permissions was never described in NFSv4 and probably never implemented.   As a result, it is likely that concern about its effect on the specification of NFSv4 ACLs was misplaced.
> 

Linux nfsd translates between NFSv4 and POSIX ACLs based upon the method
described here:

    https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-05

This is of course lossy and there are ACEs that it could never handle
correctly (like want to make something writeable but not give delete
permissions? Too bad). It also would reorder ACEs to conform to the
well-defined order of evaluation in POSIX ACLs since we can't preserve
the given ordering.

> There are also a number of related matters that were discussed without resulting in any agreement.   The following uissues will need to be addressed on the wg list and in subsequent meetings:
>  * Chris I. raised what he described as a set of  problems with NFSv4's handling of "identity".   The ensuing discussion led me to conclude that he was referring to two different issues:
>     - The lack of clarity about mapping between uid/gid values and the strings used to represent users and groups.   With regard to this issue, I tend to agree with Brian P.'s point that these are properly treated as implementation matters.   I will try to make this clearer in forthcoming drafts.
>     - At a later point in the discussion, it appeared that many of Chris's concerns were prompted by the disturbing ease with which a client might represent himself as a given named user.  While it is possible that such impersonation might be made more likely by flaws in the mappings between names and numeric ids, the fundamental issue here is inherited from NFSv2 and NFSv3 implementations, in which AUTH_SYS is used, allowing unauthenticated requests to be executed, given the common use of AUTH_SYS and the lack of facilities for client peer authentication.
> > >  The material in -08 will address this issue pretty much as was done in -07, pointing out the security problem involved in use of AUTH_SYS, without going so far forbidding its use or formally RECOMMENDING against it.   While we may not have reached consensus on this, I don't see any obstacles to it.
> > Although I feel that the shift from numeric ids to strings made between v3 and v4 was, like the inclusion of ACLs without a clear semantics model for their use, a mistake, it is not possible for  us to undo that mistake.   I think it will be possible to clarify the role of name mapping by not requiring the mapping of ids to names when AUTH_SYS is used, although the numeric ids need to (trivially) mapped to strings.  I will try to see what can be done in that regard in -08, without crossing any red lines.
>  * Tom H.  raised issues regarding potential XDR changes which he found troubling.   Chris agreed to post the diffs between RFC5662 and the most recent draft of rfc5662bis.  While Tom never wavered from his position that any such differences were inherently impermissible, I need to point out that these changes which reorganized the typedefs while keeping what is sent  OTW as formally opaque are analogous to the xdr changes made between rfc 3531 and 7531 and are not a problem.  The working group will have to discuss this issue further but I think consensus is achievable.
>  * The repeated suggestions by Brian that the NFSv4 server could be defined  as an "interpreter" depending on the server fs's choice of semantics have never been addressed.  In my view, the working group needs to seriously consider this possibility and clearly reject it.  I don't think we can publish a purported Proposed Standard that leaves so much material unspecified, even if the IETF/IESG could somehow be convinced to accept it.
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

>From my standpoint, allowing us to present and manipulate POSIX ACLs
properly across v4 sounds like a very welcome change!
-- 
Jeff Layton <[e-mail]>