Yay Cookies!

Playing With Fire: Running Uploaded Ruby Code in a Sandbox – David Stevenson

Intro

It is still new, but we will get a chance to interact with it live. There will be a competition to see who can compromise the sandbox first.

The prize is a Cupcake, but he has not bought it yet, because he doesn’t think anyone will break out.

Rules are you must break out of the sandbox itself, not compromise his box or the OS.

Why allow user code?

Say you want to make a decision about which folder to use for a user’s mail? You can write a bunch of complex rules, or you could allow your users to upload code to do it.

He makes a reference to the Neal Stephenson book about the Metaverse, where everyone uploads code.

Second Live also has a C metalanguage which allows players to create their own code and three-dimensional objects. In this type of game, the sky is the limit.

Google’s AppEngine is another example. Users can write their own code and run it in a sandbox, but Google handles all the scalability and hidden bits.

Why not allow user code?

Dangerous operations: Code could have errors, or not finish. Someone will upload an infinite loop almost immediately, you need to deal with it.

Knowledge: Are users programmers? Maybe they don’t want to learn a language, even one as easy and nice as Ruby.

API Manipulation: Maybe there are ways that users could manipulate your API in ways you have not even thought of yet…

What is a sandbox

• Limited functionality
• Can’t break out
• Separate code space
  • There need to be separate code spaces – the user’s space is the “Jungle”
• Bounded execution time

Implementations

Freaky-freaky sandbox gem (MRI ruby): By why the lucky stiff with some contributions from David, written in C. It is a big hack, a bit of a disaster, but it works. We’ll get to play with it.

JavaSand gem (JRuby): Same API as Freaky-freaky, but not as much of a hack. JRuby provides more hooks into the internals, so you can do some of the same things that Freaky-freaky does, but without as much hackery and violation of internals.

Rubinius in the future? – Sub-virtual-machines could be used to create a sandbox, maybe even 20 lines of Rubinius. The C implementation is about 2000 lines.

Lets try it out

Expression Evaluator: 2+2 -> 4, etc.

He is creating the rails application from scratch, hopefully the bandwidth holds up. He’s not using Sinatra, because he doesn’t know how to get something scaffolded fast enough in the time constraints of a presentation.

Some dangerous things are NOT accessible in the sandbox, such as File and Kernel.

require 'test_helper'
require 'redgreen'

class ExprTest < ActiveSupport::TestCase
  test "two plus to equals four" do
    assert_equal 4, Expr.new(:expr => "2 + 2").value
  end
end

class Expr < ActiveRecord::Base
  def value
    Sandbox.safe.eval(expr)
  end
end

He then goes on to implement exception handling (test driven, of course), and also implements code to prevent infinite loops with a timeout.

He then wraps up the coding of the initial app, and he is exposing it to the audience. He has to do the standard rails stuff to make a new app work, delete index.html, set up routes, etc.

http://expr.sandbox.flouri.sh

Now, the fun begins. Here’s some examples that are showing up within a minute:

  Listing exprs
  Expr
  open testfile
  return
  `ls`
  context.freeze
  Dir.entries('.')
  while true; end
  `ls`
  self.instance_eval{while true; end}
  1/0
  `rm -rf ./'
  arr = ['a'] * 0xFFFFFFFFFFFFFFFFFFFFF
  ObjectSpace.count_objects
  p=lambda { 'yo' }; p.call
  `sudo reboot`
  a = 2; a+3
  4*4

  %x[tail log/production.log]
  File.new
  $*
  "HELLO GOGARUCO. YOUR ZIPPER IS DOWN. YES YOU. YEAH, ON THE RIGHT"
  while true; puts 'are we there yet'; end

  New expr

David is now discussing the restricted set of objects in the sandbox. The problem is that you need to reference things like Net::HTTP, but that is not in the set of restricted objects.

The solution is to reference some classes into the sandbox, and copy others. It runs the unsafe things “outside” of the sandbox, but users still cannot access these restricted classes.

Gem Support

• acts_as_wrapped_class
• acts_as_runnable_code
  • Set up the sandbox easily with referenced classes
  • Pass in top level binding and execute code

A Game! Hangman

http://hangman.sandbox.flouri.sh/

# API methods
def word
def guesses
def guess!(char)
def all_words

There is a cron job. Every minute, all the algorithms run, and everyone can make a guess.

Reviewing the attempts to break out of the sandbox

Sorry, no backtick:

   Expr:  `rm -rf ./`

  Value: "#Sandbox::Exception: SyntaxError: (eval):3:in `_eval': compile errorn(eval):3: unterminated string meets end of file"

He then ask if anyone has broken out of the sandbox. NO hands go up. Win! Everyone claps. Great preso!

Aaron starts out with a really bad joke about ‘eyhelp’, which puts him in good standing with me, at least (I like bad jokes).

He’s from Brooklyn, NY, which gets a few woots.

