From: "spatulasnout (B Kelly)" <billk@...>
Date: 2013-06-02T21:15:03+09:00
Subject: [ruby-core:55252] [ruby-trunk - Feature #8468] Remove $SAFE


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/