Re: Sandboxing without $SAFE

C Erler wrote:

>Are there any objects of the forbidden classes (or their subclasses or
>equally-dangerous superclasses) open at all (or maybe redefining the #class
>method would work) ?  For example :
>  puts "Contents of /usr/passwd :\n#{
>$stderr.class.for_fd($stderr.class.sysopen('/usr/passwd')).read(2**16) }"
>IO is just as good as File, so modify it, too.  In fact, modifying it might
>fix File automatically.
>  
>
Yes, this is a danger.  I do replace $stderr, $stdout, $stdin.  Your 
idea of redefining IO methods before removing the IO constant would add 
additional security.

I'm also using ObjectSpace before opening the sandbox to scan for 
lingering objects which are IO or derived from Process, etc.  
(ProcessSubclass.superclass.fork weaknesses, for example.)  And a 
warning appears indicating a count of such issues.

>Best of all would be to neuter the Ruby interpreter so that all operating
>system access functions do nothing and put in we_want_this_to_work__open or
>something for the cases where you definitely want it to work.  It's always
>safer to use a whitelist than a blacklist.
>
This would be ideal, but I think we can do it in pure Ruby.

Thanks for the wealth of ideas.  Recently I've moved the approach to 
configuration of a safe environment on the server, but I'm ready to try 
some new stuff out in the interpreter's end of things.  The code will be 
released soon for further scrutiny.

_why