Crypto networked filesystem

Edward Glowacki glowack2@msu.edu
Thu, 8 Feb 2001 15:44:03 -0500 (EST)


Sigh, today is just one of those days where my mind can't seem to
wrap itself around anything useful, can't seem to get any work
done. =(  At any rate, I wrote this up earlier, figured I'd post
it to the list and see what everyone thinks.  =P  Sorry if it's a
bit confusing, didn't go back and proofread it too much.


Why doesn't there exist an encrypted network filesystem that supports
arbitrary user-mountable structures?  If I have a box at work that
I want to access at home over insecure dialup or across the insecure
internet, there should be a method for doing so safely via encrypted
TCP channel (SSL? SSH tunnel?).  Here's an example of how it might
look.

>ls -al data
total 2
drwxr-xr-x   2 glowack2  wheel   512 Feb  7 11:01 .
drwxr-xr-x  34 glowack2  wheel  2560 Feb  7 11:00 ..
>mount -t cryptonet glowack2@hurakan:/home/glowack2/data ./data
Public key authorized.
password for glowack2@hurakan: ************
>ls -al data
total 16
drwxr-xr-x  22 glowack2  wheel   512 Feb  6 09:17 .
drwxr-xr-x  34 glowack2  wheel  2560 Feb  7 11:00 ..
drwxr-xr-x   3 glowack2  wheel   512 Feb  7 11:28 articles
drwxr-xr-x   5 glowack2  wheel   512 Jan 30 18:06 class
drwxr-xr-x   8 glowack2  wheel   512 Oct 16 16:42 doc
drwxr-xr-x   2 glowack2  wheel   512 Feb  6 14:29 faq
drwxr-xr-x   2 glowack2  wheel   512 Sep 20 14:45 gllug
drwxr-xr-x   2 glowack2  wheel  1024 Dec 20 14:26 humor
drwxr-xr-x   6 glowack2  wheel  1024 Dec 28 16:23 images
drwxr-xr-x   3 glowack2  wheel   512 Sep 20 14:12 mail
drwxr-xr-x   4 glowack2  wheel   512 Jan  4 11:48 misc
drwxr-xr-x   3 glowack2  wheel  1024 Feb  6 14:17 mud
drwxr-xr-x   2 glowack2  wheel   512 Feb  7 10:59 programming
drwxr-xr-x   2 glowack2  wheel   512 Nov  3 13:50 resume
drwxr-xr-x   9 glowack2  wheel   512 Feb  7 10:57 web
drwxr-xr-x   5 glowack2  wheel   512 Dec 21 10:50 writings
>


The connection between boxes would be a single TCP stream to make
it easy to travel through firewalls.  mount_cryptonet on the client
side would set up the communication channel and the kernel driver
for cryptonet would use that channel to relay requests to the
server.  The client OS would have to allow user-mountable filesystems
in some fashion, perhaps suid root on the mount_cryptonet binary?
The server daemon would listen on a single port and fork to handle
requests.  Either side could initiate a shutdown of service, either
through the umount command on the client or maybe a SIGUSR signal
on the server side.

Authentication would be done in basically the same manner as SSH,
i.e. DSA keys, passwords, etc.  Additionally, the server config
may restrict access via tcp wrappers, lists of users with permission
to use the service, etc, and the client mount command could check
that system's config for valid users and/or hosts.

Any directory would be shareable in this manner, subject to
restrictions imposed by the config file as to what can/cannot be
exported.  Some examples might be: you can only export a directory
you own, you can't export /etc /dev or /tmp, you can't export to
bad.guy.com, etc.


Is this possible (and practical) to do?  Why hasn't it been done yet?


-- 
Edward Glowacki				glowack2@msu.edu
GLLUG President				http://www.gllug.org
Imagination is the one weapon in the war against reality.
                -- Jules de Gaultier