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

[David Noveck <[e-mail]>]

On Sun, Dec 26, 2021, 11:45 AM Rick Macklem <[e-mail]> wrote:

> David Noveck wrote:
> > On Fri, Dec 24, 2021, 8:49 PM Rick Macklem <[e-mail]<mailto:
> [e-mail]>> 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.
>
> See the 3rd sentence from the end.
>
> As far as I know, servers implement the same thing for Read/Write
> for NFSv4.


>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?

(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
 - It does not apply to the execute bit


> 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.

>
> The above *might* be preferred to "owner-override" for Read/Write
> operations?
>
> 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).
>

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.

Of that's the case, let me know so that I can address that issue for -05.


>
>
> 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]>> on
> behalf of David Noveck <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, December 24, 2021 8:49 AM
> To: NFSv4; nfsv4-chairs; [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]>
>
>
> 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]>>>
> 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]>>>
>
>
>
> 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]>
> https://www.ietf.org/mailman/listinfo/nfsv4
>