Guy Harris wrote:
Right, of course if you misconfig something you open yourself to mischief. What I want to get at is whether it is safe to have a filer attached to the net-at-large, or whether it needs to be firewalled or otherwise protected. Can you elaborate on the nfs insecurities you mention?
A number of NFS systems and tools send passwords in plain text, and the filer is not an exception. Use a firewall or switched Ethernet.
That bites
Actually, the only NFS service that involves passwords is PCNFSD.
However, NFS *itself* tends to use what's called "UNIX authentication", which means an NFS request goes over the wire with what purports to be the user ID, group ID, and group set of the user making the request.
The server is not in a position to find out whether the request is *really* coming from that set of IDs. Most NFS servers will trust anything other than a user ID of 0 (by default, they map a user ID of 0 to a user "nobody", but can be configured not to do that).
Thus, if a user on a given NFS client can, say, become "root" on that client machine, and can then become some *other* user using e.g. "su", they can read or write any file readable or writable by that other user.
NetApp filers don't support any of the stricter forms of authentication used by some NFS clients and servers, which may be able to protect against that. (I'm not sure what vulnerabilities have been found in, say, DES or Kerberos authentication, or in the Kerberos flavor of GSSAPI authentication.)
This does not make a lot of sense to me.. I mean, if some user on the client has hacked root, then game over man. Who cares past that. Of course they can su to some user and mess with their files, root can do just about anything.
What I want and need to know when designing our nfs system is whether a normal non-root user, _without hacking root_, can do any shenanigans via or to nfs. Basically, is adding properly configured nfs to an already secure system going to be ok or not ok, and if not ok what can be done about it?