Overview

Most everyone in the audience has used Sinatra. It is “The Classy Web Framework”

You can make a very simple controller, just require ‘sinatra’, and define a simple get to make the most basic app, and you can define routes as well.

There’s been a lot of effort to reorganize the Sinatra codebase. Now there is a base class, and you can define apps which extend Sinatra::Default. He mentions Pat Nakajima’s Rack::Flash for rack and flash message integration.

The nice thing about this is that you can define multiple classes and apps, which allows you to encapsulate things better.

Sinatra is NOT a framework, it is a library

Sinatra is not a framework. Rails is a framework. Rails makes a lot of assumptions about how you will write an app, convention over configuration. It is like a “shelving unit” with places to put everything you need.

Sinatra, on the other hand, is like a wooden board. It is NOT MVC, it is really simple and straightforward.

WDNNSP = “We Don’t Need No Stinkin’ Pattern”

• You can think of it as a DSL for defining routes.
• It is a nicer implementation of Rack.

Aaron would like to remove the idea of Sinatra as a framework, for doing “smaller” Rails app. That works, and you can use something like Sinatra Generator to make small apps. However, he’d like us to think of it as a different way to build apps.

Code First, then Sinatra

We can have our awesome Ruby project, but as an aside, it has Sinatra and can run on the web. You can think about HTTP as a language. It is a protocol, but with REST and other conventions, you can think of HTTP as a way for two apps or distinct pieces of code to talk to each other.

Do you speak HTTP?

It’s up to you, but if you do, then Sinatra is an easy way to do it. One box saying “GET”, and another box giving a “response”.

The first box on the “GET” side is a User (RestClient), and the other box is Rack and Sinatra. Sinatra is really good at handling the box on the “response” side.

The power of the local web

Think of our local computers a place to interact with apps.

Aaron discusses CouchDB now. It has a local interface which lets you interact with it, and it is a simple way to interact with the app, which runs on the web on your local machine.

He’s now describing a scenario with “Jane” in the Accounting department of “Megacorp”. When she needs to run reports, she usually sends them to the developers who have to run them from the command line. Instead, why not just make a simple webapp with a field for Jane to type into and generate her report by herself.

CALLING ALL DEVELOPERS

He would like to see all developers turn their apps into Sinatra web apps – Gems, everything. What if all our gems and code came packaged with web interfaces?

An example of this that he wrote is “Gembox”. It is a simple interface for browsing your gems. 99% of the code is RubyGems, with just a little Sinatra file to present the data via the web. He shows the code layout. The important part just consists of a file which runs the “gem list” command, with some view helpers around it. There’s not a lot of assumptions around the directory tree.

Vegas

“Super Simple Sinatra Starter”.

Vegas is a bin file which wraps your app, and allows you to run it on whatever Sinatra server you have available. It makes it really easy to write and start embedded apps.

The FUTURE!

• Gems + Vegas as a distribution platform

  • It would be cool to have all gems which have web interfaces easily displayed via Vegas, which could have a web interface itself.

• Even easier workflow for mounting

  • You could mount existing apps onto a single running instance, instead of starting a new one for each app

• Vegas as Central Brain

  • Make it easier for local apps to communicate with each other, for example via Growl

• Distribute Tasks across local network

Summary

See more at http://code.quirkey.com

Questions

Q: You showed code: ‘set :sessions, true’. Can you talk more about how sessions work, because they are really complex.
A: This is just a shortcut to including the Rack Sessions middleware in Sinatra. It is based on cookies, but you could write more complicated ones for distributed db sessions, etc.

Q: (from Alex Chaffee) Vegas is cool, but what about the security implications of running on localhost?
A: Yeah, it is insecure. But, you can do really cool things like running the command line. Maybe it could be sandboxed?

The first talk of the conference is by Rich Kilmer on MacRuby & HotCocoa.

He’s starting out by talking about the history of Apply and Ruby. The first time a version of Ruby was shipped with OS X was in 2002: Ruby 1.6.7 was shipped with OS X version 10.2. The next big development was in 2007, when Ruby 1.8.6, RubyGems, RubyCocoa and Rails were shipped with OS X version 10.5. Later this year, SnowLeopard will include Ruby 1.8.7, RubyGems, RubyCocoa and Rails 2.2.

Rich is telling us that one of Apple’s goals is to make OS X the best platform for Ruby developers. Another is to make Ruby a first-class Cocoa programming language on OS X. He hopes that it will become the best Cocoa programming language – a pretty tall order.

RubyCocoa

Now we’re diving into the history of RubyCocoa, by Fujimoto Hisakuni. It first emerged in 2001. It provided a bridge between Ruby and Objective-C. Rich is telling us that the first version of the installer wasn’t great – it managed to delete his entire /Library directory. RubyCocoa first shipped with Leopard. Rich is showing us a RubyCocoa Hello World implementation. Wow, it’s really long – about 20 lines. It’s barely visible to people at the back of the room!

