Re: Embedding Guile with sandboxing

[Matthew Keeter]

Context: Antimony is a tool for computer-aided design that makes heavy use of

user-defined scripts (http://www.mattkeeter.com/projects/antimony).

I’m considering other languages, either for Antimony or future projects.

Python is great, but I’m running into two main issues:

It’s hard to distribute:

You need to include a full Python distribution in your application

It’s hard to sandbox:

chroot / unprivileged user works on Mac / Linux but not Windows, and makes the

application more complicated — do I need to write some kind of unprivileged daemon

that’s doing all of the dangerous evaluation and talking with the main application?

(also, it’s required that you include Python.h before any other headers, which is a

small but persistent nuisance).

Thanks to all for the tips: it sounds like Guile isn’t a silver bullet, but I’ll definitely keep it

in mind for future projects.

Regards,

Matt

On Nov 22, 2015, at 7:50 PM, Roberto Baleno <address@hidden> wrote:

I've also been thinking about this issue with an embedded language I am developing in Guile.  How about the good old metacircular evaluator:

https://mitpress.mit.edu/sicp/full-text/sicp/book/node76.html

BTW, Matt, are you porting "Antimony" to Guile? :)

--Bert

On Sun, Nov 22, 2015 at 3:51 PM, Christopher Allan Webber <address@hidden> wrote:

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