Re: modify environments to make sandboxes

From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: guile-user@gnu.org
Subject: Re: modify environments to make sandboxes
Date: Thu, 22 Jun 2006 14:34:10 +0200	[thread overview]
Message-ID: <873bdxtlml.fsf@laas.fr> (raw)
In-Reply-To: <871wtuuj1v.fsf@ossau.uklinux.net> (Neil Jerram's message of "Mon, 12 Jun 2006 23:05:00 +0100")

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Code confinement is indeed an interesting feature.  Fortunately, Guile
>> offers various ways to do it (AFAIK, there's no standard way to do this
>> in R5RS Scheme).  :-) [...]
>
> That's a very nice explanation.  Is there a good place for it
> somewhere in the manual?  (If not, perhaps we should start a "How can
> I do XXX" section.)

(Sorry, I think I had skipped this message.)

We don't have "how to" sections in the manual, but for this specific
topic, perhaps we could add a subsection under "The Guile module
system"?

Note that control over a module's name space (as described in my post)
is not the only thing needed to safely evaluate untrusted code.  The
user would also need finer control over all the resources used by the
code at hand (in order to prevent DoS attacks), particularly memory
(heap and stack) and CPU.

Unfortunately, I don't think this can be realized using Guile, except
maybe by running the untrusted code in a separate process and relying on
the OS' resource accounting mechanisms (e.g., `setrlimit' --- but Guile
core doesn't provide bindings for it).  However, running untrusted code
in a separate process would preclude, practically, resource sharing with
the user's trusted code (e.g., an Xchat Scheme plug-in would be useless
as a separate process because it would be unable to access the data
structures of the "real" Xchat).

The "ideal" solution would imply things like:

  * changing the evaluator so that several evaluators with different
    `eval-options' can be instantiated (pretty much like the
    `guile-reader' approach); this way, untrusted code could be
    evaluated with an evaluator that has custom stack limits;

  * having, roughly, a `current-heap' fluid that would be referred to
    anytime heap is allocated (hmm...);

  * similarly, have CPU time slice capabilities that would be passed
    to `eval' either explicitly or via a fluid.

But, well, going back to the documentation issue at hand, perhaps we can
just mention that Guile lacks certain features to allow for really safe
execution of untrusted code.  ;-)

Thanks,
Ludovic.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user