Sandboxing Ruby: The Good, the Bad, and the Fugly
summary
A team builds an online TryRuby/try-rails engine and ships it on Heroku, then finds sandboxing failures and hard-won fixes: a JRuby-based JRuby jail sandbox that isolates namespaces, integrates FakeFS, and enforces per-eval timeouts; a parser-based RubyCop static analyzer (Ripper) that blacklists dangerous calls; a public SandboxBreaker3000 for live attacks. The system handles 1.3 million submissions so far, exposes XSS, resource-exhaustion and thread-kill weaknesses, and shows one exploit is enough to break isolation even when many mitigations exist.
AI-written summary · about
chapters (9)
- 0:00Introduction to sandboxing
- 1:21The Rails for Zombies story
- 4:05Identifying security needs
- 6:40Defining sandboxing criteria
- 9:06The 'Safe' flag and threading
- 13:43Semantic analysis with RubyCop
- 17:48Implementing JRuby isolation
- 22:11Live sandbox competition
- 33:23Conclusion and future outlook
related talks
41mSandboxing Ruby Code - Lessons from the battlefield
36mUsing Ruby In Security Critical Applications
44mRuby Web Application Security Defense in Depth
32mRails Security at Scale
01h 01mLightning Talks
28mQuiet and Versatile Rubyist: Using the Tools You've Got
29mRuby & JVM: A (JRuby) Love Story
38mSpelunking in Ruby