At 11:08 PM 9/29/2001 -0400, Mathieu Bouchard wrote:
>On Fri, 28 Sep 2001, Dan Sugalski wrote:
> > *) Some opcodes will just not be available depending on the
> > characteristics you assign to the interpreter. File opens might be
> > forbidden, or code loading, or socket ops, or something. Settable as
> > needed by the interpreter creating the compartment.
>
>Why are files and sockets directly in the bytecode format instead of being
>classes that only happen to be written in C ?
File operations and network operations are fundamental to the interpreter,
so dedicating opcodes to them makes sense. The I/O system's also fully
async (where possible, and looking async where it isn't) so we need some
good hooks into the interpreter for that anyway.
> > I won't claim it'll be bullet-proof--as long as you can call out to C code
> > it's ultimately unsafe--but we'll do our best to make sure things are as
> > secure as a bunch of non-security folks can make it.
>
>as long as you can put a fence on which C plugins may be loaded you have a
>chance to be safe. when a ".so" is required, check that it's on a list of
>so's that are allowed by the sandbox config.
Ah, the installed images list. Yep, that's being considered too. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
