Matthew Keeter writes:

> I’m currently embedding Python in a C / C++ application that evaluates
> user-provided scripts.
>
> Obviously, this is terribly unsafe: user-provided scripts can execute
> arbitrary malicious actions, and there’s no good way to sandbox Python
> in a desktop context.
>
> If I were to replace Python with Guile, is there a way to sandbox it
> so that arbitrary (perhaps malicious) user-provided scripts can be run
> safely?
>
> Regards,
> Matt

I think there's nothing in Guile that provides sandboxing currently.

A path towards it is possible though: a limited subset of guile in a
capability security based environment could probably provide the
features desired.  See the Rees Thesis:

  http://mumble.net/~jar/pubs/secureos/secureos.html

Wingo has written about it with respect to Guile:

  http://wingolog.org/archives/2011/03/19/bart-and-lisa-hacker-edition

I have thought about how this could be achieved in the Guile-verse.  My
suspicion is that the best way to achieve it is to provide a new
language layer on the compiler tower which is "mostly scheme", but only
exposes a number of deemed-safe operators by default, and provides a
mechanism to add further procedures to the default environment.
Everything from there on out takes the "capability security through
lexical scope and the labmda calculus" approach described in the Rees
Thesis.

However, this doesn't exist in Guile at present.  I'd love to see it
exist, though.

 - Chris