[E-Lang] Announcing stl-E 0.8.9k: An interim non-distributed release

[Mark S. Miller]

At 02:46 PM 11/29/00, Marc Stiegler wrote:
>Since the following point is buried in the middle of markm's message
>announcing the new version of E, I shall pull it out and highlight it for
>everyone who might have either missed the note or missed the ramifications:
>
>> This is the first version of E supporting locally untrusted code (!!!)
>
>In case anyone missed this, it is worth noting that 2 weeks ago markm and I
>thought the ability to locally run untrusted code was at least a year away.
>A breakthrough or two later, and it was a weekend's effort, and this version
>bears the fruit.

Btw, I should have mentioned that several conversations with MarcS 
contributed enormously to finding a way to make this happen quickly.  Thanks!


>It is my belief (correct me if I am wrong, markm) that with this release of
>E, it is now possible to distribute full-power applications (true caplets)
>that are capability secure. For example, the following tiny E program is a
>launcher able to bring to life Emaker caplets with all the power of standard
>desktop office apps like Word, Excel, PowerPoint, and Access, yet bound
>within the confines of the authorities they need:
>
>#Crude but effective Desktop Caplet Launcher
>#On command line, arg1=emakerFilename, arg2=documentPath
>def signalAppFinished() {interp continueAtTop}
>def appMaker := <import: (interp getArgs[0])>
>def doc := <file: (interp getArgs[1])>
>appMaker new(doc, signalAppFinished, <import:java.awt.*>,<import:java.swing.*>)
>interp blockAtTop

>PPS: For those of you who actually want to try this launcher out, the
>imports of swing and awt probably have to be handled slightly differently. 

Very differently.  First and most important is something you already know but 
which your code gets wrong: "import:" can no longer provide access to any 
but a carefully examined set of Java classes that I've decided are safe.  
Except for the small and slowly growing set of classes on this list, all 
other Java classes can only be accessed using "unsafe:", which exists only 
in the privileged scope (the *.e environment), not in the universal scope 
(the *.emaker environment).  So the line instead needs to be

    appMaker new(..., <unsafe:java.awt.*>,<unsafe:javax.swing.*>)

As long as I'm harping on this, I should point out that your "<import: 
(interp getArgs[0])>" is correct, since your intent is that appMaker be 
indirectly confined.

So you also need to point out that this code runs in the privileged 
environment, and is therefore the code that *does* need to be audited to 
determine what powers of its user it may cause to be abused.


>This launcher starts the app with these authorities:
>    --read and write the single document which the user wants the app to
>edit

Correct, because E's wrapping of the java.io.File class carefully ensures this.

>    --inform the launcher it is done (is this really an authority? Probably
>not :-)

Yes it is, since it will typically cause the process to exit.  In any case, 
it is the ability to communicate with something outside the app.

>     --write to the screen, read from mouse and keyboard

Here's where we get into a heap of trouble that is *very* important to 
understand and explain well.  The awt & swing packages are known not to have 
been designed with capability security in mind, and have never been examined 
to understand in what ways they violate capability discipline.  Your above 
code hands the untrusted app all the powers that may be transitively derived 
from all the swing & awt classes, and all their public static variables, 
static methods, and constructors.  No one can understand in what ways the 
untrusted app's authorities have been constrained until someone examines the 
swing and awt libraries regarding these issues (and hopefully providing a 
capability-oriented wrapping of these classes, as I did for the File 
classes).  This is the hard work I had though was needed before supporting 
untrusted code at all.  We now support untrusted code before we've done this 
work, but many plausible security claims, such as yours above, must still be 
postponed until this work is done.


        Cheers,
        --MarkM