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

[Rick Macklem <[e-mail]>]

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.
> >
> > 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?
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"?).
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.
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.

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

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

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

> 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