Forum: Ruby mod_ruby security

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
88e98c5398a3b4af4d0eaefacf69f8b7?d=identicon&s=25 Parragh Szabolcs (Guest)
on 2007-01-18 17:01
(Received via mailing list)
Hi,
I have a quiestion regarding mod_ruby security, hope someone might help
me out.

Suppose, I have a local user on my server, who has a chroot jail,
scponly web-home folder to upload .rhtml (or .rb) files, that apache
executes by mod_ruby. At the default safe level (=1) he can execute code
like:

% expr = %{File.read(\"/etc/postfix/main.cf\")}
% result = eval(expr)
% puts result

She can see globally readable files on the server while his code is
running in the name of the apache user. The same happens with
"RubySafeLevel 2". With 3 or 4, the user cannot access these files, but
actually he cannot do anything reasonable at all, so that is not really
an option. My question is, can I do something similar to PHP-s
safe_mode, where the running _code_ is jailed into its folder somehow?
Or any other solution?

Thx in advance!
PSz

p.s: changing acces rights of all files is s.g. I don't want to do
(fighting debian file acc.rights policy on hundreds of files) that's why
I like scponly/jailroot
D408048a4f28fdbb19512d032584b29b?d=identicon&s=25 Matteo Cavalleri (Guest)
on 2007-09-25 22:35
(Received via mailing list)
> Fortunatelly many hostings provide mongrel&co for their clients.

thanks for the exhaustive answer :)
97550977337c9f0a0e1a9553e55bfaa0?d=identicon&s=25 Jan Svitok (Guest)
on 2007-09-25 22:44
(Received via mailing list)
On 1/6/07, Matteo Cavalleri <shiva.brahma@tiscali.invalid> wrote:
> question is old but my searches on the web weren't succesful...
[Note: I have not studied mod_ruby internals. I'm building on the
statement that all scripts run in the same interpreter]

There are several things a script can do:

1. call your objects' methods - enumerate all objects (via
ObjectSpace.each_object), methods (via Object#methods) and call
private methods via Object#send. The similar for variables and
constants. Call any code in the context of the object either via
adding new method or using instance_eval

2. modify your classes/objects - the classes are open, trace/debug
your code via set_trace_func and/or rdebug/breakpoint etc.

3. see your source code using __SCRIPT_LINES

4. the other script runs with the same privileges as your script, so
it sees the same files - configs, data, etc.

In summary, the script can do almost anything security-wise.

> anyway... let's suppose I've my brand new application with its database
> class which opens a connection to the db with the correct user and
> password, and a session class wich keeps track of user sessions, login,
> etc. then I put my program on a web hosting service
>
> how should I write my classes so that a malicious script running on the
> same web hosting service can't access my db or get an authenticated
> session by poking with my classes?

This is usually solved by not using mod_ruby ;-) The other way running
your script using webrick/mongrel/mod_fcgi within its own interpreter
and in case of mongrel/webrick reverse proxying them with an optional
load balancer (apache/pond/lighttpd/ngix/...) That way, each script
has its own interpreter running under different user. (From the above
the optimal one seems to be a bunch of mongrels behind something -
apache/pond/... - see mongrel.rubyforge.org)

_why was working on a sandbox that would allow separating code within
one interpreter, but I don't know how far has he got (see
code.whytheluckystiff.net)

Finally something can be done using $SAFE_MODE, although that's not a
fix for all of the above problems.

Problem with the above solutions might be that the webhosting provider
has to install them (unless you have a dedicated host or a VPS).
Fortunatelly many hostings provide mongrel&co for their clients.
This topic is locked and can not be replied to.