[#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

Re: Sandboxing without $SAFE

From: C Erler <erlercw@...>
Date: 2005-11-23 11:42:19 UTC
List: ruby-core #6752
On 10/11/05, why the lucky stiff <ruby-core@whytheluckystiff.net> 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?
>
> _why
>
>
> Oh yeah, I forgot.  Use defense in depth.

Don't just remove all the ways to get a handle to, say, ObjectSpace, also
remove any special abilities ObjectSpace has so that, even if they find a
way to get ObjectSpace, ObjectSpace.each_object does absolutely nothing.

Make an object of each class (ObjectSpace#each_method allows specifying a
class) with no methods except a method_missing that hangs the interpreter
(and thwaps other running threads so that they can't, in parallel, skip your
trap, perhaps by REALLY hanging the interpreter) so that, even if they get
through your first two lines of defenses and get a handle to the 'destroyed'
each_object method, they have a good chance of hanging the interpreter when
they try to find an object, like GC, that you've hidden.

Destroy their abilities not just on the hard, outer shell, but inside as
well.

In This Thread