Re: SMB vs. NFS security

[awilliam@xxxxxxxxxxxxx]

> A judgement call question.  Does anyone have an opinion on which
> is the more secure way to serve files, samba or NFS?

This is a rather more complex issue than it first appears.  NFS is 
quite secure, but CAN be compromised by an insecure client.  If you 
can acquire root privilages on the client, you can su to any known 
user on that system and acquire the privilages of that user on both 
the local and NFS filesystems, thus becoming in NFS speak, a 
"imposter".  NFS does not verify the UID in any way for open, read, or 
write access.  NFS is reasonably secure if all your clients are 
secure,  that is you remove root login and setuid tools (assuming 
these are UNIX clients).  NFS with M$ clients is a VERY BAD idea.

SMB on the other hand does contain a "key" in each client<->server 
request and thus is less prone to "imposters".  However the SMB 
protocol is huge, having over 127 defines operations, and can be 
hi-jacked in a variety of other ways. This is one of the problems that 
plagues NT, and should go away in W2K (with no NT4.0 or lower grade 
clients).  Since M$ clients provide little or now restrictions for 
getting packets on a network,  a reasonably clever person who can boot 
or even just run a program from a floppy,  could very likely crack 
open a fileserver.

Secure NFS on the other hand integrates a key into every operation, as 
does SMB, and the keys can be quite large, and thus secure.  But 
secure NFS requires the generation of a key, which can be a hassle for 
new users.  But key generation can be integrated into XDM or whatnot 
by a decent C programmer with little fuss.  You have to run a key 
server as well.  I don't know what M$ NFS clients support this.  And 
Linux, at first glance at least, doesn't seem to support secure nfs.

Another problem, is that you need a distributed UID and GID system to 
share files easily.  SMB provides it's own, and NFS systems typically 
rely on NIS. I think NIS is horribly insecure and subject to a variety 
of brute force attacks as the crypt of the password is exposed to the 
client.  Using something like a properly configured LDAP server can 
accomplish the same thing in a much more secure and robust manner, as 
the server can be instructed never to reveal a crypt to a client, but 
simply accept a crypt for comparison,  thus making brute force attacks 
MUCH more difficult, and they would certainly generate alerts in the 
LDAP servers log file if someone attempted to match a password 5000 
times.  With an exposed crypt they can try to crack it on the client 
or even e-mail it home.

The "REAL" solution to network security in all aspects is Kerberos,  
the two headed dog from Greek mythology that guards the fjiord to the 
gate of hades. And if your not intimidated yet, you will be.

http://www.isi.edu/gost/brian/security/kerberos.html

You need kerbo-ized clients, and a kerberos key server, all of which 
are publicly available (so long as you live in the US).  It basically 
adds authentication and encryption to ALL network transactions using 
large private keys.  I think kerbo-ized NFS is floating around 
somewhere, and CODA supports Kerberos (if CMU every finishes it,  CMU 
seems to have decided to drop off the edge of the techno-world in a 
lot of projects).

Overall the picture of file server security is pretty bleak, unless 
you really go whole hog.  It all depends on how you define "secure", 
how clever and malicious your users are, and the market value of your 
information.

Another thing you might want to look at is TCFS, which seems 
promising, but I don't know much about: http://tcfs.dia.unisa.it/  
which adds a security layer over NFS by mounting through loopback.