The Sandbox is Loading Gems and Acting Less Freaky #
I really hoped that 1.8.5 and the sandbox would go hand and glove, but continuing development has caused a split from Ruby 1.8.5. (See the patch.) But, nevermind that, it’ll be okay, considering that the sandbox now loads gems!
require 'sandbox'
hpricot_broken = Sandbox.new :init => :all
hpricot_broken.eval %{
require 'rubygems'
require_gem 'hpricot', '=0.4'
require 'hpricot'
puts Hpricot("<a class=test>link</a>").search(".test")
}
hpricot_fixed = Sandbox.new :init => :all
hpricot_fixed.eval %{
require 'rubygems'
require_gem 'hpricot', '=0.4.47'
require 'hpricot'
puts Hpricot("<a class=test>link</a>").search(".test")
}
Two separate versions of Hpricot, illustrating a broken version and a fixed version, both inside the same Ruby process. This is a new checkpoint for sandbox and I’m calling it 0.1. (Installation instructions.) Available on my development gems or, better yet, as a tarball.
Okay, with matz’ approval, Ruby in CVS has been patched. This means the patch above has been updated or you can just install Ruby 1.8 from CVS.
Matt Todd
Interesting… that really is a tiny patch. But why exactly do you need them to be non-static? (Can you extern them as static?)
Sorry… I’m so rusty (and inexperienced) with C that I probably shouldn’t even be asking! Hah.
I guess I should actually go in and upgrade to 1.8.5… and actually play with Snadbox! Freaky freaky… no more? :)
M.T.
adam
I kept looking at my RedHanded feed, hoping it would do something today. Hooray!
I have some ideas for using snaddox later, could be very handy.
FlashHater
Yey! Hopefully I can get the package maintainer for Ruby on ArchLinux to include this patch.
Logan Capaldo
@Matt, static means “scoped to this compilation unit only”. extern static is bound to have confusing semantics (and is illegal I would imagine).
Matt Todd
Ah. I come from a primarily PHP background which has thoroughly messed me up… ;) But I’d still like to know why… :/
Oh, yeah… Hey, _Why… Well done! :D
M.T.
neil
Does this work on ruby 1.9 cvs?
why
neil: No. Just Ruby 1.8 CVS and a patched 1.8.5.
Farrel
Just a query, will using Sandbox allow one to prevent DOS style attacks that are still possible with a $SAFE=4 thread?
why
Eventually. But, for now, attacks which use ensure are still deadly.
MenTaLguY
Despite all my nattering on about continuations, I think perhaps the best solution is to add a
Thread#kill!which bypassesensure.I’ll see if I can prepare a patch for ruby-core tonight.
why
MenTaLguY: This is the kind of can-do attitude I need right now. We’ve been killing threads softly for too long. Let’s have it.
MenTaLguY
Good news, I’ve got a prototype
Thread#kill!working.Once I backport to 1.8, I think the way I’ll do this is to commit the patch and some bits to sandbox SVN , and let you upstream it with matz.
MenTaLguY
Okay, comitted to SVN . It’s all yours, pal.
MenTaLguY
Here’s a question—should we be using
$SAFE = 4even for friendly (i.e.Sandbox.newnotSandbox.safe) sandbox evals?why
WHOA . That works!
(((*LOVE EXUDES*)))No, let friendly sandboxes do anything. What’s your concern exactly?
why
Oh, and
$SAFEisn’t requisite for the safe sandbox either, since unsafe methods aren’t even exposed. But it will be an option.MenTaLguY
Well, I was just wondering since as of that writing, having a timeout forced $SAFE = 4 too, whether the sandbox was friendly or not. Ok.
MenTaLguY
Okay, I’ve added a
:safeleveloption to request what$SAFEto use for the eval (if any).MenTaLguY
Here’s another issue—sand_table doesn’t appear to build with 1.8.4 anymore, since 1.8.4 doesn’t appear to export a few things like
rb_cBinding. Is that fixable/worth fixing?