Feature #15344

Being proactive about Ruby security

Added by ioquatix (Samuel Williams) almost 2 years ago. Updated almost 2 years ago.

Target version:


I would like to start a discussion relating to

I don't know what has been done here already. I know from a computability POV, it's impossible to solve this problem.

That being said, it seems like we could do more.

Some parts of this problem relate to tooling (like RubyGems above).

Other parts relate to isolation within the interpreter.

As code bases get bigger, security is more of a concern, both in terms of how users interact with a system, and what they can do.

Dropping all but the necessary privileges is a great way to provide security at the interpreter level.

In BSD, they recently adopted this kind of model:

It might be something which we can incorporate into Guilds.

User can create guild, pledge which APIs should be available, and then load 3rd party code.

Some code does not function well when it is isolated, Ruby often encourages monkey patching. That being said, in many large Ruby applications, business logic could be isolated. Some benefits might include reduced memory usage, improved security, etc. Apple adopted a similar policy with XPC (

For example, it might look like: do

  require 'unstrusted/3rd/party/code`
  Untrusted.all_your_base(are_belong_to_us) # Raise error or SIGABRT.

It would bring more purpose to Guild, not just for scalability, but also reliability, and security.

This is not the only way to solve this problem, I welcome any and all discussion.

Related issues

Related to Ruby master - Feature #8468: Remove $SAFEClosedshugo (Shugo Maeda)06/01/2013Actions

Also available in: Atom PDF