Re: Embedding Guile with sandboxing

[Matthew Keeter <matt.j.keeter@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

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 <roberto.baleno@gmail.com> 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 <cwebber@dustycloud.org> 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
> 
> 


[-- Attachment #2: Type: text/html, Size: 4442 bytes --]