Why doesn't Ruby have a built in sandbox class?

After having some trouble getting the j-ruby sandbox gem to work
(http://www.ruby-forum.com/topic/4410708), 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 (https://github.com/tario/shikashi): 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. :wink:

On Sun, Feb 10, 2013 at 10:45 AM, Ano H. [email protected] wrote:

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.

Maybe, that fine grained control you are thinking of is too
complicated to realize - or does not even exist.

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.

You make it sound as if people who use $SAFE would not know exactly
how it works.

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 remains to be seen whether the alternatives are really simpler.

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.

I am not a regular user of $SAFE and at the moment I have no idea what
use cases you are referring to here. Can you share some more detail,
please?

Personally I think the
number of problems that are unsolvable with a language is always
something worth reducing.

I wouldn’t say always. All changes come with a cost. If the cost is
too high then the reduction of unsolvable problems is not worthwhile.

Especially if it might also serve to simplify
things that are currently implemented in a complex way.

If that is the case, then, yes, I agree.

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

Did you mean #method_missing instead of #send?

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.

I think there are some issues with wrappers. Assuming object X lives
in object space A and was thrown into objectspace B. Y and Z are
other objects private to object space B.

  1. A method call from Y to X which passes Z as argument would
    implicitly export Z to A. For a sandbox it would not make sense to
    implicitly export something to another box (object space).

  2. How far in the object graph starting at Z do you want to go with
    wrapper creation? It’s not that you only export Z to A but also a
    whole lot other objects. This is not only a security issue (item 1)
    but also a performance issue because you would need a recursive wrap
    of all objects.

  3. How do you ensure objects stay inside their boxes if you
    automatically create wrappers for method arguments? It seems the
    situation is not that different as with a single global object space.

The situation would be easier if you allowed for object graphs
starting at method arguments only objects which are known to the
target object space, i.e. disallow implicit migration. I am not so
sure though whether that solution is so far away from $SAFE - or
creating separate processes which communicate via DRb.

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.

I believe your suggestion certainly needs more thinking. Before we
talk about implementations we should clarify requirements - even more
so as this is a security topic.

Remember, you’ll never be able to justify calling it
ruby 2.0 unless you have lots of cool new features to play with. :wink:

I am pretty sure it’s too late to include such a fundamental
architectural change into Ruby 2.0. That sounds more like a Ruby 3.0
thing.

Kind regards

robert

On Sun, Feb 10, 2013 at 10:45 AM, Ano H. removed_email_addr[email protected] wrote:

After having some trouble getting the j-ruby sandbox gem to work
(http://www.ruby-forum.com/topic/4410708), 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?

PS: I forgot one thing: thank you for starting that interesting
discussion!

On Mon, Feb 11, 2013 at 7:14 AM, Ano H. [email protected] wrote:

Robert K. wrote in post #1096190:

that specifically depended on ObjectSpace not having a new method, but
looking at the ruby source code, it became apparent it would take more
time than I have to familiarize myself with the code enough that I could
even approach the issue of implementing sandboxes, let alone actually
doing it.

I don’t have enough time to follow up on the rest of the discussion
but with regard to timing: 2.0 is RC already and with what you say
above you acknowledge that architectural changes of MRI are a major
effort.

http://www.ruby-lang.org/en/news/2013/02/08/ruby-2-0-0-rc2-is-released/

Kind regards

robert

Robert K. wrote in post #1096227:

I don’t have enough time to follow up on the rest of the discussion
but with regard to timing: 2.0 is RC already and with what you say
above you acknowledge that architectural changes of MRI are a major
effort.

http://www.ruby-lang.org/en/news/2013/02/08/ruby-2-0-0-rc2-is-released/

Ah, ok, things are quite far along. 3.0 it is then. Incidentally, this
bullet point is relevant to my interests regarding the project I was
originally inquiring about in my other thread: “NativeClient support”.
That may prove to be a better option for my project than jruby, as
NativeClient modules are already loaded in a heavily protected sandbox,
which lets me be a little more comfortable relying on safe levels. Then
again, I also just found out about this
(http://qiezi.me/2013/01/09/webruby-1-2-3-tutorial/), which has a fair
amount of advantages, such as not requiring chrome, and having a very
snappy load time. Nice to know there are getting to be more options for
running ruby in the browser.

Robert K. wrote in post #1096190:

You make it sound as if people who use $SAFE would not know exactly
how it works.
Not so much that they wouldn’t know how it works, but that it may
provide a false sense of security. Just look at this
(http://blog.segment7.net/2006/08/30/reducing-safe) and this
(http://www.h-online.com/open/news/item/Multiple-vulnerabilities-in-Ruby-safe-level-and-dl-tainting-736893.html).
Safe levels work by blacklisting things you don’t want to be available
to untrusted code. The problem with this is the same problem with any
type of blacklisting, it violates the principle of least privilege
(http://en.wikipedia.org/wiki/Principle_of_least_privilege). While it
may be nice to think you can be secure by not letting code have access
to things that could be dangerous, it is practically impossible to
predict what is or isn’t dangerous in every given scenario. It’s always
a better idea to use an approach that allows untrusted code access to
what it needs to function, and only what it needs to function. Safe
levels don’t do that.

I am not a regular user of $SAFE and at the moment I have no idea what
use cases you are referring to here. Can you share some more detail,
please?
Why himself actually listed several cases in the original README for his
sandbox:

  • Start small interpreters which can periodically be dumped and
    restarted.
    (Long-running apps can self-upgrade!)

  • Load multiple different versions of a library. Maybe you’re
    converting
    an old version to a new version.

  • Run multiple Rails apps. (Rails is a classic example of a crowded
    namespace
    where two apps’ set of modules cannot coexist.)

I would additionally add to that the ability to run your code under a
hypervisor for added security, even in cases where you trust the code
you’re running. And of course, that I believe sandboxes are in general,
more secure than blacklisting.

Did you mean #method_missing instead of #send?
I could be wrong about this, but I think send is the only method a ruby
object is actually required to have. Otherwise you couldn’t call on the
object to do anything. You could use method_missing, but you’d still
need to have a send method, because I’m pretty sure method_missing only
gets called in the event that the send method fails.

I think there are some issues with wrappers. Assuming object X lives
in object space A and was thrown into objectspace B. Y and Z are
other objects private to object space B.

  1. A method call from Y to X which passes Z as argument would
    implicitly export Z to A. For a sandbox it would not make sense to
    implicitly export something to another box (object space).
    Wouldn’t it? I think that you have to keep in mind that most of what
    you’re doing in a sandbox is interacting with the stuff already in the
    box. In cases where you allow outside stuff to go in, you should
    generally keep it restricted to objects that act as controlled
    interfaces between what’s outside the box and what’s inside the box.
    That being said in order to prevent massive unintentional leaks of
    objects into a box from occurring, it would probably be a good idea to
    make it so you could only access the methods of an object exported to a
    box if it’s class had also already been exported.
  1. How far in the object graph starting at Z do you want to go with
    wrapper creation? It’s not that you only export Z to A but also a
    whole lot other objects. This is not only a security issue (item 1)
    but also a performance issue because you would need a recursive wrap
    of all objects.
    If you’re referring to doing something like wrapping all the objects
    referenced to by the instance variable of objects being wrapped, you
    wouldn’t do that. All method calls to the object would switch the object
    space of the current thread to the object’s native space, in which all
    of it’s references would already be valid. Granted the context switching
    would be a drag on performance, but you wouldn’t be doing it that much,
    because your general goal is to limit the interaction of things in the
    box with things outside of it.
  1. How do you ensure objects stay inside their boxes if you
    automatically create wrappers for method arguments? It seems the
    situation is not that different as with a single global object space.
    While you don’t necessarily keep objects in only a single space by doing
    this, at the least you maintain control over what they can access. Any
    reference to a foreign object, be it in the original object space or the
    one you’re using for a sandbox, is always going to be wrapped. It’s
    methods will always execute inside of it’s native object space. Even
    when an object leaves the box, it never truly leaves the box.

The situation would be easier if you allowed for object graphs
starting at method arguments only objects which are known to the
target object space, i.e. disallow implicit migration. I am not so
sure though whether that solution is so far away from $SAFE - or
creating separate processes which communicate via DRb.
I’m not quite sure how what you’re saying would work. Could you
elaborate a bit?

I believe your suggestion certainly needs more thinking. Before we
talk about implementations we should clarify requirements - even more
so as this is a security topic.
It couldn’t hurt. I mean, if someone does seriously consider
implementing sandboxing as a native feature of ruby, the last thing I’d
want is for it to turn into a security disaster that gets scrapped
before it ever hits a stable release. I will however say that sandboxing
is a tried an true approach to securely executing code. My version of
sandboxing is slightly different from the typical because I was trying
to think of something that would be more in line with the way ruby
already works, and not something that would require dozens of hacks to
implement. If any ruby devs want to jump in here and tell me all the
reasons a more traditional sandbox would be a million times easier to
implement, I’m all ears.

I am pretty sure it’s too late to include such a fundamental
architectural change into Ruby 2.0. That sounds more like a Ruby 3.0
thing.
Is ruby 2.0 getting close to release then? I honestly haven’t been
following ruby’s development closely enough to keep up on these things,
but I was assuming 2.0 was still at least a year away. Well, while
implementing native sandboxing may require some architectural
reshuffling, it wouldn’t require any changes to the ruby environment
itself that wouldn’t be more or less backward compatible with all
existing code. The only thing I could think of is if you’d written code
that specifically depended on ObjectSpace not having a new method, but
I’m not sure that would come up very often. Maybe someone could still
sneak sandboxes into 2.0, you never know.

PS: I forgot one thing: thank you for starting that interesting
discussion!
My pleasure. :wink: I’ve been a long time user of ruby for my personal
scripting needs, but I’ve never really done much as far as contributing
to the greater ruby scene. Well, there’s this
(https://github.com/An0Hit0/Ruby-ISO-9660), which is useful, despite
being unfinished. Anyway, I’d like to contribute a bit more, but after
looking at the ruby source code, it became apparent it would take more
time than I have to familiarize myself with the code enough that I could
even approach the issue of implementing sandboxes, let alone actually
doing it.

I posted a strawman for something similar a few days ago. It’s a bit
different idea from yours and a super-granular class whitelist:

https://gist.github.com/tarcieri/4719525

Clearly that doesn’t cover all the “NO” cases, but I hope it gives you a
general idea

Wow, I wasn’t aware $SAFE=4 was quite that powerful. Too bad it doesn’t
work on JRuby or I might seriously consider using it :wink:

Tony A. wrote in post #1096413:

I posted a strawman for something similar a few days ago. It’s a bit
different idea from yours and a super-granular class whitelist:

https://gist.github.com/tarcieri/4719525

Clearly that doesn’t cover all the “NO” cases, but I hope it gives you a
general idea

Creating a secure context inside of a block would certainly be more
rubylike than $SAFE = 4. But would you allow for managing what classes
and methods are allowed to be used in a SecureContext? Otherwise it’s
not that different from just running the code in a new thread after
setting $SAFE = 4 in the thread’s context.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs