https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112018-11-27T03:06:47ZRuby Issue Tracking SystemRuby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=752062018-11-27T03:06:47Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Project</strong> changed from <i>Ruby master</i> to <i>14</i></li><li><strong>Backport</strong> deleted (<del><i>2.4: UNKNOWN, 2.5: UNKNOWN</i></del>)</li></ul><p>At first glance this topic is a bit vague. I like how <code>unveil(2)</code> works, but honestly I have no idea if adopting that way prevents dominictarr/event-stream issue.</p>
<p>So at the starting point: may I ask your goal of this thread? Do you want to prevent future dominictarr/event-stream? Or you want to introduce <code>unveil(2)</code>-like mechanism into the core? These two might or might not be closely related.</p>
<hr>
<p>Regarding "what has been done here already" part. Ancient versions of ruby had a feature called <code>$SAFE</code>. It was somewhat similar to what unveil system call is trying to achieve. In stone age when everyone invoked <code>ruby(1)</code> via CGI, it was very important for CGI hosting companies to prevent their customer-created CGI scripts doing something evil.</p>
<p>Years passed. What turned out to be difficult about <code>$SAFE</code> was that sandboxing done in a userland process can hardly properly work. There are simply so many entry points to cover, and 3rd-party C extensions are almost completely unable to censor before using. We (mainly matz) had considerable efforts making the mechanism sane, and eventually gave up. The raise of Rails drastically decreases the needs of CGI. Running customers' scripts inside of hosting provider's machine is not a realistic story these days. People run codes they write on their machine. Ruby's <code>$SAFE</code> feature shrunk to what it is now and expected for removal in a long term future.</p>
<hr>
<p>That being said, perhaps the situation may be changing again. There are so many gems to use, depending on each other. It is practically impossible to completely understand what they do before actually using them. I understand the needs of protection from malicious activities -- not by your customers, but by some unknown gem authors. It would definitely be better for us to provide such thing if any. The history shows, through, that designing such thing is challenging, at the very least.</p>
<p>Further reading: <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Remove $SAFE (Closed)" href="https://redmine.ruby-lang.org/issues/8468">#8468</a></p> Ruby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=752082018-11-27T03:07:05Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/8468">Feature #8468</a>: Remove $SAFE</i> added</li></ul> Ruby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=752092018-11-27T04:06:17Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p>From <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a>: <a href="http://ruby.11.x6.nabble.com/ruby-core-26388-suggestion-gems-ruby-lang-org-tt3595295.html" class="external">http://ruby.11.x6.nabble.com/ruby-core-26388-suggestion-gems-ruby-lang-org-tt3595295.html</a></p> Ruby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=752102018-11-27T04:10:14Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/10">@shyouhei (Shyouhei Urabe)</a> Thanks for updating this issue correctly.</p>
<p>Thanks for providing some background on <code>$SAFE</code>.</p>
<p>I think the goal should be ensuring Ruby has the tools and processes in place to minimise issues like the ones facing NodeJS. Whether this is just policy level changes as suggested by <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a> (e.g. having an officially sanctioned list of gems vs development gems) or involves code changes (e.g <code>$SAFE</code>) or both, is really something I can't answer.</p>
<p>That being said, there are various different approaches to sandboxing that exist outside the scope of Ruby and they might be worth investigating. For example in the case of malicious gems accessing users personal files, sandbox could help.</p>
<p>On the other hand, gems which load code in-process could access form submission including credit card details, require a different approach, e.g. isolation of critical and non-critical parts of code.</p> Ruby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=757322018-12-16T21:52:10Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul> Ruby master - Feature #15344: Being proactive about Ruby securityhttps://redmine.ruby-lang.org/issues/15344?journal_id=955362021-12-23T23:40:34Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Project</strong> changed from <i>14</i> to <i>Ruby master</i></li></ul>