Ruby, SAFE, method interception, and plugins

Hi all,

I am working on an embedded Ruby application that may support
user-written Ruby plugins in the future, and I am trying to get a rough
idea as to what is and isn’t possible, as it will affect the design I go
with. Basically, if you’ve worked on such a thing before, please share
your experiences. :slight_smile:

The ideal in my case is that the app will load in user-written Ruby code
as a plugin, and the plugin author can interact with the rest of the
code via a predefined and restricted set of objects and methods, but
cannot mess with things outside of its environment, and especially not
start exploring outside that environment in any way. I want to be able
to completely lock the user out of using certain objects or classes.

Having not done anything like this in Ruby before, I’m trying to get a
feel as to what might be possible and practical.

For example, many of the criteria in a $SAFE level of 4 seem appropriate
to me- although what I’m really after is a way to lock things up, call
some user code, and then revert back to a normal $SAFE level. It looks
like the only way this could really be done though is to launch the
plugin in its own (Ruby) thread and handle any synchronisation issues
arising from it myself. Is this right?

Being able to set up my own access control by intercepting every method
call made by the plugin would also be useful. I could then, for example,
have a set of testing criteria that I could use on each method call to
determine if it should be allowed (for example, class whitelists). I
wonder if I could set up a series of proxy objects for objects that I’d
like to wrap, but I wouldn’t want a plugin author to use those proxy
classes to get at the original objects, and mess with them directly. The
interface could be as thin as two objects- an application object that
you send messages to, and a plugin base object that the plugin uses to
receive messages from the application. In this case I’d like the user to
be able to create their own classes, manipulate strings and arrays (for
example), but not interact with any of the remaining Ruby code at all,
and certainly not examine it in any way.

As some app users might run plugins other app users have written, being
able to limit the damage they can cause is also important. I’m not
fussed if certain operations could cause a denial of service (eg. just
run “while true; end”), as the environment would be such that the
affected user could just kill the process and disable the plugin- it’s
not a web server. I would be fussed though if the plugin was able to
read and write files to the system directly, or cause lasting damage
outside of the application itself.

As you can tell, my thoughts on the subject are still somewhat
disorganised. I’m trying to determine roughly which parts of this
infrastructure would be easy, difficult, or impossible to implement. I
would greatly benefit from the thoughts and experiences of people who
have been down this road before. If you can find the time, please share
your experiences, and let me know what worked, and what did not.

Thanks in advance, apologies for the long, rambling question. :slight_smile:

Garth

A quick addendum: I forgot to mention that I’m quite comfortable using
Ruby, embedded Ruby, and the like- I just haven’t worked on anything
resembling this problem with Ruby before.

On Dec 18, 2011, at 3:16 AM, Garthy D wrote:

As some app users might run plugins other app users have written, being able to
limit the damage they can cause is also important. I’m not fussed if certain
operations could cause a denial of service (eg. just run “while true; end”), as
the environment would be such that the affected user could just kill the process
and disable the plugin- it’s not a web server. I would be fussed though if the
plugin was able to read and write files to the system directly, or cause lasting
damage outside of the application itself.

I’m not sure that I would want to rely on any language enforced
constraints for executing ‘hostile’ code within the same address space
as my main application. I think a better solution is to run the foreign
code (that sounds nicer) in an external process or even on a completely
separate system and then use some sort of communication scheme to
interact with the foreign code. If the communication scheme is well
defined it also means that the plugin doesn’t have to even be in Ruby.

If you want to run it on the same system but in a different process you
can arrange for the process to be ‘locked down’ in a sandbox or other
restricted environment. The specifics on how to do this are going to be
very dependent on your production environment but perhaps someone will
pipe up with some specific suggestions if you tell us about your
environment.

Gary W.

Hi Gary,

On 19/12/11 10:31, Gary W. wrote:

I’m not sure that I would want to rely on any language enforced constraints for
executing ‘hostile’ code within the same address space as my main application. I
think a better solution is to run the foreign code (that sounds nicer) in an
external process or even on a completely separate system and then use some sort of
communication scheme to interact with the foreign code. If the communication
scheme is well defined it also means that the plugin doesn’t have to even be in
Ruby.

If you want to run it on the same system but in a different process you can
arrange for the process to be ‘locked down’ in a sandbox or other restricted
environment. The specifics on how to do this are going to be very dependent on
your production environment but perhaps someone will pipe up with some specific
suggestions

if you tell us about your environment.

I’ll give it a shot. :slight_smile:

I am developing a cross-platform app, Linux and Windows initially. Using
Ruby code for plugins is extremely desirable as much of the app itself
is already written in Ruby, and I don’t want the users to even have to
consider the platform. Most users would only be using a single platform
anyway, and many plugin authors would be new to Ruby.

From the perspective of a potential plugin, I would be providing the
entire interface- every call that they could need to interact with the
app would be provided. As mentioned, it could be as simple as message
passing between a couple of objects. In fact, I don’t want the plugin to
be able to communicate outside the app, except through the API provided
by the app. This includes networking, filesystem access, and the like. I
would most likely supply a “require” replacement as well, and RubyGems
or existing libraries wouldn’t be directly usable. I would like plugin
authors to be able to use things such as strings, arrays, create an
manage their own custom classes, so forth. I could potentially whitelist
allowed things if I could hook into things at various points.

Plugin authors would generally not be deliberately malicious, because
they won’t be entirely anonymous (as per if it was a online web app, for
example), but it could happen, so I’d like to minimise the interactions
with the external environment as much as possible. Some authors will be
genuinely curious and be looking to explore the rest of the Ruby code
that is running. I specifically want to limit this. A determined
attacker will of course eventually succeed, but I want to make it
difficult.

