[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] E [being] insecure
From:       Mark Miller <markm () caplet ! com>
Date:       2004-07-28 18:06:04
Message-ID: 6.1.2.0.2.20040727081215.03c21ec0 () caplet ! com
[Download RAW message or body]

At 03:11 AM 7/27/2004  Tuesday, Knut I. Nesheim wrote:
>I'm new to E, and programming in general. I find E to be very exciting and I 
>would like to learn it.

Hi Kurt, welcome!

The following response may be more detailed than your looking for, but on 
security questions, I prefer to err on the side of completeness first. 
Please let me know if things are still unclear. Thanks.


(cc'ed to cap-talk, since this is also a further answer to Jed Donnelley's 
query in
http://www.eros-os.org/pipermail/cap-talk/2004-May/001829.html :
>Secondly, I'm very suspicious of any efforts to install protection
>boundaries between program modules within a shared memory
>application. [...]

Kurt, see also MarcS' answer to Jed at 
http://www.eros-os.org/pipermail/cap-talk/2004-June/001831.html
)


At 03:11 AM 7/27/2004  Tuesday, Knut I. Nesheim wrote:
>However, I have some conserns:
>
>If E is built on top of Java, and Java is insecure, how can E be secure?
>
>Obviosly, I am wrong, but I can't see where. Please tell me.


It's a good question. The key is how new code from potentially untrusted 
sources enters the system. If you ran an E-on-Java system, where your system 
was willing to load Java class files from potentially untrusted sources, 
then your E system would have no better security than Java's ability to 
sandbox. Likewise, Java is built from C, but Java's security, such as it is, 
does not depend on C's (non-existent) security. If your Java process were 
willing to load and run arbitrary *.dll or *.so files from potentially 
untrusted sources, or if you install *.exe applications from potentially 
untrusted sources on the same platform, then your Java system would have no 
better security than the constraints your OS imposes on arbitrary machine 
code. Extending the analogy one step farther down, if your OS is willing to 
load code (such as device drivers) from potentially untrusted sources to run 
as part of the kernel (in system mode, at ring 0), then your security would 
be truly non-existent.

In like manner, E's security does not derive from Java's security. To E, 
Java is just an implementation language. The following arguments would apply 
with equal force if E were implemented directly in C.

All these loaders load data describing behavior (i.e., "code"), and 
magically turn it into executable behavior. It doesn't matter whether this 
happens by interpretation, compilation, some mixture, or other techniques. 
The security claims made by any of these systems relies on the assumption 
that data from potentially untrusted sources only becomes executable behavior via its 
loader (in our case, the E eval function), or loaders built on top (such as 
meta-interpreters), but that all the loaders of lower level systems it is 
built on (i.e., the Java ClassLoader, the *.dll or *.so loader, the OS's 
exec function, the hardware's boot loader) being inaccessible to potentially 
untrusted sources of code. 

"Paradigm Regained" http://www.erights.org/talks/asian03/ is the first time 
we've clearly stated the security properties that a loader must have, in 
order for the system to be an object-capability system. (Note, this is not 
invention, but discovery of requirements. The loader of Dennis & van Horn's 
1966 Supervisor behaves in precisely this way, as do most object-capability 
systems since then, including W7's eval function.)

>A loader makes new instances. The creation request to a loader has two arguments:
>code describing the behavior of the new instance, and an index => reference
>map providing *all* the instance's initial state. A loader must ensure (whether
>by code verification or hardware protection) that the instance's behavior cannot
>violate the rules of our model. A loader returns the *only* reference to the new instance.

The "rules of our model" include that the behavior of the instance created 
by loading code+state cannot effect the world outside itself other than by 
sending messages on references it holds, and that the state is the complete 
initial set of such references.

Later we state 'All “linking” happens only by virtue of these 
associations...'. The built-in module system (the import__uriGetter and 
unsafe__uriGetter) used for loading *.emaker files and tamed Java files is a 
good approximation, but not perfect: All emakers currently share the default 
CLASSPATH as the namespace they import from.

CapDesk shows how we should handle these issues. From E's eval, CapDesk 
builds a module system for loading caplets. This module system is written in 
normal E without special privilege, and so cannot help but be 
multiply-instantiable. Each caplet is effectively loaded in a separate 
instantiation of this module system, with a namespace local to that caplet.

We will eventually construct a new module system in E for E along these lines.


-- 
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]