The State of Network File Systems

Rationale

What I want is simple. I want a secure network-based file system. Is that asking too much? It would seem so. This rant attempts to explain the utterly horrible state opensource network-based file systems are in.

Network File System (NFS)

Probably the most common network-based file system, NFS is one of the most insecure inventions ever made. Ignoring the fact that NFS relies on the security of file descriptors to maintain security, one has to look further than that. It is well known (in my circles at least) that running NFS without root_squash is a bad idea. The reason for this is simple, any user that can obtain root on any client has root access to the filesystem. The real question though is this - does root_squash really solve the problem? Well, this depends (actually, it doesn't, but in a few rare cases it does help). Say I have a bunch of files owned by uid 1000, now I am root (uid=0) on the local system right, now I should be prevented from reading files that is owned by uid (permitting the read flag for others is not set - chmod o-rwx filename)? Wrong - what happens if I do su 1000 - -c "cat /path/to/file"? I get the content of the file, that's what happens!

In a similar fashion I can clobber or simply change other users's files by su'ing to that user (remember that you have root locally).

Now the case where it does help is the case where you would require root access to read/write the file. As soon as any other uid has read/write access to the root_squash option helps didly squat.

NFS is a very good option, as long as you can trust your client workstations. Oh, yes, you also need to be able to trust your routers to not forward packets that cannot come along that route. For example, say I'm using 10.0.0.0/16 as my IP range but dividing into 10.0.x.0/24 blocks then any packet coming out of 10.0.1.0/24 should in fact have a source IP in that range. This is not the case with most vlan/routing implementations.

Secure File System (SFS)

Supposedly a replacement for NFS. I beg to differ. I've only been looking at it for a day and I can already see why SFS will never replace NFS.

The main problem is in the bootstrapping process, once I can get over that, I'm through. However, in a lab situation I cannot require every user to walk around with a flash disc of some sort in order to gain access to his/her home directory. It's simply not practical.

Perhaps my situation would explain this well. 1500 users (ok, I've got a few dead accounts which I'll hopefully sort out in the next two to three weeks). One server, 400 odd workstations distributed over about 5 subnets using 100Mbps ethernet (Server is going onto 1Gbps in the next week). Some of these subnets are shared with other machines (not lab-related).

Right, to get those cryptographic key pairs out there I have a few choices:

Require every user to walk around with a flash-disc/cd, attempt to mount /mnt/usb, /mnt/cdrom and possibly /mnt/floppy upon every login and check whether I can load the required key using the password as supplied by pam. Obvious problems here: Forgotten media, password synchronisation, corrupt floppies.
Export the encrypted private keys over NFS. Hmm, nice, back to replacing private keys and other NFS-based exploits. Effectively make everyones private keys available to the whole world, albeit password encrypted (you try and convince students to use secure passwords).
Store all keys on the local fs. Right, then I'll rather use NFS - at least then I can possibly keep track and find someone that steals all the keys.
Any other options ... ? Please mail me if you are aware of any.

Common Internet File System (CIFS)

I actually think this is at the moment of writing the best option. There are two options here:

I can keep a seperate SAM for samba passwords (ok, I could use this same SAM along with pam_smbd for authentication). I can even make samba update the ldap password and vice versa (or rather, I can make samba update the ldap password which updates the samba password if I understand the howto's/options correctly).
I can use pam support in samba to auth against ldap. This however requires plaintext passwords on the wire. Also not an option as I could then just as well use NFS. Ok, perhaps not quite.

The first of these options is in fact the one I'm liking more and more by the day. I cannot, however, for the life of me to get samba to do ldap the way I want it to (Topic for another rant). I suppose I'll be doing a large amount of rtfs'ing over the next week or so.

The major drawback with samba apparantly is CPU overhead. It's not nearly as efficient as NFS or SFS.

Other possibilities?

There are other network filesystem possibilities such as ASF, NFSv4 (kerberised NFS). I have not yet investigated these options, and as such this rant cannot be considered final.

Conclusion

None so far. I'm still investigating but it's not looking good. The only semi-viable option so far is to go with samba and SAM password databases (So much for sharing user information via ldap...)