Rant: The State of Network File Systems
The State of Network File Systems
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:
Common Internet File System (CIFS)
I actually think this is at the moment of writing the best option. There are two options here:
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.
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.
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...)