hoodwink.d enhanced


Sandbox Has a New Patch #

by why in inspect

What was a two-line patch has now become rather significant. Lots of development in the last few revolutions of the sun, mostly in regard to two massively outstanding issues: threading and security. (Instructions updated.)

What & How Many?

  • MenTaLguY’s Thread#kill! method, which circumvents ensure inside the thread.
  • My thread save/restore hooks, which let the sandbox walk in lockstep with your app’s threading.
  • Also, exposing of ruby_top_cref and top_cref to let require work. (Already in Ruby CVS.)

Okay & To What End?

The Thread#kill! patch means we can now timeout threads:

 val = 
   Sandbox.safe(:timeout => 10).eval %{
     loop {}

You can now accept endless loops and other DoS techniques into your safe sandbox and they’ll go away in due course. You’ll see a Sandbox::TimeoutError come back instead.

And the threading stuff means you can load libraries which use threads into separate sandboxes. Or manage sandboxes inside of threads. Whatever. With some encouragement on #camping last night, I got two Mongrels working in separate sandboxes!

 require 'sandbox'
 th = Thread.start do
   Sandbox.new(:init => :all).eval %{
     ARGV = ['', '3000']
     load 'serve-mongrel.rb'
 Sandbox.new(:init => :all).eval %{
   ARGV = ['', '3001']
   load 'serve-mongrel.rb'

It sort of flubs on FreeBSD, but it seems fine on Linux. Anyone got any OSX they can share?

Update: Yay, matz has approved patches for both 1.8 and HEAD. We are on our way!

said on 07 Sep 2006 at 14:44

Whadda mean, “share”?

said on 07 Sep 2006 at 14:46

Like some OSX experiences. Heartfelt, Bil!

said on 07 Sep 2006 at 15:37

I got scared by the patch.

said on 07 Sep 2006 at 16:44

keep up the great work, hope to see some non-flubbing on the freebsd.

said on 07 Sep 2006 at 16:58

Yeah, most sandbox dev is done on FreeBSD. And most thread/sandbox combinations work fine, but the dual Mongrel test doesn’t somehow.

said on 08 Sep 2006 at 03:09

The patch has been “OK”ed by matz, so the stable snapshot should soon be able to run the latest sandbox again.

said on 08 Sep 2006 at 11:32

Hah, excellent. Putting struct thread in a public’ly-accessible header file is very nearly just the hook I need to solve my libgc woes, too!

We are totally doing this, why.

said on 09 Sep 2006 at 14:27

Irb in a firefox tab, Irb in a firefox tab, irb in …

said on 09 Sep 2006 at 14:28

oops the closing < tag has been cut off. Guess I explain the above then – IRB , in a firefox tab, rocks! =)

said on 09 Sep 2006 at 17:01

very cool

said on 09 Sep 2006 at 21:17

Does this mean we’re going to get the sandbox to a future Ruby 1.8.x as well? That would be awesome!

said on 10 Sep 2006 at 20:44

Jon: That’s the hope. It’s also basically a prototype for what we want to have in terms of Sandboxing for Ruby 2.0.

The design of Ruby 1.x necessitates a lot of ugly hacks to pull this off, but hopefully matz can make accomodations in 2.0’s design to make this easy, based on what we’ve learned from implementing Sandboxing in 1.8.

said on 12 Sep 2006 at 02:13

You’re really doing it, you’re living the dream!

Thanks ever so much for your diligent fiddling, why & MenTaLguY.

said on 13 Sep 2006 at 14:34

But we know it cannot be sandwiched
Between two adjacent moments, that its windings
Lead nowhere except to further tributaries

said on 19 Sep 2006 at 22:34

_Why, do you have a guide to hosting multiple Rails apps in sandboxes? Or a few minutes of time in #camping sometime? We would like to host all the Railsday entries for a community judging effort, since real Railsday is defunct. I don’t know how to deploy this, though.

11 Jul 2010 at 21:11

* do fancy stuff in your comment.