After having some trouble getting the j-ruby sandbox gem to work
(Error When Loading jruby-sandbox in Applet - JRuby - Ruby-Forum), and giving some thought to
the idea of writing a pure ruby implementation of the sandbox (a more or
less unworkable idea), a thought occurred. Why doesn’t ruby ship with a
sandbox class?
I know ruby has safe levels, and safe levels do work for many scenarios
in which you wish to run potentially unsafe code. But they really don’t
offer the same fine grained control that a true sandbox does. There’s
just something really appealing about the idea of:
class A
def initialize
B.new
end
end
class B
def initialize
puts “test”
end
end
box = Sandbox.new
box.ref A
box.eval(“a = A.new”) #“test”
box.eval(“b = B.new”) #fail: I don’t know what a “B” is
This is simple, elegant, and far better than setting “$SAFE = 4” and
hoping for the best. It’s also the model Why used for his Freaky Sandbox
project. Why wrote his sandbox more than 6 years ago in the hopes that
it would make ruby a more useful language. Unfortunately his
implementation was rather hacky and difficult to install, leaving much
room for improvement. But here we are, more than 6 years later, and the
options for sandboxing ruby still suck.
The current option are as follows:
$SAFE = 4: Works well for cases where you just want to keep bad things
from happening, but offers no real way to specify what objects code can
or can’t access.
jruby-sandbox: Works well, but of course requires jruby which is not
always an option.
Why’s Freaky Sandbox: Sure, just keep using ruby 1.8.6 forever and
you’re set. Why not?
shikashi (GitHub - tario/shikashi: shikashi is a ruby sandbox that permits the execution of "unprivileged" scripts by defining the permitted methods and constants the scripts can invoke with a white list logic): I couldn’t even get it to
work on my system (C extensions wouldn’t compile) so I can’t comment on
it’s effectiveness. However, after examining the source code for a bit,
I think the implementation is misguided at best. I can’t entirely blame
the dev though because the truth of the matter is…
Sandboxing is not something that should be left to a third party to
develop. It belongs in the core of the language if it belongs anywhere
at all. So why isn’t it? Personally I have a few theories.
It could be that the ruby devs think safe levels are good enough. I
would buy this, except safe levels are a very inelegant and unrubylike
solution to a problem for which a much simpler solution could exist.
Need to mess with something unsafe? Just throw it in the box. Why use
constructs like “taintedness” when you could just throw them out in
favor of something more effective and flexible, but less complicated.
It could also be that the ruby devs are convinced that the third party
offerings are already satisfying the demand for a ruby sandbox. I think
you could make this argument for the case of jruby, but for any and all
other ruby implementations out there, the truth is, no, no they aren’t.
But maybe they think nobody needs or even wants sandboxing? I’m sure a
lot of people don’t, but sometimes you never know how useful something
can be until you have the option of using it. As much as sandboxing
could become a bad solution to many common problems, it is still the
only solution to a set of less common problems. Personally I think the
number of problems that are unsolvable with a language is always
something worth reducing. Especially if it might also serve to simplify
things that are currently implemented in a complex way.
That leads me to my last theory, maybe there is just no good way to
implement a sandbox in ruby without it becoming an ugly hack? I can’t
give a definitive answer to this question because I am not as familiar
with ruby’s internals as I would like to be. What I can tell you is that
at the very least, if I was building a ruby implementation from scratch,
I know how I’d do it.
Here’s how it would work. As opposed to having a single object space for
everything, we allow for the creation of multiple object spaces
(ObjectSpace.new). Every thread would then be attached to the object
space it was created it, so that anything you did in that thread would
exist in a separate world from anything happening in another object
space. You could use objectspace.eval to make stuff happen in any object
space for which you have a reference. If you want to put something in an
object space, you can call objectspace.ref a_thing, and it now exists in
that object space too. Sort of…
To implement this properly you’d need a wrapper class (SharedObject).
Then when you called sandboxspace.ref object, it would create a instance
of a wrapper for the object that would exist only in sandboxspace, but
would use the same object id of the original object. The wrapper would
contain only a single send method which would temporarily switch the
objectspace of the current thread (an ability that would of course not
be allowed for normal ruby code), create wrappers for any objects being
sent as parameters, and then send them to the method being called.
Incidentally, due to the overhead involved in this it may be desirable
to allow for duplicating certain class definitions in an object space as
opposed to using wrappers. I don’t really think you want to have to
switch spaces every time you create a string, for example.
I think this would be a very good approach that would offer ruby a much
more flexible security model that it currently has. If only I had the
time or experience with ruby’s code base to implement it… All I can do
is offer my approach as a suggestion. But maybe it will get the ball
rolling, get people talking, that kind of stuff. Maybe someone will
think of a much better approach to implementing sandboxes than I ever
could. Frankly, I don’t know exactly how much work my solution would be
to implement. It could be a weekend project for an experienced ruby dev,
or it could be a massive three month rewrite of tons of mission critical
code. Either way, it would be an improvement to ruby, so I hope someone
at least tries. Remember, you’ll never be able to justify calling it
ruby 2.0 unless you have lots of cool new features to play with. 