The app users would be the ones running the plugins. Most wouldn’t be
able to write a line of Ruby to save their lives, let alone understand
plugins as anything more than a magic file they download. Thus, if they
enabled a plugin that executed 99999999**999999999, it might lock the
app up, but they’ll just kill it, restart it, and not use the dodgy
plugin next time. If the plugin was capable of blasting files away from
their filesystem, then there is a problem. Thus maliciousness that
causes an app crash is only a minor problem, maliciousness that deletes
files is a big problem.

As most of the interaction would be in the form of method calls (ie.
plugin calls app, expects a return value, app call plugin, expects a
return value), a separate process for the app would be cumbersome. A
separate thread would be slightly annoying, and in the same thread would
be fine. However, I realise that the closer the plugin gets to the app
in this way, the harder it will be to sandbox. My gut feeling is that
the solution would probably be provided at the (Ruby) thread level.

The current state of the code is that the app is still in development,
but many of the basics are in there. No plugin infrastructure exists
yet, as I’m just starting to explore the possibilities (hence the reason
for my post- I’m trying to figure out the best place to begin). The app
itself is a C++ and embedded Ruby mix, and I’ve worked with both for the
last decade or so. Patching the version of Ruby I am using myself is a
possibility if it helps, as I’m fine building Ruby and potentially
making very small changes. I am using the 1.9 series.

I’m happy answer any questions on specifics if it helps.

Garth

On Sun, Dec 18, 2011 at 2:16 AM, Garthy D
[email protected] wrote:

Hi all,

I am working on an embedded Ruby application that may support user-written
Ruby plugins in the future, and I am trying to get a rough idea as to what
is and isn’t possible, as it will affect the design I go with. Basically, if
you’ve worked on such a thing before, please share your experiences. :slight_smile:

There’s a number of folks using JRuby for this, most notable the
“Rails for Zombies” online course, which runs JRuby in a sandboxed
environment and allows students to run their code directly on the
server.

I am not a fan of $SAFE at all. I don’t trust it, and I don’t think
anyone else should either. The JVM’s security model is far more
robust, and works well to secure a JRuby instance. There are many
examples of secure JVM-based services running major sites, such as all
of apps deployed to Google AppEngine for Java. I know of no example of
anyone running $SAFE mode in Ruby in a real-world setting.

I’m also looking to make JRuby’s integration with the JVM security
model more robust in JRuby 1.7. At the very least, I’d like to have
equivalent built-in modes similar to SAFE levels that use JVM security
policies to enforce restrictions. Beyond that, I would like a full
complement of JVM permissions for Ruby-specific features like
evaluating code, reopening classes, and so on. You’ll be able to
choose a pre-packaged SAFE-like policy, or roll your own.

I’d love to see Ruby adopt a real security model. Until then, I’ll
keep trying to make JRuby utilize the JVM’s model better.

  • Charlie

Garthy D писал 18.12.2011 12:16:

synchronisation issues arising from it myself. Is this right?
I want to note that $SAFE value is set per-thread[1], so you can load
your
plugin into an anonymous namespace (Kernel#load second argument) and
then
spawn a thread from there, using some library (Celluloid[2]?) to
communicate
with the code in it.

I should say that I’m not sure that $SAFE is, well, safe for your
needs, as
I’m not familiar with it at all.

1: http://rxr.whitequark.org/mri/source/safe.c#040
2: https://github.com/tarcieri/celluloid

Hi Charlie,

I have no realm experience with JRuby, although at a glance it might be
a closer fit with respect to securing running plugins. I might be stuck
in this regard though as a good chunk of the app is already written, and
C+±based. The cost of moving across might prove to be too high in my
particular case, but at the very least it gives me something to explore
and think about. Thankyou for sharing- this is probably not an area I
would have thought to investigate on my own. :slight_smile:

Garth

JRuby does support FFI, for calling C libraries, so one approach to
using your existing code would be to write a thin C wrapper and bind
it with FFI.

An alternative would be to write a thin JNI (Java Native Interface)
wrapper and use that from JRuby just like any Java API. The level of
effort would be similar to writing a Ruby C ext.

In any case, keep me posted. If you decide to go with JRuby, perhaps
we can collaborate on coming up with appropriate permissions and
security policies.

  • Charlie

On Sun, Dec 18, 2011 at 8:48 PM, Garthy D

Hi Charlie,

Thankyou for the additional information. :slight_smile: As mentioned there would be
a big cost to moving across to JRuby at this point- but I now have a
much better starting point if I undertook such a move. Thanks for that.
:slight_smile: I wasn’t familiar with FFI, but I’m quite familiar with the problem
they are trying to solve. Very interesting stuff. :slight_smile: There are certainly
other benefits to moving to a JVM-based approach as well- as well as
associated disadvantages. I’ll also assume that’s it’s pretty much a
given that I could use have Java-based plugins as well if I went this
way- and this could very well be a big plus. I’ve certainly got some
things to think about now. :slight_smile:

Garth

I haven’t watched this presentation yet, so obviously can’t comment on
the content, but it does sound like it’s in the right ballpark:

http://confreaks.net/videos/713-rubyconf2011-sandboxing-ruby-the-good-the-bad-and-the-fugly

Hi Mark,

I’ve just finished watching it- thanks for that. :slight_smile: The sort of problem
the presenter was trying to solve is running untrusted web-submitted
code, and has a degree of similarity with the problem I am trying to
solve. I can’t say that I now have a sense of knowing how to solve the
problem entirely, but it was an interesting watch nonetheless. :slight_smile:

Thanks again. :slight_smile:

Garth

Hi Peter,

Thanks for that- that confirms my current (somewhat limited)
understanding of $SAFE thus far. Thanks for the reference to Celluloid,
btw- this might help a bit. :slight_smile:

Garth

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs