Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-03.txt

[Rick Macklem <[e-mail]>]

Sorry. Stupid frickin windows and outlook...

I've added the rest of the text this time around

________________________________________
From: nfsv4 <[e-mail]> on behalf of Rick Macklem <[e-mail]>
Sent: Wednesday, December 1, 2021 8:36 PM
To: J. Bruce Fields; David Noveck
Cc: NFSv4; [e-mail]; nfsv4-chairs
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-03.txt

J. Bruce Fields wrote:
> On Tue, Nov 23, 2021 at 08:55:04AM -0500, David Noveck wrote:
> > This is considerably different from -02 (1400 lines).  Still, a diff
> > between -02 and -03 is useful to see where the changes/additions are, if
> > you read -02.
>
> 5.9: special identifiers: "when ACEs containing these who values are
> encountered, the server MUST treat all requesting users as not
> matching."
>
> So a two-ACE ACL like:
>
>         allow read to INTERACTIVE
>         deny everything to EVERYONE
>
> would require the server to fail all NFS READs, and an ACL like:
>
>         deny read to INTERACTIVE
>         allow everything to EVERYONE
>
> would require the server to allow all NFS READs.
>
> Presumably these special identifiers are mainly only there for the
> multiprotocol case--the server can actually make use of them when
> accessed by an SMB client, but we still want NFS clients to be able to
> e.g. do ACL-preserving copies, so we want NFS clients to still see them.
>
> So I guess it's a sensible default to treat those special identifiers as
> describing groups of which no NFS user is a member.
>
> Seems more like "a sensible default", though, rather than something to
> be enshrined in a MUST.  I could imagine server administrators wanting
> the option to configure this.
>
> I'd rather leave this unspecified.  At least, unless we can get input
> from a wide range of server implementors.
I agree with Bruce on this. At this time, the FreeBSD server will normally
fail a Setattr of ACL if any ACE in the ACL has one of the "special who"s
(except for OWNER@, GROUP@ and EVERYONE@). For full disclosure, the
way the code is currently written, a sysadmin could put a "special who" in
the password database and it would be recognized as that user. I suppose
that could be considered a bug.

However, I do think that a POSIX-like server, such as FreeBSD, could choose
to implement POSIX groups that corresponded to these "special who"s,
as Bruce mentioned.

I don't see why that should not be allowed and think it is up to the server
implementor/sysadmin.

rick

That goes double for ANONYMOUS and AUTHENTICATED.  I don't know all the
ways that export permissions and idmapping (like squashing) are
implemented on different servers and I'm not sure we can reasonably come
up with rules that will work for everyone.

--b.

>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Tue, Nov 23, 2021 at 8:45 AM
> Subject: New Version Notification for draft-dnoveck-nfsv4-security-03.txt
> To: David Noveck <[e-mail]>
>
>
>
> A new version of I-D, draft-dnoveck-nfsv4-security-03.txt
> has been successfully submitted by David Noveck and posted to the
> IETF repository.
>
> Name:           draft-dnoveck-nfsv4-security
> Revision:       03
> Title:          Security for the NFSv4 Protocols
> Document date:  2021-11-23
> Group:          Individual Submission
> Pages:          139
> URL:
> https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
> Html:
> https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-03.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-security-03
>
> Abstract:
>    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 by RPC on a per-
>    connection basis.
>
>    This preliminary version of the document, is intended, in large part,
>    to result in working group discussion regarding existing NFSv4
>    security issues and to provide a framework for addressing these
>    issues and obtaining working group consensus regarding necessary
>    changes.
>
>    When a successor document is eventually 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.
>
>
>
>
> The IETF Secretariat

> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4