Internet File System?

The other day, it occurred to me that Java could really take off if there
was some sort of file system.  And, since you can't write to local files
with Java, the obvious solution is to set up the 'fopen, fclose(), etc)
set of functions that are 'rpcs' to some server application on the same
computer as the web server the applet comes from.

Since I never manage to come up with new concepts, I assume someone is already
working on this, or has already created this.  

In any case, I've been trying to figure out the best balance of security
characteristics for this sort of system.  I've written something up at
a very high level -- Please let me know what is wrong
with it. 

1)  Before any files can be written or read, the applet has to prompt the
    user for a password.   
2)  Password is encrypted one-way, and sent to the server.
3)  Server establishes a 'session' (TCP) with the client.  At the point, the
    options are:  
     -- use SSL to maintain security (probably the best, if available)
     -- providing some sort of encryption, similar to SSL
4)  Server would handle all the traditional file manipulation routines, 
    possibly with some restrictions (no access to directories, maybe?)
5)  If someone wanted to get a local copy, they would have to ftp to the
    server, and go to the appropriate place to get it.

I can tell this has a couple of weaknesses:
 a) central authority for creating accounts, maintaining users, etc.
 b) server side can view all the files at will.
 b) susceptible to trojan servers

I don't know how to reliably solve a).  If you don't have some sort of central
user admin, you can't avoid denial of service/resource wasting attacks.

b) Could be solved by having the user type in (or cut and paste, etc) their
   entire public key.   They could ftp the encrypted document back, and
   decrypt it with the private key.  This would detect and prevent a lot
   of problems, but dealing with the key would be a bit cumbersome.  

c) If the server has to send out some sort of validation code that the
   clients have to accept, it will work ok.  But if the attacker has access
   to the server, they may have access to the java code, and may be able
   to modify it to not perform the validation.

Any ideas ?

  Thanks for your time.
---
John Brothers 
   Do you have a right not to be offended?

John Brothers wrote:

| The other day, it occurred to me that Java could really take off if there
| was some sort of file system.  And, since you can't write to local files
| with Java, the obvious solution is to set up the 'fopen, fclose(), etc)
| set of functions that are 'rpcs' to some server application on the same
| computer as the web server the applet comes from.

	Interesting idea.  But, this requires that for disk access,
the applet have network access.  Violates the principle of least
privledge.

	The correct solution seems to me give the applet limited local
disk access.  To those who claim this can't be done, I point to the
UNIX kernel, which, with a small set of primitives, controls disk
access pretty effectively.  (Quotas were added in 1984.)

	This micro kernel could be added outside of the Java VM, so
that the Java code can't touch it, only call it.  The V7 kernel is
pretty small and efficient by todays standards.   Might want to use
BSD4.4 instead, and also get portals, which would allow you to use
/dev/tcp/www.netscape.com/80 as a file with certain permissions.  See 
http://www.bsdi.com/bsdi-man?proto=1.1&msection=ALL&apropos=1&query=portal



Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

-----BEGIN PGP SIGNED MESSAGE-----

# The other day, it occurred to me that Java could really take off if there
# was some sort of file system.  And, since you can't write to local files
# with Java, the obvious solution is to set up the 'fopen, fclose(), etc)
# set of functions that are 'rpcs' to some server application on the same
# computer as the web server the applet comes from.


Here's my crypto-friendly design for this. 


Define a new TCP protocol called "Blocks Colon".
It forms URLs like

	blocks://blocks.aol.com/strick

This protocol is similar to a "block device" in unix,
with basic operations to read and write 512-octet blocks,
named by an integer index.  Other operations are to ask the size 
of the block file, to change its size, to commit/abort changes,
and session authentication (like a POP server).




Then in the JAVA box you need

	-- a class implementing a 'filesystem' (files & directories)
	   on a "block device"

	-- a "block encryption" filter

	-- a "block device" client using the "blocks colon" protocol


So your program uses the filesystem object, which uses
the block encryption filter, which uses the block client,
which goes to your ISP's block service.   The internet and
your ISP sees nothing but encrypted blocks.   The encryption key
never leaves your personal java box.

Your ISP charges you by the block/hour for storage, and by the number
of blocks read/written for network.  You could keep a backup
blocks account at another ISP, and keep the two blocks mirrored
(another filter?) or run occasional backups. 



What annoys me is that java.io.* defines specific classes for
filesystem access, rather than a "factory class" and thereafter 
nothing but interfaces.  That makes it difficult to override
the "builtin" notion of a filesystem with network-based or
crypto-based filesystems, without changing your programs,
or tampering with the builtin classes.  :(


strick



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQBaAwUBMkcA0xLAL4qMWktlAQEWPwInbnDWq9o1eosKVCqwjuj+7pDlJ8CRaNCt
XflpcmyK8di9rQKS5CMGnSdfvOVJA4epJsGAAKuLfPcSAn4yuKLfsJBcm/Is
=DLWN
-----END PGP SIGNATURE-----