[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

[YAY] my sandboxing extension!!

From: why the lucky stiff <ruby-core@...>
Date: 2006-07-19 09:40:34 UTC
List: ruby-core #8271
I have (what feels like) very exciting news.  I finally sat down to code up my
sandboxing extension, based on what I've learned from Try Ruby.  This extension
is written in C and is designed to open a blank symbol table, fill it with the
basic boilerplate and eval a string within that environment.

The extension contains a whitelist of methods and classes to move into the blank
environment.  The code grabs the NODE for each method body and replants the
CFUNC in the sandbox.  Allocators and singletons and all that get copied.

So how does it actually eval the code?  Well, it swaps out rb_class_tbl and all
the rb_(m|c|e)\w+ variables just before eval.  Then, it rb_obj_instance_evals on
an anonymous object (sandbox's `main`) inheriting from the new sandbox->cObject.
I then rb_ensure and swap the normal vars back in.

Here is the code: 

  <http://code.whytheluckystiff.net/svn/sandbox/trunk>

For now, just compile the extension in ext/sand_table/.

  require './sand_table.so'
  p Sandbox.new.eval("'test' + ' strings'")
  p Sandbox.new.eval("Kernel.fork")

I am able to keep the entire sandbox self-contained.  I only have one issue:
I can't replace rb_global_tbl since it is static.  I need it to be extern, is
this possible?

If I cannot replace rb_global_tbl, this leaves an exploit:

  p Sandbox.new.eval("$0.class.ancestors.last.method(:p)")

So the globals can be used to get a handle to the unsafe Kernel.

Thanks for listening!  Any help stabilizing this intrepid effort is welcome, of
course!

_why

In This Thread

Prev Next