Re: [nfsv4] Going forward on the security document

[Frank Filz <[e-mail]>]

> From: nfsv4 [mailto:[e-mail]] On Behalf Of Jeff Layton
> 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.

NFS-Ganesha also translates between POSIX and NFSv4 ACLs in hopefully the
same way as the kernel (no guarantee it's a perfect match). NFS-Ganesha also
supports the non-RFC sideband protocol to provide POSIX ACL support to NFSv3
clients.

NFS-Ganesha has some level of support of NFSv4 ACLs when IBM's GPFS is the
back end FSAL. I don't know the details of how closely their ACL
implementation matches RFC 3530 and it it was updated in any way for
subsequent RFCs.

I don't know if any out of tree FSALs implement NFSv4 ACLs. There has been
talk but no action towards implementing Rich ACLs for the Cephfs backend.

NFS-Ganesha does not yet reject ACLs it cannot properly enforce per RFC.

> > 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]>
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

Frank Filz