Eval, SAFE, and Sandbox

Hello Ruby Forum.

I am working on a personal project that will need people to be able to
submit bits of Ruby code so that my project can run it (eval). I know
there is a lot of danger in this and wonder if there are any solid ways
to avoid malicious attacks.

From what I have read and seen on Google, there is the $SAFE (=4)
variable which is supposed to prevent many vulnerabilities, but at the
same time, there are many sources saying this is not reliable. Also, I
have seen that a year or 2 ago, there was a popular Ruby project called
Sandbox, created by a whytheluckystiff, who has apparently disappeared
off the face of the planet, and thus killing the project.

So I am wondering if I should attempt to work off Sandbox, although I
don’t think it is maintained or updated to the newer Ruby versions
(1.8.7+). I am pretty new to the whole metaprogramming world, so I am
not sure if I could handle this either. Or should I try to create my
own system, using $SAFE, disallowing known loopholes, running in a
thread with a kill time and timeout limit, etc. Or is there an
alternative to Sandbox that I should be looking at that my research has
not turned up? Thanks for your time.

  • simon

On Fri, May 21, 2010 at 1:17 PM, Simon M. [email protected]
wrote:

have seen that a year or 2 ago, there was a popular Ruby project called
not turned up? Thanks for your time.

  • simon

Look at Try Ruby.
$SAFE > 3 won’t work in a repl, btw

Andrew McElroy
http://TryRuby.org

Andrew Mcelroy wrote:

Look at Try Ruby.
$SAFE > 3 won’t work in a repl, btw

Andrew McElroy
http://TryRuby.org

Cool, thanks, looks like this should do the trick.

On Sat, May 22, 2010 at 11:27 AM, Simon McBryan [email protected]
wrote:

If you’re on a Mac, you might try Dia. http://github.com/robgleeson/Dia

On Sun, May 23, 2010 at 7:43 AM, Caleb C. [email protected]
wrote:

$SAFE is unlikely to be good enough. Even why’s sandbox probably has
some vulnerabilities.

To be honest, I’m not sure I trust $SAFE because it takes such a
scattered approach to performance. Basically every operation that
mutates needs to check for tainting (and now “untrust” in 1.9) or
there’s a hole. That’s a lot of code to ensure is always doing the
right thing.

Plus C extensions either need to be disabled or audited as well.

Granted…$SAFE is what’s available on MRI, so I don’t have another
solution for non-JRuby users.

Another idea; if you want to use jruby, you could take advantage of
the jvm’s sandboxing capabilities. I believe this would require some
custom java security manager programming.

Actually it can often just come down to configuration. “Programming” a
security manager isn’t generally needed to secure a server or sandbox
an application.

  • Charlie

On 5/21/10, Simon M. [email protected] wrote:

have seen that a year or 2 ago, there was a popular Ruby project called
not turned up? Thanks for your time.
$SAFE is unlikely to be good enough. Even why’s sandbox probably has
some vulnerabilities.

Depending on what you’re doing, you could try running inside a virtual
machine or freebsd jail. These are general-purpose sandbox facilities,
not ruby specific. That’s somewhat difficult to set up, but they
should be very solid choices.

All these ideas could be combined. That is, you run with $SAFE=4, in
why’s sandbox, inside a jail in a freebsd installation running in a
virtual machine. That way, you have multiple layers of protection, and
the best of all worlds.

Another idea; if you want to use jruby, you could take advantage of
the jvm’s sandboxing capabilities. I believe this would require some
custom java security manager programming.