From: why the lucky stiff <ruby-core@...>
Date: 2005-11-11T07:36:01+09:00
Subject: Sandboxing without $SAFE

I've been playing with Ruby sandboxing alot over the past several 
weeks.  I've been using remove_const and redefinitions of classes to 
limit Ruby rather than $SAFE.  I want to offer an interpreter which can 
be scripted without needing to learn tainting and still giving the 
ability to `eval'.

Here are the assumptions:
1. The filesystem is chroot'd or, better yet, a virtual filesystem 
implemented in Ruby memory.  (Like MockFS.)
2. Scripts will be monitored for CPU usage and consuming processes will 
be killed.
3. STDERR, STDIN and STDOUT are attached to the user's input and output 
(the browser).
4. The following constants are removed from Object: Continuation, GC, 
ObjectSpace, Process.
5. The following methods are removed or redefined in Kernel: (backtick), 
abort, autoload, autoload?, exec, exit, exit!, getc, gets, fork, load, 
readline, readlines, require, select, syscall, system, test.
6. As a part of #1, the following class are redefined to prevent them 
from accessing the actual filesystem: File, FileTest, Dir, DBM, File::Stat.
7. All communication to the interpreter is done through a UNIXServer 
socket, like this:

   s = UNIXServer.open( socket_path )
  # .. removal of all constants (including UNIXServer), loading of libs
  while true
    Thread.start( s.accept ) do |s|
       if cmd = s.gets
         s.write eval(cmd)
         s.close
       end
     end
   end

It's a bit more complicated than this, but you get the idea.

My questions are three:
1. Are removed constants and methods available elsewhere in the interpreter?
2. Could this be distilled into a general practice, as standard as $SAFE?
3. In general, what am I overlooking?

_why