Walnut/Secure Mobile Code
(formatting and added links)
|(3 intermediate revisions not shown)|
Latest revision as of 02:24, 21 July 2007
Secure Mobile Code
The key to running code from people you do not trust totally is to run those programs with the least possible authority, and to refuse to run the program if it requires different authority than what you are willing to grant. Straight E programs run with all your authority on your system, just like Java applications and C applications. However, emakers come to life in a confined world totally controlled by the E virtual machine. They have no capabilities except those explicitly passed in by the outside world. This forms the beginning of a trustworthy way of running untrusted software.
Safety Deposit Vault Metaphor
Java introduced the concept of a sandbox for its applets. The sandbox is a space in which no access to dangerous powers is available. To give greater flexibility they introduced the security manager and the ID badge architecture--if the user concludes the applet came from a "trusted source", the applet can get your ID badge and roam wantonly through your system.
A java application that runs in a sandbox is called an applet. An E emaker that embodies a full program is called a caplet. Caplets are not trapped in sandboxes. Instead, you may think of caplets as being trapped in safety deposit vaults. The caplet is started inside the vault, surrounded by hundreds of safety deposit boxes--but not one of the boxes is accessible unless and until you give the caplet a key to that particular box.
Hello World Caplet
Caplets can be thought of as highly stylized emakers. They are granted one authority when they are brought to life: the authority to talk with a powerbox, a trusted part of the caplet launching system that holds, negotiates, and mediates authorities for the caplet. Caplets can, through the powerbox, request needed authorities from the user.
TBD when the caplet framework is good enough to document.
Next Section: Advanced Topics