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

[Mark S. Miller]

At 08:05 AM 11/30/00, Marc Stiegler wrote:
>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.

Thanks for the reminder, I had not previously posted it.  In 0.8.9k, the 
safe/import:able classes are:

        java.lang.Boolean
        java.lang.Byte
        java.lang.Character
        java.lang.Comparable
        java.lang.Double
        java.lang.Float
        java.lang.Integer
        java.lang.Long
        java.lang.Number
        java.lang.Object
        java.lang.Runnable
        java.lang.Short
        java.lang.String
        java.lang.StringBuffer
        java.lang.Throwable
        java.lang.Void
        java.math.BigInteger
        org.apache.oro.text.regex.Perl5Compiler
        org.apache.oro.text.regex.Perl5Matcher
        org.apache.oro.text.regex.PatternMatcherInput
        org.erights.e.elang.interp.ProtocolDesc
        org.erights.e.elang.interp.Thrower
        org.erights.e.elang.syntax.EParser
        org.erights.e.elib.base.MessageDesc
        org.erights.e.elib.base.ParamDesc
        org.erights.e.elib.quasi.Identifiers
        org.erights.e.elib.quasi.Substituter
        org.erights.e.elib.ref.BrokenFarRef
        org.erights.e.elib.ref.FarRef
        org.erights.e.elib.ref.Ref
        org.erights.e.elib.prim.E
        org.erights.e.elib.sealing.Brand
        org.erights.e.elib.slot.NullOkMaker
        org.erights.e.elib.slot.SimpleSlotMaker
        org.erights.e.elib.tables.ConstList
        org.erights.e.elib.tables.ConstMap
        org.erights.e.elib.tables.EList
        org.erights.e.elib.tables.EMap
        org.erights.e.elib.tables.FlexList
        org.erights.e.elib.tables.FlexMap
        org.erights.e.elib.tables.IdentityCacheTable
        org.erights.e.net.dcap.SturdyRef
        org.erights.xml.qdom.XMLQuasiParser

This list needs to be rapidly expanded, but no faster than we can carefully 
examine candidate classes for possible holes.  All public classes are 
currently available through unsafe:, but the E-accessible API of the class 
is the public API (public fields, methods, and constructors) as modified by 
the E "sugaring" mechanism, which my previous message incorrectly referred 
to as "wrapping".  

For example, <unsafe:java.io.File> is available, but the API accessible from 
E is the Java public API as modified by 
org.erights.e.meta.java.io.FileSugar.  FileSugar doesn't necessarily make 
File non-authority granting (which is why it's not yet import:able), but it 
does make it follow capability discipline, so that one can reason about how 
much authority is being granted when one hand someone a File, or an object 
derived from a File.  For example, File and related classes, as accessed 
from E, don't allow upward navigation by fetching ".." from a directory. 
A directory can therefore be understood as giving authority only over the 
transitive contents of the directory, rather than the entire file system.

(We will make java.lang.StrictMath import:able only after we remove access to 
random().  Unfortunately, the sugaring mechanism has no general 
method-removal facility, an obvious oversight that will soon be fixed.)

Unlike java.io, all of the sugaring to date of awt & swing has been solely 
motivated by convenience rather than security.  (For example, if you iterate 
an awt/swing Container, you get all the Components.)  That's why I raised 
the objection in my previous message.  An example worry: Are there any 
public methods in awt or swing that take in a filename argument in order to 
open a file of that name?  Perhaps to read an image from it?  If so, then 
when you gave out awt__uriGetter and swing__uriGetter, you also gave out at 
least read access to your file system.

One possible unpleasant shortcut on this unpleasant issue: load the E 
invocation mechanism through another ClassLoader, and use the (bletch) 
sandbox/SecurityManager mechanism to turn off all the Java API that the 
SecurityManager can turn off.  We then use other means to selectively turn 
back on those powers we deem to follow capability discipline.  Javasoft 
hasn't been trying to achieve security in our sense (interaction of mutually 
suspicious agents, cooperation without vulnerability) but they have been 
trying to achieve safety (perimeter security, keeping the bad guys out).  If 
they've done their job well, their safety may be a good first cut on making 
our unsafe: classes be better behaved.  For example, if there is a hidden 
file accessor lurking in swing, it's likely that a maximally restrictive 
SecurityManager would turn it off.  We don't save on auditing time -- we 
still don't know how safe swing is until we examine everything publicly in 
it -- but we may be able to save substantially on the effort to beat/sugar 
it into capability discipline.

But I can't express how reluctant I am to, in effect, mix security models.

    Cheers,
    --MarkM