On the Issues Behind Securing NFS?

mhoskins asks: "We all know about the problems with NFS security: export/home to a bunch of workstations and anyone with a laptop can switch off a workstation (after looking up its IP), assume the IP with the laptop, mount /home, create user accounts and then su to them." Are there ways to secure NFS systems from this kind of 'exploit'?

"As stated in the NFS-HOWTO:

'That's good, and you should probably use root_squash on all the file sys good, and you should probably use root_squash on all the file systems you export. "But the root user on the client can still use 'su' to become any other user and access and change that users files!" say you. To which the answer is: Yes, and that's the way it is, and has to be with Unix and NFS.'

Under Solaris, Sun had had what they call SecureRPC witch makes use of NIS+ and credentials. Both the User AND the host/workstation have to be authenticated in order for a /home directory to be accessed. This requires the cooperation of the RPC portmapper, NFS daemons and yp/nis/nis+ nameservices for distribution of credentials.

As far as i can tell Linux based OS's have very little support for NIS+ and secureRPC, and only as a client.

Implementing a NIS+ domain is quite complex, and there are many points of possible failure. There's gotta be a way for us to figure out a simpler way to secure NFS.

At the highest level, we should probably verify RPC calls to NFS come from a known MAC address. (But even that is spoofable)
How about some kind of token stored on the workstation that can authenticate the host.

How about only exporting individual /home subdirs to certain hosts as needed. What are the implications of having huge kernel export tables? etc..."