Re: Sandboxing without $SAFE

why the lucky stiff wrote:
> 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?

In general, this may be unnecessary work. If you run Ruby in a chrooted
environment with minimal tools and as an unprivileged user with all
proper permissions set, it is fairly safe. The failpoints, then,
would be any other applications in that chrooted environment,
accessed through system() and so on.

Well, with a sane chroot program at any rate.


> _why

E