SFS is a network file system that provides strong security over untrusted networks. At the same time, SFS goes to great lengths to prevent security from hurting performance or becoming an administrative burden.
SFS is also a global file system. Users can access any server from any client in the world, and share files with anyone anywhere. There is no need to rely on system administrators or trusted third parties to coordinate the sharing of files across administrative realms. Thus, SFS provides convenient file sharing over the Internet even where security is not a priority.
Self-certifying file system.
You should use SFS to improve the security of your local-area network, to gain remote file system access where you can't currently have it, or to set up a file server where currently servers are under centralized control.
NFS, for example, transmits secret file handles in every file system request. An attacker who learns the file handle of even a single directory can access the entire file system as any user. AFS, another widely-used network file system, does not keep the contents of private files secret from network eavesdroppers. Moreover, AFS uses an insecure message authentication code (MAC) to protect the integrity of communication between clients and servers. An active attacker can, with very little computation, tamper with and change the contents of AFS messages in transit. Coda has approximately the same security properties as AFS.
The key difference between SFS and any previous file system is that SFS always provides security over untrusted networks, but does not perform any key management. SFS accomplishes this by naming file systems by their public keys. Every SFS file server is accessible under a self-certifying pathname--a file name of the form:
/sfs/Location:HostIDLocation is the server's DNS hostname or IP address. HostID is a cryptographic hash of the server's public key. SFS uses a collision-resistant hash function to compute HostID. Thus, HostID effectively specifies a unique public key. (The client can ask a server for its public key, hash the key, and ensure that the key returned by the server matches the HostID in a pathname). Self-certifying pathnames are automatically created, or "automounted", the first time they are referenced.
Self-certifying pathnames allow a variety of server key management mechanisms to coexist on top of SFS. They ensure that people can use the most appropriate mechanism to access any particular file server, which in turn eliminates most of the administrative burden of running a secure file system. Some examples of how SFS might be used and key management would be performed:
/etc/fstab or configuring an NFS automounter.
sfskey will do this automatically
for you and creat a symbolic link to the self-certifying pathname.
While SFS does not perform its own key management, it provides a great
infrastructure on which to build various key management mechanisms.
File servers can certify other file servers with symbolic links.
Users' sfsagent programs exploit the secure file system
to perform name to self-certifying pathname mappings on-the-fly.
Various symbolic links can be chained together in pathnames to combine
different key management mechanisms. In short, SFS can function as
its own key management infrastructure, even though SFS itself is
completely agnostic about how users should actually manage keys.
SFS runs on Unix platforms with NFS version 3 support. We have run
SFS successfully on OpenBSD 2.6, FreeBSD 3.3, OSF/1 4.0, Solaris 5.7,
and Linux (with an SFS-capable Linux kernel).
You need gcc 2.95.1 or higher, at
least 128 Megs of ram, and 550 Megs of disk space to compile SFS.
Finally, you must create a user and group called sfs for
SFS.
Configuring and running SFS is relatively easy. The SFS client can peacefully coexist with other network file system clients. The SFS server serves the operating system's local file systems. Thus, you can install and evaluate SFS without disrupting any existing network file systems, and gradually migrate over to SFS if you decide you like it.
No. The current implementation of SFS serves existing local file systems on your server. Thus, you can evaluate SFS on the file systems you use daily without disrupting anything.
SFS is slightly slower than straight NFS3 over UDP. However, most of the slowdown is caused by SFS's portable user-level implementation, rather than by the fact that it encrypts and MACs [checks the integrity of] network traffic. We think that moving a small portion of SFS's client-side functionality into the kernel could make SFS outperform NFS. Some work has already been done on this (a loadable kernel module called UVFS), but no one is currently working on it.
This table compares the performance of SFS with NFS and the local file system. The benchmark used was a compilation of the FreeBSD 3.3 GENERIC kernel. The client and server were both 550 MHz Pentium III machines, connected by full-duplex 100 Mbit/sec ethernet.
As you can see, SFS performs between NFS over UDP and NFS over TCP. Since SFS itself uses TCP to communicate, this isn't too bad. (The SFS protocol allows slightly more aggressive attribute caching, which is how SFS can beat NFS/TCP.)
File System Seconds
Local 140 NFS3/UDP 178 NFS3/TCP 207 SFS 197 SFS/nocrypt 194
Several SFS developers store their home directories on SFS. We have run SFS internally for many months and never lost a file. SFS gains a great deal of stability from the fact that the SFS server serves the operating system's native local file system, which is presumably stable and well-debugged.
The most likely problem you might have with SFS is if the client or
server crashes for some reason. How serious this is obviously depends
on how reliant you are on SFS. On the server side, killing and
restarting sfssd should be enough to recover from such
problems. On the client side, killing sfscd, waiting for
all file systems to unmount, and restarting sfscd should
fix the problem. (These daemons could actually recover on their own
from subsidiary daemon failures by respawning whatever daemon crashed.
However, SFS should never crash, so if it does we want you to notice
it and tell us about it!)
Another potentially serious problem is deadlock. The SFS client software can deadlock the kernel on some operating systems when the software takes a page fault. SFS tries hard not to get paged out, but on some operating systems this is either impossible, or else doing so tickles other bugs in the operating system's virtual memory code.
A more serious problem might be if SFS opened any security holes on your system. If you are already running NFS, chances are running SFS will not make your security too much worse. However, you should read the Security section of the SFS manual for a detailed discussion of the security implications of running SFS.
The short answer is yes you can--in fact several SFS developers
do--but it's not very convenient. If your home directory is on SFS,
when you first log in you will not have permission to access it. You
must run sfsagent to authenticate you to the file server
before you can access your home directory. At that point, it's
probably easiest to log out and log back in so that your shell reads
all of your dot files.
We are working on a remote login program that will forward connections
to sfsagent (much like ssh does). This program will
greatly simplify having a home directory on SFS. Ideally, some
operating systems' local login programs will some day
spawn an sfsagent for users, the way AFS clients have
hacked login programs that fetch kerberos tickets. Modifying the
login program of your operating system to support SFS is one way you
can help the SFS project...
SFS relies uses SHA-1 or slightly strengthened variants as a "random oracle" in a number of situations. HostIDs are computed as SHA-1 (1, Location, PubKey, 1, Location, PubKey).
SFS generates random bits with the NIST pseudo-random generator
(specified for use in DSS
key generation). This generator is based on SHA-1. It is seeded from
a number of sources, including /dev/random where
available, a random seed file, the output of various system utilities,
and, for key generation, from the value and timing of random
characters typed by the user.
SFS protects the secrecy of messages between clients and servers using ARC4 (alleged RC4) with 20-byte keys. A separate key is used for traffic in each direction. Data integrity is assured using a 16-byte MAC based on SHA-1. SFS never operates in a degraded or insecure mode. Shortening the symmetric key lengths would break compatibility.
Public key encryption and digital signatures are performed using the Rabin-Williams algorithm. Public key size is a configurable parameter; the minimum is 768 bits and the default is 1,280. A "plaintext-aware" (using SHA-1 as a random oracle) padding function is used to protect against adaptive chosen-cyphertext attacks. The computational cost of private key operations is randomized to resist timing-based attacks.
SFS also uses blowfish with 20-byte keys to encrypt NFS file handles in CBC mode. This is to make up for deficiencies in the security of most NFS implementations. It does not affect the security of the SFS protocols if people cannot inject NFS traffic onto your network.
All user-chosen passwords are processed with the eksblowfish algorithm. Private keys are encrypted with eksblowfish when stored on disk. The computational cost of processing passwords in eksblowfish is a configurable parameter; it can be increased as computers get faster to ensure that the cost of password-guessing attacks increases as well.
To establish password-authenticated connections to servers, users first make use of Rabin-Williams to negotiate symmetric keys for a secure channel, then use SRP over the secure channel. The minimum size of the prime used in SRP is 768 bits. Each user can select his own prime and generator for use in SRP, though each machine also has a default prime and generator. Passwords are preprocessed using an eksblowfish-based hash function dependent on the server's name. This ensures that servers cannot impersonate each other when users recycle passwords inappropriately. Moreover, the computational cost of password-guessing attacks by corrupt servers can be scaled as hardware improves.
Yes, SFS works in MacOS X. However, a successful compilation requires a few extra steps depending on which version of SFS you have. We have successfully compiled SFS on MacOS 10.3. Earlier versions of MacOS X result in compiler errors.
To compile SFS 0.7.2 on MacOS X, you will need to patch the source in the tar ball.
As of this writing in March 2004, compiling the current SFS source code from CVS requires a different patch. We are testing the patch and will post a message to the SFS users list when we are ready.
Yes, with some fiddling. John Pormann write a FAQ on poking SFS through a NAT.
There is a public mailing list, sfs@sfs.fs.net, for SFS users and others interested in SFS. Send mail to sfs-subscribe@sfs.fs.net to subscribe to the SFS mailing list.
You can also send mail to sfs-dev@pdos.lcs.mit.edu to contact the authors of the software.