Re: modify environments to make sandboxes

[Ludovic Courtès]

Hi,

Thanks for your comments and the nice links!

Alan Grover <address@hidden> writes:

> One approach is to write your own security-manager/white-list. You scan
> the s-expr, check the symbols in the head of any (sub-)list, and fail if
> they aren't approved.

I don't really like this approach, it looks quite "ugly" and impractical
IMO, and it could only be made to work when one has access to the source
code.  Instead, evaluating untrusted code in an environment that only
provides access to the necessary bindings and resources (as I
suggested), thereby honoring the principle of least authority (POLA),
really looks nicer.

> I think there is a R5RS way of doing code-confinement. The R5RS spec
> says that the null-environment "is empty except for the (syntactic)
> bindings for all syntactic keywords defined in this report that are
> either required or both optional and supported by the implementation." I
> take it to mean that you are guaranteed the required keywords, might
> have the optional keywords, but won't have anything else.

Right.  Then you still lack control over the resources used by the
untrusted code.

> Beware, you have to provide a comprehensive black-list. Imagine if the
> guile 1.6 null-environment didn't include every optional-keyword, but
> 1.8 did. Untrusted code could take advantage of the difference. You also
> have to carefully consider the impact of allowing any keyword. For
> example, "let" would allow the untrusted code to do an infinite loop
> (via named-let).

Good point: "black listing" is obviously more risky than "white listing"
because you can always forget an important binding.

> I can't find the place where I originally found this method, but there
> is another example at
> http://www.cap-lore.com/CapTheory/Language/Scheme/SchemeFactory.html
> and the preceding pages. You may want to read these pages to understand
> some other issues around untrusted code.

This is a very nice reading.  It also refers to Jonathan Reed's ``A
Security Kernel Based on the Lambda-Calculus'' [0] which I'm going to
read as soon as I can!  :-)

>> 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.
>
> You can also write a safe-interpreter in scheme, and thus in the same
> process. You solve the above issues by charging the expression each time
> it applies a procedure, each time it consumes heap (roughly at each
> "cons"), etc.

The changes I was describing are the minimal changes that look necessary
to write such a "safe interpreter" (you don't need that if you run the
untrusted code as a separate process: you can rely on `setrlimit' and
friends).

As for control over heap allocation: unfortunately, rebinding `cons' to
a restricted version of `cons' (for instance, once that enforces some
quota) would not be sufficient in Guile.  This is because, for instance,
memory for SMOBs, vectors, etc., is not allocated via `cons'.
Controlling calls to `scm_cell ()' would be better, but still
insufficient.  And anyway, one could hardly control the heap used by
SMOBs (because there's more than one way SMOBs can allocate memory)...

(Of course, we are clearly not considering invocation of untrusted C
code by the untrusted Scheme code!)

> This one is for chicken:
> http://www.call-with-current-continuation.org/eggs/sandbox.scm
> And, again, I can't locate a reference to the original example of this,
> I believe it was R5RS though.

Hmm, I'm not sure I understand how it works.

Thanks,
Ludovic.

[0] http://mumble.net/~jar/pubs/secureos/