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

[David Noveck <[e-mail]>]

On Tue, Dec 28, 2021, 11:32 PM Rick Macklem <[e-mail]> wrote:

> David Noveck wrote:
> > On Sun, Dec 26, 2021, 11:45 AM Rick Macklem wrote:
> > > David Noveck wrote:
> > > > Rick Macklem wrote:
> > > > [stuff snipped]
> > > > > Does the Linux client expect "owner-override"?
> > > > >If no one familiar with the Linux client answers this, I'll run a
> test on a Linux
> > > > > mount.
> > > > I ran the following little test program. It ran fine on local file
> systems and on
> > > > an NFSv4 mount for both the FreeBSD and Linux-5.15.1 clients, if
> > > > "owner-override" was applied to Read/Write.
> > >
> > > > Is there documentation for this option?  I have googled for these
> words several
> > > > times and come up empty.  We need a clear definition of these
> semantics to
> > > > resolve this issue in -05 and that documentation might be helpful.
>  If it isn't,
> > > > could you point me to code, preferably in bsd, implementing that
> option.
> > > Well, I'm not sure if/when the term "owner-override" cropped up, but
> here is
> > >a description of it from RFC 1813 pg. 98:
> >
> > Thanks.  This is helpful.
>
> > >   Another problem arises due to the usually stateful open
> > >   operation.  Most operating systems check permission at open
> > >   time, and then check that the file is open on each read and
> > >   write request. With stateless servers, the server cannot
> > >   detect that the file is open and must do permission checking
> > >   on each read and write call. UNIX client semantics of access
> > >   permission checking on open can be provided with the ACCESS
> > >   procedure call in this revision, which allows a client to
> > >   explicitly check access permissions without resorting to
> > >   trying the operation. On a local file system, a user can open
> > >   a file and then change the permissions so that no one is
> > >   allowed to touch it, but will still be able to write to the
> > >   file because it is open. On a remote file system, by
> > >   contrast, the write would fail. To get around this problem,
> > >   the server's permission checking algorithm should allow the
> > >   owner of a file to access it regardless of the permission
> > >   setting. This is needed in a practical NFS version 3 protocol
> > >   server implementation, but it does depart from correct local
> > >   file system semantics. This should not affect the return
> > >   result of access permissions as returned by the ACCESS.
> > >
>

In -05, the Author Aside quotes this in full, but the replacement text
refer to it without quoting it.

> > > See the 3rd sentence from the end.
>

I notice that it use the (lower-case) word "should".   given that RFC1813
is an informational RFC this probably isn't all that relevant.

In the replacement text I make this a MAY, principally because there are
other ways of providing for this

> > >
> > > As far as I know, servers implement the same thing for Read/Write
> > > for NFSv4.
>

This will be a MAY in -05.


> >
> > From your description and the testing you have done, it seems there is a
> > significant difference in that this special handling of the owner
> permissions only
> > applies to an open file in v4.  Is there a v4 server that does this
> v3-like thing even
> > for files that are not open?
> The FreeBSD server does. It does the "owner-override" for Read/Write using
> special stateids (which is what I assume you mean by "not open"?).
>

Yes.   This is not mentioned in -05 so is considered OK.


