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

[Marc Stiegler]

Hey, markm, have you published the list of safe (importable) and/or unsafe
(unsafe:able) classes from the API? I can't find it in a brief run through
the site.

--marcs

----- Original Message -----
From: Mark S. Miller <markm@caplet.com>
To: Marc Stiegler <marcs@skyhunter.com>
Cc: E Language Discussions <e-lang@eros-os.org>
Sent: Wednesday, November 29, 2000 6:13 PM
Subject: Re: [E-Lang] Announcing stl-E 0.8.9k: An interim non-distributed
release


> 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
>
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>