5 ms·

NFSv4 uses only a single port, which allows an option of skipping any complicated Kerberos setup and getting encryption by just tunneling the connection through

NFSv4 uses only a single port, which allows an option of skipping any complicated Kerberos setup and getting encryption by just tunneling the connection through stunnel: https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls https://www.linuxjournal.com/content/encrypting-nfsv4-stunne... A version of that scheme is in the process of being standardized as part of the official NFSv4 protocol: https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-t... (see "Acknowledgments" at the end for a mention of the connection).

denkmoon 5y ago
And the permissions problem? My experience with NFS is that permissions fall over the moment you've got root on a box that is allowed to connect. You're essentially relying on network level access control to prevent naughtyness. If I can create a user that has the same UID as someone's files I want on a remote NFS, I can just go do that? Maybe I've always misconfigured NFS, but as far as I know outside of kerberos there is no way to have independent authorisation of users.
- yrro 5y ago
  Yeah, you need kerberos. OTOH it's not as difficult as people seem to think. Maybe if you insist on DIY rather than getting started with FreeIPA or even whisper it Active Directory...
- chasil 5y ago
  I wrote the article on stunnel encryption. NFSv3 was strictly numeric uid/gid, but this is not the case with NFSv4. It is still best to keep uid/gid values synchronized, but there are idmapd processes that negotiate permissions between client and server. Examine the output of "man idmapd.conf" for details. It even does LDAP.
  - dheera 5y ago
    > It is still best to keep uid/gid values synchronized That's impractical in a large organization. They really should have used a username@domain or UUID.
yrro 5y ago
Hmm, does that enable strong authentication of the users making RPC requests? Or does the server still have to trust that the client making RPC requests is being honest? Specifically I wonder if the client is compromised, is it able to start making RPC requests for any arbitrary user (as with AUTH_SYS), or only for any user who uses their own credentials to establish a security context (as with RPCSEC_GSS)? Forgive my imprecise terminology here, I'm clearly not an NFS/RPC expert! :) [edit] Ah, I see this is addressed in Sec. 7 - never mind. It looks like you still need to use GSS on top of this scheme in order to prevent a compromised client from impersonating any user.

denkmoon 5y ago

And the permissions problem? My experience with NFS is that permissions fall over the moment you've got root on a box that is allowed to connect. You're essentially relying on network level access control to prevent naughtyness. If I can create a user that has the same UID as someone's files I want on a remote NFS, I can just go do that? Maybe I've always misconfigured NFS, but as far as I know outside of kerberos there is no way to have independent authorisation of users.

yrro 5y ago
Yeah, you need kerberos. OTOH it's not as difficult as people seem to think. Maybe if you insist on DIY rather than getting started with FreeIPA or even whisper it Active Directory...
chasil 5y ago
I wrote the article on stunnel encryption. NFSv3 was strictly numeric uid/gid, but this is not the case with NFSv4. It is still best to keep uid/gid values synchronized, but there are idmapd processes that negotiate permissions between client and server. Examine the output of "man idmapd.conf" for details. It even does LDAP.
- dheera 5y ago
  > It is still best to keep uid/gid values synchronized That's impractical in a large organization. They really should have used a username@domain or UUID.

yrro 5y ago

Hmm, does that enable strong authentication of the users making RPC requests? Or does the server still have to trust that the client making RPC requests is being honest? Specifically I wonder if the client is compromised, is it able to start making RPC requests for any arbitrary user (as with AUTH_SYS), or only for any user who uses their own credentials to establish a security context (as with RPCSEC_GSS)? Forgive my imprecise terminology here, I'm clearly not an NFS/RPC expert! :) [edit] Ah, I see this is addressed in Sec. 7 - never mind. It looks like you still need to use GSS on top of this scheme in order to prevent a compromised client from impersonating any user.