Rich is describing the problems with RubyCocoa. First, it’s a bridge. Second, its messaging syntax is different. Third, Ruby uses green threads. Lastly, you ended up with 2 runtimes and 2 garbage collectors, which caused problems. In a nutshell, you could build apps with RubyCocoa, but probably not large, complicated ones.

MacRuby

Then MacRuby hit the scene. MacRuby 0.4 is built on top of Objective-C 2.0 and Ruby 1.9. Every Ruby class/object/method is an Objective-C class/object/method. That’s great, because you get the dynamism of Ruby with the runtime and speed of Objective C: much better than a bridge.

Now we’re seeing a MacRuby implementation of Hello World. Well, it’s still about the same amount of code. There’s still a lot of code around wiring things together and configuring things.

HotCocoa

And now, enter HotCocoa. Rich is showing us how to refactor the MacRuby Hello World example into HotCocoa. He’s removing lots of code, bit by bit, and looking more and more like plain Ruby. Actually, it’s looking a but Rails-y in places (e.g.

win = window :title => 'hello world', :frame => [0, 0, 200, 60]

He’s down to 7 lines now of pure Ruby. Rich is telling us how a lot of the excitement around HotCocoa is because of its ability to simplify the configuration of your code.

Installing HotCocoa

Rich is giving us a live demo, using HotConsole (available on GitHub), of HotCocoa. HotConsole is written in HotCocoa. He’s running simple Ruby code such as

{}.methods

and how he’s also running code such as

w = window :title => 'hello'
b = button :title => 'push me'

Hey presto, a window pops up with a button labeled “push me” on it. Rich gets a round of applause!

MacRuby Experimental

Rich is going on to talk about MacRuby 0.5. Over Christmas break, Laurent stargin building a new VM for MacRuby, based on LLVM. He already has a functioning replacement for YARV. Other parts of Ruby 1.9 are being replaced with Objective-C code also (such as the garbage collector and built-ins). The JIT is actually just generating machine code, which means it’s really fast: about 4 to 5 times faster than Ruby 1.9 (the goal is to pass them all). It won’t use any libffi for external calls. It’s passing many RubySpecs already. Laurent is also going to make it fully re-entrant and implement fully concurrent threading. His goal is to automatically generate Grand Central code.

All this could lead to some exciting developments, such as, in Rich’s words, the ability to run Ruby on a “small device that runs OS X on a cellular network” :)

We’re out of time for Rich’s talk. He’s suggesting that you go to macruby.org to learn more.

There’s a gig round of applause as Rich leaves the stage. Break time now!

Here’s a couple more pictures of the venue filling up. The Swedish American Hall is a very cool venue. The conference room is upstairs. There is a balcony, and a lot of intricate and beautiful woodwork.

Announcements just started. Josh Susser said this location feels like we are Beowulf waiting for Grendel.

Josh and Leah are making announcements and kicking things off.

There is a great schedule lined up

People are here from everywhere, several people from Europe, including Belarus. Breakfast and beverages were provided.

Justin.tv is also providing a live feed

The first annual Golden Gate Ruby Conference is about to begin!

People are gradually arriving and the hall is filling up. It is a very cool venue, music is playing, good vibe.

There is an expo hall, and we have a spot where we are demoing Pivotal Tracker during breaks and lunch. Swing by and say hi if you are here.

Edward snagged a prime blogging spot at the front of the hall before anyone else arrived:

Stay tuned! Announcements start in a few minutes…

When Leah Silber and I first sat down to talk about putting on Golden Gate Ruby Conference, there were a few things we wanted to do but weren’t sure we could manage given it was our first year and we didn’t know if we could afford everything. The biggest of those things, and the one we get the most questions about, was whether we’d be able to record videos of the presentations. Well, I’m happy to say we’ll be doing just that. Pivotal Labs, already one of our platinum sponsors, stepped up and offered to cover not only the the cost of producing videos of all the sessions but also the hosting of them. This makes me pretty happy, as Pivotal has been recording its own tech talk series for many months and Chris Odell does a great job with the videos.

We also wanted to guarantee there would be good live-blogging of the conference. Often a good blogger can make a big difference in capturing the feel of a conference, but mostly those things just happen by accident. We decided we wanted to help it happen, so we arranged for an official blogger for the conference. Chad Woolley will be leading a team of pivots to chronicle the conference as it happens.

And to top everything off, the conference will be streamed live by justin.tv. Did you know justin.tv was one of the biggest Ruby-powered websites on the internet? Not many people realize that. Anyway, they’ll have someone there covering all the conference presentations and streaming it live. If you’re watching that way, you might want to get on IRC on freenode and follow along on the #gogaruco channel.

That’s a lot of stuff, but there’s only one place you have to go for it all: pivotallabs.com/gogaruco