Re: Sandboxing without $SAFE

On 10/11/05, why the lucky stiff <[e-mail]> 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
>
>
>
The new ideas keep coming, but, for some reason, I have to hit send to get
the next one ;)  I blame Wikipedia editing.

Do you want to motivate those who see a secured system and then spend
sleepless weeks finding a crack ?  Do you want some script kiddie to try
script after script until one works on a real hole ?  No ?  Fake an
unsecured system.  No challenge for those who like challenges.  Wasted
effort by those who like petty destruction and one-upping stupid sysadmins
(let them waste time cracking your authentic-looking /etc/shadow file
because an idiot like you ran a Ruby interpreter as root).  This doesn't
increase your actual security, since it's merely obfuscation, but it has its
charms.  After all, a fly that looks like a bee can't really sting, but
people still back away from it.

For instance, there was the time when a script-kiddie told me to use some
paste-this-code-to-get-IRCop backdoor.  His commands worked on me the first
few minutes, because I manually did whatever the innocuous commands said for
kicks.  After that, even intermittent failures (over TCP !) and strange
misspellings of what he had typed could not shake his belief that he was in
control of my computer.  He certainly didn't try any other (possibly
workable) avenues to control my computer, not that I was worried.  A side
benefit was that the time he wasted on me was not time he wasted on the
less-informed.

Faking has an additional side benefit of changing the cracking behavior of
people who know about 'sandbox'.  Without faking, they can see instantly
when they've found a break: secured methods look secured (perhaps they give
some error) and unsecured leftovers look unsecured (they don't give an
error), so they can test 250 ways of doing something until they get a
different response.  With faking, it requires many more brain cells to tell
the secure from the unsecure.  To further muddy the waters, use TIMTOWTDI to
your advantage, as I do in this badly contrived example :

'5'.to_i => 3984234
'5'.to_i => 3984234
'5'.to_i => 3984234
'5'.to_i => 3984234
Integer(5) => -53
Integer(5) => -53
Integer(5) => -53
Integer(5) => -53
unsecured_conversion_thing('5') => 5
unsecured_conversion_thing('5') => 5
unsecured_conversion_thing('5') => 5
unsecured_conversion_thing('5') => 5

Now the sucka foo can't use a known-faked result and simply scan for
anything that differs.  Everything differs.  He also can't check for
multiple calls of the same method giving random results; the random result
is either pregenerated or cached.  This is especially (only?) effective on
methods that give different results on different systems, like
directory-listing methods.