> It only uses the stateid to check for a conflicting Open_Share_Deny. (For
> special
> stateids, any Open_Share_Deny for the type of I/O would be considered
> conflicting.
>
> > > (FreeBSD does it for Read as well as Write, although the
> > > above only refers to Write.)
> >
> > I don't have a problem with that as long as:
> >  - it is limited to open files
> I can see an argument for not doing "owner-override" for special stateids.


Me too, but I don't present that in -05.

The counter argument would be along the lines of "nothing in the RFCs
> says that it cannot be done for special stateids and defining that in this
> draft changes the protocol.
>

I don't agree with that argument but I expect the working groups does and i
am drafting -05 on that basis.

It looks like we are stuck with this.

>
> To be honest, I am not aware of any extant clients that do Read/Write with
> special stateids at this time.
>

I'm at a loss to understand what they were included in the first place. I
have to check RFC8881 to see if server support is REQUIRED for this.

>
> > - It does not apply to the execute bit
> Not sure why execute would be handled differently that Read?
>

I was just confused about that.   Since this stuff does not apply to
ACCESS, it doesn't matter.

>
> > > For NFSv4 over encryption with client peer authentication, I think you
> > > can argue the following:
> > >
> > Although I don't want to get into arguing in a standards-track document,
> > I think you have the essence of the matter right.
> >
> > Since v4 is  stateful protocol, and now has reasonable security, we can
> reasonably
> > allow the server to rely on permission checking on open, if it chooses.
> Doing this
> > only for the owner would also be covered.
> >
> > > - Since the client can be trusted.
> > > and
> > > - Encryption subverts "man in the middle attacks" and the ability to
> > >   "sniff to acquire valid stateids".
> > > that an appropriate Open/Lock/Delegation stateid is sufficient to
> > > permission check the Read/Write and, as such, checking of mode/ACL
> > > is not required.
> > >
> > > --> Appropriate stateid would refer to a current one issued to that
> client
> > >      where either the Open associated with the Open/Lock stateid
> includes
> > >       the needed OPEN_SHARE_ACCESS or the Delegation is of the correct
> > >     type (READ_DELEGATION or WRITE_DELEGATION).
> >
> > I will do something similar in -05.
>

This will be an alternate way of addressing the issue.

Right now, both ways of doing this use MAY.

A statement you SHOULD do one or the other is meaningless without a
discussions of why you might bypass.   MUST is a possibility but for -05, I
will simply says that clients expect this behavior to be provided in some
way.

> >
> > > The above *might* be preferred to "owner-override" for Read/Write
> > > operations?
>

I try to explain plusses and minuses in -04 with giving a preference.


> > >
> > > rick
> > > ps: I am not sure if any NFSv4 server uses the stateid in Read/Write in
> > >       the way described above.  At this time, FreeBSD only uses these
> > >       stateids to check for conflicting Open/shares (byte range locks
> are
> > >      always advisory).
> This was simply meant to say "I do not know if any extant server does what
> I argued could be reasonable, above.
>
> > >
> > > If that's the case, then, for v4, the it and uw bits would be ignored
> and your test
> > > program would behave the same if you closed it and re-opened it before
> the
> > > write.
> Not sure what you mean? The permission checking would not change for Opens.
> If done locally on the client, due to a delegation being issued, an Access
> operation
> would be used.
>

Right.


>
> > Of that's the case, let me know so that I can address that issue for -05.
> rick
>
>
>
>
> If "owner-override" is turned off on the server, it fails for both the
> FreeBSD
> and Linux-5.15.1 client NFSv4 mounts. (The write(2) fails for FreeBSD and
> the
> close(2) fails for Linux, but that's ok. Unless there is an fsync(2),
> flushing writes
> to the server can be delayed until close(2). Both had empty files after the
> failure.)
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <fcntl.h>
> #include <errno.h>
> #include <sys/param.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <err.h>
> #include <unistd.h>
>
> char buf[1024 * 1024];
>
> int
> main(int argc, char *argv[])
> {
>         int fd, i;
>
>         fd = open(argv[1], O_CREAT | O_RDWR, 0666);
>         if (fd < 0)
>                 err(1, "cannot open %s", argv[1]);
>         if (fchmod(fd, 0) < 0)
>                 err(1, "cannot chmod %s", argv[1]);
>         for (i = 0; i < 10; i++)
>                 if (write(fd, buf, sizeof(buf)) != sizeof(buf))
>                         err(1, "cannot write");
>         if (lseek(fd, SEEK_SET, 0) < 0)
>                 err(1, "cannot seek");
>         for (i = 0; i < 10; i++)
>                 if (read(fd, buf, sizeof(buf)) != sizeof(buf))
>                         err(1, "cannot read");
>         if (close(fd) < 0)
>                 err(1, "cannot close");
> }
>
> I do not have access to a Solaris or Mac OSX client to test, rick
>
> ________________________________________
> From: nfsv4 <[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>> on behalf of
> David Noveck <[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> Sent: Friday, December 24, 2021 8:49 AM
> To: NFSv4; nfsv4-chairs; [e-mail]<mailto:[e-mail]
> ><mailto:[e-mail]<mailto:[e-mail]>>
> Subject: [nfsv4] Fwd: New Version Notification for
> draft-dnoveck-nfsv4-security-04.txt
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> [e-mail]<mailto:[e-mail]><mailto:[e-mail]
> <mailto:[e-mail]>>
>
>
> I've just posted security-04.   Thanks to Rick Macklem and Chuck Lever who
> made important suggestions that I hope are correctly addressed in this
> version.  An rfcdiff with -03 is not small but it is helpful to see what
> has changed.
>
> As previously discussed, I am proposing that the working group adopt this
> draft as a working group document.   I expect Brian and Zahed to set the
> timeline for that discussion.
>
> Please let me know about your suggestions for -05.
>
> ---------- Forwarded message ---------
> From: <[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>><mailto:
> [e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>>
> Date: Fri, Dec 24, 2021 at 8:31 AM
> Subject: New Version Notification for draft-dnoveck-nfsv4-security-04.txt
> To: David Noveck <[e-mail]<mailto:[e-mail]
> ><mailto:[e-mail]<mailto:[e-mail]>><mailto:
> [e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>>
>
>
>
> A new version of I-D, draft-dnoveck-nfsv4-security-04.txt
> has been successfully submitted by David Noveck and posted to the
> IETF repository.
>
> Name:           draft-dnoveck-nfsv4-security
> Revision:       04
> Title:          Security for the NFSv4 Protocols
> Document date:  2021-12-24
> Group:          Individual Submission
> Pages:          129
> URL:
> https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
> Html:
> https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-security-04
>
> 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]<mailto:[e-mail]><mailto:[e-mail]<mailto:
> [e-mail]>>
> https://www.ietf.org/mailman/listinfo/nfsv4
>