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

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


On Sun, Feb 10, 2013 at 1:45 AM, Ano Hito <[e-mail]> 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?
>
> 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. ;)
>
> --
> Posted via http://www.ruby-forum.com/.
>
>


-- 
Tony Arcieri