[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>

Hi folks,

14 messages 2005/11/19

[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...

Bugs item #2858, was opened at 2005-11-20 16:35

13 messages 2005/11/20

[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>

Hi all,

81 messages 2005/11/21
[#6685] Re: semenatics of if/unless/while statement modifiers — Mauricio Fern疣dez <mfp@...> 2005/11/22

On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:

[#6686] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Mauricio Fern疣dez wrote:

[#6687] Re: semenatics of if/unless/while statement modifiers — Eric Hodel <drbrain@...7.net> 2005/11/22

On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:

[#6689] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Eric Hodel wrote:

[#6693] Re: semenatics of if/unless/while statement modifiers — Yukihiro Matsumoto <matz@...> 2005/11/22

Hi,

[#6695] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Yukihiro Matsumoto wrote:

[#6718] Re: semenatics of if/unless/while statement modifiers — mathew <meta@...> 2005/11/22

[#6722] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

mathew wrote:

[#6707] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6708] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6714] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6717] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>

Hi,

37 messages 2005/11/30

Sandboxing without $SAFE

From: why the lucky stiff <ruby-core@...>
Date: 2005-11-10 22:36:01 UTC
List: ruby-core #6604
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


In This Thread

Prev Next