Re: Restricting Guile: a Guile-based sandbox.

[Rob Browning]

Alejandro Forero Cuervo <address@hidden> writes:

> 1. Restrict the maximum time a given call to gh_eval_call might take.
>    Hopefully without using alarm(2).  The restriction might be based
>    on the number of cycles or total number of function calls or
>    something along those lines.  I just need to make sure a malicious
>    user can't take control of the server process through here.

With the new beta, we've added setitimer and getitimer at the guile
level, and so (wondering out loud) you might be able to set it up so
that you set the profiling timer when you start the user's code, and
then if the timer goes off while the user's code is still running,
kill the code.  Now it might take some experimentation to figure out
*how* you want to kill the code since you'll probably be limited in
what you should do from the profile signal handler, but here's one
thing that comes to mind:

Since you'll be using a safe envt for the users code, and can
explicitly provide all the symbols the user's allowed to use, you can
wrap these in code that checks a should-die? flag.  i.e.:

       (define (user-+ . args)
          (if should-die? (exit-continuation 'timed-out))
          (apply + args))

or similar, where exit-continuation is a continuation you captured
before you started executing the user's code.  Or perhaps you could
use exceptions here as long as you set it up so that any "catch"
function the user has access to can't catch the "die" exception.

Another possibility, though I don't know how practical, would be to
add an apply-frame (or other trap) handler that would check the
should-die? flag.  This might avoid having to define special versions
of *all* functions.

> 2. Restrict the maximum memory a given call to gh_eval_call might
>    consume.

This one I can't think of any easy way to handle unless you're going
to only launch one guile-server per user (which might solve a bunch of
other safety problems).  If you did that, then you might be able to
use the OS's quota tools, or you might be able to run a check every
now and then inside guile on the memory allocation and have the server
kill itself if things get out of hand.

> 3. Restrict the functions/symbols provided in the environment that the
>    gh_eval_call evaluates in to a specific set, so only functions I
>    explicitly list can be executed.

As Martin suggested, you should be able to do this with the safe envts
in the new guile beta (soon to be 1.6.0).

> 4. Reset the environment after executing the user's code, so that if
>    it defined symbols, they will be lost and the memory they used will
>    be freed.  This is necessary so the users won't be able to corrupt
>    the environment in any way.

I presume that the safe-envts above might handle this, but you might
also want to check out the guile info page on "Dynamic Roots".

> Creating a different Unix account for each user is, unfortunately, not
> an option.

If creating a separate invocation of guile for each user (even if
they're all running as the same unix user) is feasible, that might
help avoid some of the "interference" and resource control issues.

One thing to bear in mind is that guile's only recently been
considering the malicious user scenario, so there may still be ways a
someone could lock things up.  This is a case where launching a
separate unix process to "watch" the guile process(es) running the
users' code and kill them when needed might help.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD