Embedding Guile with sandboxing

Embedding Guile with sandboxing

[Matthew Keeter]

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

Re: Embedding Guile with sandboxing

[Pascal J. Bourguignon]

Matthew Keeter <matt.j.keeter@gmail.com> 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?

Well, I would use ecl (Embeddable Common Lisp) rather, but the problem
is not specific to a language.

To ensure "safety", you need to _control_ things.

Using a general algorithmic programming language with OS or platform
interfaces will never be safe.

What you need is to write your own implementation. It doesn't matter of
what language.

For example, you could take pypy, expurge it from the "dangerous"
operations and go on with the resulting restricted python.

Or you could do the same with guile or Common Lisp.

The advantage of the later languages, is that it is easier to write
languages in them, reusing parts of the existing infrastructure.  I
imagine the same can be done with pypy.   On the other hand, if you mix
metalinguistic layers, you may introduce leaking bugs.  


Ultimately, the problem comes down to the fact that the underlying
hardware and OS layer is not safe itself.  One easy way to allow
potentially hostile code to run, is to make it run in a chroot, nope, we
know it's not safe, so in its own virtual machine (either on an
hypervisor or a qemu or simular), but, nope, we know it's not safe
(there are exploitable bugs in hypervisors and qemu, etc).


So you need to implement a language that won't provide any unwanted
OS/platform API and that won't provide any way to generate code accessing
to any unwanted feature, and that still allows user to write useful
programs, while making no mistake; and since it will run on an unsafe
platform, how will you ensure that a program written in your language
will never be able to have any nefarious side effects?

For example, the x86 MMU is turing complete.  How do you ensure that
there is no way any program written in your language will not have the
side effect of introducing a nefarious program in the underlying MMU?


Perhaps it would be easier to select good users, and just give them full
Common Lisp with ecl (or full guile).


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Embedding Guile with sandboxing

[Amirouche Boubekki]

Le 2015-11-21 22:39, Pascal J. Bourguignon a écrit :
> Matthew Keeter <matt.j.keeter@gmail.com> 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?
> 
> So you need to implement a language that won't provide any unwanted
> OS/platform API and that won't provide any way to generate code 
> accessing
> to any unwanted feature, and that still allows user to write useful
> programs, while making no mistake; and since it will run on an unsafe
> platform, how will you ensure that a program written in your language
> will never be able to have any nefarious side effects?

If you want to go that route I recommend you have look at GNU epsilon 
[1][2]
which is basically a framework for building languages. It's still alpha.

HTH

[1] https://www.gnu.org/software/epsilon/
[2] http://lists.gnu.org/archive/html/epsilon-devel/

Re: Embedding Guile with sandboxing

[Thompson, David]

On Sat, Nov 21, 2015 at 1:35 PM, Matthew Keeter <matt.j.keeter@gmail.com> wrote:
> 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?

I recommend using the features of the underlying operating system to
provide the sandbox.  In Linux, one can create new
user/pid/network/mount/etc. namespaces (in other words, a "container")
that isolate a process (or processes) from the rest of the system.
Additionally, you should run the program as an unprivileged user
inside of a chroot.

- Dave

Re: Embedding Guile with sandboxing

[Arne Babenhauserheide]

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

Am Samstag, 21. November 2015, 13:35:12 schrieb Matthew Keeter:
> 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?

The languages which try to do that are Java and Javascript, and they
have several bugs connected to this every year (which i.e. allowing
execution of code with elevated priviledges).

To make this safe, you could follow the route described by Pascal:
Define a restricted sub-language which is not turing-complete. You can
do that with a medium amount of hassle with Guile (my personal
estimate). This will not give users a full programming language —
which is exactly why it can be made safe.

Best wishes,
Arne

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Embedding Guile with sandboxing

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Nov 22, 2015 at 11:06:05AM +0100, Arne Babenhauserheide wrote:
> Am Samstag, 21. November 2015, 13:35:12 schrieb Matthew Keeter:
> > 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?
> 
> The languages which try to do that are Java and Javascript, and they
> have several bugs connected to this every year (which i.e. allowing
> execution of code with elevated priviledges).
> 
> To make this safe, you could follow the route described by Pascal:
> Define a restricted sub-language which is not turing-complete. You can

I think the problem isn't Turing completeness. It's the access to
the whole machine environment.

Still a tall order.

As another point, the Tcl community has had something they call "safe"
for quite a while (they can have several interpreters in one executable
and can instantiate so-called "safe" interpreters [1]). Might be worth
a look (for inspiration -- or for use).

[1] <http://wiki.tcl.tk/4204>

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZVln4ACgkQBcgs9XrR2kYQyQCfTADGl0E80DtDZcCvuCcBhdhe
lZcAn2O4S4bQbWYtVcJUP/S/R/IlBJdg
=3+xj
-----END PGP SIGNATURE-----

Re: Embedding Guile with sandboxing

[Christopher Allan Webber]

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

Re: Embedding Guile with sandboxing

[Roberto Baleno]

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

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: 2821 bytes --]

Re: Embedding Guile with sandboxing

[Matthew Keeter]

[-- 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 --]

Re: Embedding Guile with sandboxing

[Christopher Allan Webber]

Antimony looks really cool!

I agree that Guile doesn't provide a silver bullet here.  Again, I think
it can be done... though I think it'll require a lot of yak hair
traversal to get to that point :)

Good luck, have fun, and happy hacking!