> On Jul 3, 2024, at 6:24 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > I've been pondering security questions with localio - particularly > wondering what questions I need to ask. I've found three focal points > which overlap but help me organise my thoughts: > 1- the LOCALIO RPC protocol > 2- the 'auth_domain' that nfsd uses to authorise access > 3- the credential that is used to access the file > > 1/ It occurs to me that I could find out the UUID reported by a given > local server (just ask it over the RPC connection), find out the > filehandle for some file that I don't have write access to (not too > hard), and create a private NFS server (hacking nfs-ganasha?) which > reports the same uuid and reports that I have access to a file with > that filehandle. If I then mount from that server inside a private > container on the same host that is running the local server, I would get > localio access to the target file. > > I might not be able to write to it because of credential checking, but I > think that is getting a lot closer to unauthorised access than I would > like. > > I would much prefer it if there was no credible way to subvert the > LOCALIO protocol. > > My current idea goes like this: > - NFS client tells nfs_common it is going to probe for localio > and gets back a nonce. nfs_common records that this probe is happening > - NFS client sends the nonce to the server over LOCALIO. > - server tells nfs_common "I just got this nonce - does it mean > anything?". If it does, the server gets connected with the client > through nfs_common. The server reports success over LOCALIO. > If it doesn't the server reports failure of LOCALIO. > - NFS client gets the reply and tells nfs_common that it has a reply > so the nonce is invalidated. If the reply was success and nfs_local > confirms there is a connection, then the two stay connected. > > I think that having a nonce (single-use uuid) is better than using the > same uuid for the life of the server, and I think that sending it > proactively by client rather than reactively by the server is also > safer. This echoes typical security approaches, and I think it would be very easy to convert the current LOCALIO protocol to operate this way. > 2/ The localio access should use exactly the same auth_domain as the > network access uses. This ensure the credentials implied by > rootsquash and allsquash are used correctly. I think the current > code has the client guessing what IP address the server will see and > finding an auth_domain based on that. I'm not comfortable with that. > > In the new LOCALIO protocol I suggest above, the server registers > with nfs_common at the moment it receives an RPC request. At that > moment it knows the characteristics of the connection - remote IP? > krb5? tls? - and can determine an auth_domain and give it to > nfs_common and so make it available to the client. I wasn't sure about the "copy the IP address" logic. It doesn't seem like it would provide adequate security across network namespaces on the same physical host, but I haven't studied it closely. My sense is an administrator would want authorization for localIO to behave just like it would if this were a normal NFS access. So the export's IP address settings, secure/insecure, GSS, TLS, and squashing options should all be effective and work exactly the same without regard to the I/O method. auth_domains are an area I still don't know much about, but that seems like it would get us closer to having access authorization behave the same in both cases. It looked like your __fh_verify() clean-up was headed in that direction. > Jeff wondered about an export option to explicitly enable LOCALIO. I > had wondered about that too. But I think that if we firmly tie the > localio auth_domain to the connection as above, that shouldn't be needed. > > 3/ The current code uses the 'struct cred' of the application to look up > the file in the server code. When a request goes over the wire the > credential is translated to uid/gid (or krb identity) and this is > mapped back to a credential on the server which might be in a > different uid name space (might it? Does that even work for nfsd?) > > I think that if rootsquash or allsquash is in effect the correct > server-side credential is used but otherwise the client-side > credential is used. That is likely correct in many cases but I'd > like to be convinced that it is correct in all case. Maybe it is > time to get a deeper understanding of uid name spaces. I've wondered about the idmapping issues, actually. Thanks for bringing that up. I think Christian and linux-fsdevel need to be involved in this conversation; added. -- Chuck Lever
