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..."

Kerberized NFS is here (Sun today, Linux soon)

[fooblah]

Sun's current SecureNFS system, no longer based strictly on NIS+, is available for Solaris 2.6, 7 and 8. It's called SEAM and it works by adding a new RPC auth flavor called RPCSEC_GSS based on an earlier flavor by MIT called AUTH_GSSAPI.

This means you can use GSS-API to authenticate/secure NFS, which means you can use Kerberos V (Sun also includes GSS-API plug-in mechanisms for doing Diffie-Hellman, ala NIS+).

Sun has opened source for this under the OS-friendly SISSL (not SCSL).

Meantime, the University of Michigan is doing an NFSv4 implementation for Linux and they already have completed their own implementation of RPC with RPCSEC_GSS (which they have released).

Surely the Michigan code will be adapted to the existing NFSv3 code in Linux.

The RPCSEC_GSS flavor can be used with NFSv2, NFSv3 and NFSv4 (the latter is not yet a standard).

Good luck!

Security in the workplace

[Borogove]

This is a significant issue. It's quite common for people running Linux at work to need root access to their own machines (because the sort of people running Linux at work tend to want to do the sort of things you can only do as root). But as the HOWTO points out, it's a short hop from being root on your machine to masquerading as anyone else.

Are there no (released) tools for solving this problem? Projects like Coda seem to be aiming for sensible solutions based on decent authentication mechanisms - but Coda is solving several other problems and (last time I checked) was still under development. Are there any file-servers which don't attempt to be as ambitious, but do provide the necessary secure authentication?
-- Andrem

SSH?

[jbert]

Off the top of my head, can't NFS be tranported over TCP instead of the more usual UDP?

In this case, you should be able to set things up on the server so that NFS only responds to data received over the ssh tunnel (hmm...how do you do this - ipchains on Linux?) and then you're away.

Clients first need to establish an ssh connection (providing the authentication you want) before they can do NFS. As a bonus, you can have ssh encrypt the NFS traffic (but you might not want to).

Have I had too little coffee today or would this be one way to go?

(Might require some tight configuration with current tools, but that could all be automated in principle).

Re:finger in the dyke

[Muggins the Mad]

I too spent a while scratching my head at ways to secure NFS, but with little success.

There does appear to be support in the (rpc) protocol for authentication other than the primitive "trust the client" stuff it defaults to on Linux, but none of it seems to be supported by Linux NFS.

I think some of the commercial UNIXen have kerberos authentication attached to NFS, which seems a good way to do it. But this doesn't seem to be something simple to implement.

> Have you checked out CODA? Quite possibly it may have resolved some of these issues.

I've checked many other file systems: Coda seems quite secure and has many features, but also has many limitations that make it unsuitable for a lot of environments.

Same goes for Samba (doesn't do UNIX permissions, symlinks, etc).

IBM have announced that they're open sourcing AFS and making it free (OpenAFS) www.transarc.com [transarc.com], but mention that they've removed some secret stuff. It seems to be my last hope for network
security though...

- Muggins the Mad

glibc 2.1 has secureRPC, Kerberos RPC in future

[coyote-san]

After the US finally started relaxing the crypto export rules glibc 2.1 included support for secure RPC. While this code is pretty standard and shouldn't cause any problems, the Linux keyserver is probably beta, at best, and none of the RPC-based applications have really been tested with secure RPC.

In other words, this is an area where YOU can make a valuable contribution to the community! :-)

The other secure option is GSSAPI RPC (aka Kerberos). It's not available in Linux yet, but it is a RFC and it also provides strong authentication and encryption(?) of NFS volumes.

finger in the dyke

[linux_penguin]

I dont think it would really be feasible to try to secure NFS in this way. It is really designed to be used on trusted LANs, and not much more. Closing the gate after the horse has bolted is never a good idea, it is usually more efficient to start again with a more secure design.

Have you checked out CODA? Quite possibly it may have resolved some of these issues.


Simon

Secure network file system

[Aaron Denney]

Take a look at SFS [fs.net]. It really does look like a secure way to do file sharing. Individual user are authenticated, the host itself is authenticated, and the traffic is encrypted. You do need NFSv3 support, as it is layered on top of it, but it is just about as fast as NFSv3, even with the security. Take a look.

For the latest Linux NFS patches, (to support V3), you'll want to go to nfs.sourceforge.net [sourceforge.net]