Use SFS to help secure your remote filesystems.
If you are using Unix systems and sharing files on your network, you are most likely using NFS. However, there are a lot of security problems, not only with individual implementations, but also with the design of the protocol itself. For instance, if a user can spoof an IP address and mount an NFS share that is only meant for a certain computer, she essentially has root access to all the files on that share. In addition, NFS employs secret file handles that are used with each file request. Since NFS does not encrypt its traffic, this makes it very easy for attackers to guess these file handles. If they guess correctly, they essentially get total root access to the remote filesystem.
SFS (http://www.fs.net), the Self-certifying File System, fixes all of these problems by employing a drastically different design philosophy. NFS was created with the notion that you can (and should) trust your network. SFS has been designed from the beginning with the idea that no network should ever be trusted until it can definitively prove its identity. To accomplish this, SFS makes use of public keys on both the client and server ends. It uses these keys to verify the identity of servers and clients, and also provides access control on the server side. One particularly nice side effect of such strong encryption is that SFS provides a much finer grained level of access control than NFS. With NFS, you are limited to specifying which hosts can or cannot connect to a given exported filesystem. In order to access an SFS server, a user must create a key pair and then authorizes the key by logging into the SFS server and registering the key manually.
Building SFS can take up quite a lot of disk space. Before you attempt to build SFS, make sure you have at least 550MB of disk space available on the filesystem on which you’ll be compiling SFS. You will also need to make sure that you have GMP (http://www.swox.com/gmp/), the GNU multiple precision math library, installed. Before you begin to build SFS, you will also need to create a user and group for SFS’s daemons. By default, these are both called sfs. If you want to use a different user or group, you can do this by passing options to the configure script.
Once your system is ready, you can build SFS by simply typing this command:
$ ./configure && make
Once that process is finished, become root and type make install.
If you want to use a user and group other than sfs, you can specify these with the –with-sfsuser and –with-sfsgroup options:
$ ./configure –with-sfsuser=nobody –with-sfsgroup=nobody
Building SFS can take quite a bit of time, so you may want to take the opportunity to enjoy a cup of coffee, a snack, or maybe even a full meal, depending on the speed of your machine and the amount of memory it has.
After SFS has finished building and you have installed it, you can test it out by connecting to the SFS project’s public server. You can do this by starting the SFS client daemon, sfscd, and then changing to the directory that the SFS server will be mounted under:
# sfscd
# cd /sfs/@sfs.fs.net,uzwadtctbjb3dg596waiyru8cx5kb4an
# ls
CONGRATULATIONS cvs pi0 reddy sfswww
# cat CONGRATULATIONS
You have set up a working SFS client.
#
sfscd automatically creates the /sfs directory and the directory for the SFS server. Note that SFS relies on the operating system’s portmap daemon and NFS mounter; you’ll need to have those running before running the client.
To set up an SFS server, first log into your server and generate a public and private key pair:
# mkdir /etc/sfs
# sfskey gen -P /etc/sfs/sfs_host_key
sfskey will then ask you to bang on the keys for a little while in order to gather entropy for the random number generator.
Now you will need to create a configuration file for sfssd, the SFS server daemon. To do this, create a file in /etc/sfs called sfsrwsd_config, which is where you configure the filesystem namespace that SFS will export to other hosts.
If you wanted to export the /home filesystem, you would create a configuration file like this:
Export /var/sfs/root /
Export /home /home
Then you would need to create the /var/sfs/root and /var/sfs/home directories. After that, you would create NFS exports so that the /home filesystem could be mounted under /var/sfs/root/home. These are then reexported by sfssd. The NFS exports need only to allow mounting from localhost.
Here’s what /etc/exports looks like for exporting /home:
/var/sfs/root localhost(rw)
/home localhost(rw)
This exports file is for Linux. If you are running the SFS server on another operating system (such as Solaris or OpenBSD), consult your operating system’s mountd manpage for the proper way to add these shares.
Now start your operating system’s NFS server. Once NFS has started, you can then start sfssd. After attempting to connect to the sfssd server, you should see some messages in your logs like these:
Dec 12 12:29:14 colossus : sfssd: version 0.7.2, pid 3503
Dec 12 12:29:14 colossus : rexd: version 0.7.2, pid 3505
Dec 12 12:29:14 colossus : sfsauthd: version 0.7.2, pid 3506
Dec 12 12:29:14 colossus : rexd: serving @colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:14 colossus : rexd: spawning /usr/local/lib/sfs-0.7.2/ptyd
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from
localhost.localdomain:715 for /var/sfs/root (/var/sfs/root)
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from
localhost.localdomain:715 for /home (/home)
Dec 12 12:29:15 colossus : sfsauthd: serving
@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:16 colossus : sfsrwsd: version 0.7.2, pid 3507
Dec 12 12:29:16 colossus : sfsrwsd: serving
/sfs/@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
The last log entry shows the path that users can use to mount your filesystem. Before mounting any filesystems on your server, users will have to create a key pair and register it with your server. They can do this by logging into your server and running the sfskey command:
$ sfskey register
sfskey: /home/andrew/.sfs/random_seed: No such file or directory
sfskey: creating directory /home/andrew/.sfs
sfskey: creating directory /home/andrew/.sfs/authkeys
/var/sfs/sockets/agent.sock: No such file or directory
sfskey: sfscd not running, limiting sources of entropy
Creating new key: andrew@colossus.nnc#1 (Rabin)
Key Label: andrew@colossus.nnc#1
Enter passphrase:
Again:
sfskey needs secret bits with which to seed the random number generator.
Please type some random or unguessable text until you hear a beep:
DONE
UNIX password:
colossus.nnc: New SRP key: andrew@colossus.nnc/1024
wrote key: /home/andrew/.sfs/authkeys/andrew@colossus.nnc#1
Alternatively, if you already have an existing key pair on another server, you can type sfskey user@otherserver instead. This will retrieve the key from the remote machine and register it with the server you are currently logged into.
Now that you have registered a key with the server, you can log into the SFS server from another machine. This is also done with the sfskey program:
$ sfskey login andrew@colossus.nnc
Passphrase for andrew@colossus.nnc/1024:
SFS Login as andrew@colossus.nnc
Now try to access the remote server:
$ cd /sfs/@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
$ ls
home
As you can see, SFS is a very powerful tool for sharing files across a network, and even across the Internet. Not only does it provide security, but it also provides a unique and universal method for referencing a remote host and its exported filesystems. You can even put your home directory on an SFS server, simply by linking the universal pathname of the exported filesystem /home.