You're right. The krb5 is not covering the side band protocols pre- v4.x. I forgot about that bit, thanks for the reminder.
In some "top secret" environments, I could see that sniffing in the Network and seeing things like Computer Object name, uid/gid, mount path and FH could by someone be seen as a security risk. *Eve* if the actual datagrams with user data could never be seen. For most use cases, I contend that this is just an ISO 27001 tick box item, though.
A thought: OTOH if anyone, anyone at all, is root on an NFS client then can they not somehow from inside it see that MOUNT information anyway? (Even if the info is encrypted in transit with krb5 then.) I'm not sure how that bit works, never looked into it
Justin Parisi wrote:
you can configure v4.x to force domain string ID auth only [...] ,but also offers some security benefits when you tack on Kerberos UPN.
I did try a setup with this at some point in the past and then got really tired of the whole thing and tore it down. It's just... cumbersome. I can't think of any non esoteric Linux (Unix) based environment with lots of NFS traffic which would be reasonably manageable with such a config
/M
-------- Original Message -------- Subject: Re: Any Openstack/Netapp FAS deployments w cinder NFS, v3 or v4 Date: Mon, 5 Oct 2020 13:29:19 +0000 From: Parisi, Justin Justin.Parisi@netapp.com To: NGC-michael.bergman-ericsson.com michael.bergman@ericsson.com, Toasters toasters@teaparty.net
Re: v3 vs. v4.x security...
With NFSv3, the sideband protocols are not Kerberized when with krb5*. So all that gets kerberized is the NFS protocol; mount, portmap, nlm, etc are all plaintext. That's one aspect of security that v4.x provides with everything encapsulated. Those sideband protocols can contain some information about the mount that you don't want to be readable.
For example, MOUNT shows:
- machine account name - uid/gid mounting - auxiliary groups - mount path - filehandle info
NFSv4.x stores all that info with PUTROOTFH calls in the NFS packets, so that all gets GSS wrapped.
Plus, you can configure v4.x to force domain string ID auth only, whereas v3 is numeric ID only. That offers some flexibility (such as being able to have different UIDs on storage and client, provided they can both resolve name@domain.com to a user), but also offers some security benefits when you tack on Kerberos UPN.
V4.x does offer some security benefits that v3 does not, but you're right that you can accomplish most of the v4 security stuff in v3.