Re: [nfsv4] Agenda items for virtual interim

[Chuck Lever III <[e-mail]>]

> On Oct 16, 2021, at 6:33 PM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever III wrote:
>>> On Oct 16, 2021, at 9:28 AM, David Noveck <[e-mail]> wrote:
>>> 
>>> I'd be interested in hearing from Chuck about his thoughts about addressing use of RPC-with-TLS for NFSv3 and >>how that might or might not interact with the v4 security work now going on.
>> 
>> I haven't had a chance to read nfsv4-security yet. That is at
>> the top of my to-do list.
>> 
>> After that, I think I'd like to huddle with Rick to discuss
>> how NFSv3 should work. Once we have something, we can present
>> options or discuss it on the mailing list.
> Well, for the implementation I did for FreeBSD, it just worked. All the changes were in the kernel
> RPC layer used by all versions of NFS,
> --> I suppose there is the question of crossing server mount point boundaries, where the
>      requirement for RPC-with-TLS changes, but at least for FreeBSD, NFSv3 exports individual
>      file systems, so there is no issue.

I was thinking that the MNT procedure would have to provide
the same list of pseudoflavors that SECINFO deals with, and
the server's kernel would need to enforce the administrator's
policy of which ones are permitted.

I'll have to study the MOUNT protocol Appendix to see if adding
unexpected flavors to the result of MNT will be a problem for
existing implementations.


> Having said that, I have done nothing w.r.t. the ancillary protocols (Mount, NLM, NSM). To do
> Mount and NSM on FreeBSD, the userland RPC library functions would need to be modified to
> support RPC-with-TLS. This wouldn't be hard to do, but  might be hard to deploy, since it means
> that all RPC programs would need to link to the OpenSSL libraries, and that might not be
> acceptable to the FreeBSD collective.

FedFS on Linux used to require LDAP and still requires libxml2.
For FedFS support, the Linux mountd does a dynamic module
load. If that library happens not to be available then FedFS
junctions are not available on that server. The same approach
could be taken to handle RPC-with-TLS support in Linux's
libtirpc, but I don't have a plan to do that yet.

Linux handles NLM and NFSACL in the kernel, so these could
reasonably be modified to use the kernel's RPC-with-TLS
support. NFSACL will probably get TLS anyway because it is
conveyed on the same transport as NFS.


> Not sure if support should be required for the ancillary protocols and not sure who would decide?

Implementers decide, of course. The Linux NFS community has
so far decided not to protect these sideband protocols with
RPCSEC GSS, for instance. (IIRC Solaris is the same).


> (Does Oracle claim NFSv3 as theirs or is it just an orphan now?;-)

NFSv3 is not an orphan. Sun Microsystems contributed NFSv3 to
the IETF back in the 1990s, so Oracle does not have any
unilateral say regarding what happens to it today.

I don't believe the nfsv4 WG is willing to publish any updates
to RFC 1813, however, so NFSv3 is effectively moribund (tm).


>> In short, I agree this is something that needs to be discussed
>> at some point, but I'm not confident I'll be ready by Oct 27.
>> I'd prefer to see some discussion on list about this before
>> we bring it to a WG meeting.
> I'll be interested in hearing what others think? Chuck, if you want to email off-list, that's fine with me,
> but I'll admit the above is all I can think of right now.

Well then we might be pretty close to having a cohesive plan
for NFSv3 in-transit encryption. Only WG decision being where
to document the conventions and changes, if any are needed.


--
Chuck Lever