Phil Fraering writes:
How would you make Java secure or create a secure Javalike language? (Secure to your satisfaction, of course).
Well, you can't make anything secure, but you can make things more secure. My fundamentnal design principles are: 1) You can't abuse features you don't have. 2) You can't abuse privs you don't have. 3) You can't catastrophically fail to do something you don't do. I would eliminate the notion of having the Java interpreter make the system "safe" with language features that cripple certain threads of execution. Instead, I'd emasculate the whole system. Remove any i/o features right out of the interpreter -- ditto execution features or other features. I'd run the interpreter in a separate unix process communicating only through two pipes, one down which you feed code and mouse events and one up which you get bitmaps and URLs to fetch. The interpreter runs in a padded cell and can't alter the world except by passing up bitmaps and URLs. It doesn't talk to anything other than the browser. Even then, I'm not entirely comfortable, but I'm more comfortable.
What sort of interface does it have to the filesystem? I would guess that a secure language would have its own filesystem mapped to a file of fixed size in the normal filesystem, so that it couldn't cause disaster by filling your hard disk.
Thats not a secure system, because you depend on the interpreter properly doing the mapping. If there are no system calls to open(2) in the whole program it can't misuse any of those calls. If there are no calls to exec, it can't mis-execute things. Security through emasculation. Perry