[#55222] [ruby-trunk - Feature #8468][Feedback] Remove $SAFE — "shugo (Shugo Maeda)" <redmine@...>

20 messages 2013/06/01

[#55260] [ruby-trunk - Feature #8478][Open] The hash returned by Enumerable#group_by should have an empty array for its default value — "phiggins (Pete Higgins)" <pete@...>

8 messages 2013/06/02

[#55276] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation — Tanaka Akira <akr@...>

2013/5/31 zzak <ko1@atdot.net>:

9 messages 2013/06/03

[#55306] [ruby-trunk - Feature #8490][Open] Bring ActiveSupport Enumerable#index_by to core — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>

12 messages 2013/06/04

[#55330] [ruby-trunk - Feature #8499][Assigned] Importing Hash#slice, Hash#slice!, Hash#except, and Hash#except! from ActiveSupport — "mrkn (Kenta Murata)" <muraken@...>

30 messages 2013/06/06

[#55391] [ruby-trunk - Bug #8507][Open] Keyword splat does not convert arg to Hash — "stephencelis (Stephen Celis)" <stephen.celis@...>

16 messages 2013/06/09

[#55393] [ruby-trunk - Bug #8508][Open] Invalid byte sequence in UTF-8 (ArgumentError) in win32/registry.rb — "thasmo (Thomas Deinhamer)" <thasmo@...>

11 messages 2013/06/09

[#55528] [ruby-trunk - Bug #8538][Open] c method not pushed into the callstack when called, but popped when returned — deivid (David Rodríguez) <deivid.rodriguez@...>

9 messages 2013/06/17

[#55557] [ruby-trunk - misc #8543][Open] rb_iseq_load — "alvoskov (Alexey Voskov)" <alvoskov@...>

47 messages 2013/06/19

[#55558] [ruby-trunk - Feature #8544][Open] OpenURI should open 'file://' URIs — "silasdavis (Silas Davis)" <ruby-lang@...>

12 messages 2013/06/19

[#55580] [CommonRuby - Feature #8556][Open] MutexedDelegator as a trivial way to make an object thread-safe — "headius (Charles Nutter)" <headius@...>

19 messages 2013/06/21

[#55596] [ruby-trunk - Feature #8563][Open] Instance variable arguments — "sawa (Tsuyoshi Sawada)" <sawadatsuyoshi@...>

18 messages 2013/06/22

[#55638] [CommonRuby - Feature #8568][Open] Introduce RbConfig value for native word size, to avoid Fixnum#size use — "headius (Charles Nutter)" <headius@...>

18 messages 2013/06/24

[#55678] [ruby-trunk - Feature #8572][Open] Fiber should be a Enumerable — "mattn (Yasuhiro Matsumoto)" <mattn.jp@...>

13 messages 2013/06/28

[#55699] [ruby-trunk - Feature #8579][Open] Frozen string syntax — "charliesome (Charlie Somerville)" <charliesome@...>

20 messages 2013/06/29

[#55708] [ruby-trunk - Bug #8584][Assigned] Remove curses — "shugo (Shugo Maeda)" <redmine@...>

17 messages 2013/06/30

[ruby-core:55252] [ruby-trunk - Feature #8468] Remove $SAFE

From: "spatulasnout (B Kelly)" <billk@...>
Date: 2013-06-02 12:15:03 UTC
List: ruby-core #55252
Issue #8468 has been updated by spatulasnout (B Kelly).



spatulasnout (B Kelly) wrote:
>
> What I'd really like is a mechanism in ruby
> that would provide a secure sandbox that could
> contain completely untrusted code.

To clarify:

I'd say our application treats the difference between
$SAFE == 4 and $SAFE <= 1 as somewhat similar to the
boundary between to 'privileged mode' and 'user mode'
on a CPU.

The functionality on which we depend includes:

- user-mode (sandboxed) code is restricted:
  - can't modify/extend existing classes & modules
  - can't perform I/O
  - can't modify global or thread-local variables or environment

- user-mode code MAY transition to privileged-mode
via a "trap" (i.e. calling a block that was compiled
in a privileged context.)

Now, if something like the JVM provides a more granular
permission structure, that sounds potentially great.

But if we could at least just begin with the most
restrictive possible sandbox, and then allow a
trap to a privileged context (via calling a proc
compiled at a privileged level,) my hope is such a
thing could be accomplished without some of the
complexity attributed to current $SAFE handling:

headius (Charles Nutter) wrote:
>
> [$SAFE] is blacklisting, which is almost impossible to do without
> leaving gaps. EVery new API needs to enlist in the blacklisting,
> every change needs to be aware of it, and if you don't choose the
> right safe level or one piece of code isn't aware of it, you've
> got a hole.

It would indeed seem ideal to require, for any
Ruby VM, that the default for any newly defined
native extension function is to enforce requiring
privileged execution -- such that the simplest path
for anyone coding a ruby extension is to define
functions that the VM will only execute in a
privileged context.

It shouldn't be that "every new API" needs to
enlist in the blacklisting.  Every new pure Ruby
API shouldn't need to do anything; it's either 
being executed in a privileged context or it isn't.

It's only the native extensions that need to be
specially attended to; and if they can default to
requiring privileged execution unless explicitly
marked as sandbox-safe by the author, then it 
seems to me we'd be in pretty good shape?


Regards,

Bill


----------------------------------------
Feature #8468: Remove $SAFE
https://bugs.ruby-lang.org/issues/8468#change-39646

Author: shugo (Shugo Maeda)
Status: Feedback
Priority: Normal
Assignee: shugo (Shugo Maeda)
Category: core
Target version: current: 2.1.0


Yesterday, at GitHub Tokyo drinkup (thanks, GitHub!), Matz agreed to remove the $SAFE == 4 feature from Ruby 2.1.
Shibata-san, a developer of tDiary, which is the only application using $SAFE == 4, also agreed to remove it, so today is a good day to say goodbye to $SAFE (at least level 4).

Furthermore, I'm wondering whether $SAFE should be removed entirely, or not.
Is there anyone using $SAFE?


-- 
http://bugs.ruby-lang.org/

In This Thread