From: Charles Oliver Nutter <headius@...>
Date: 2011-06-11T18:27:51+09:00
Subject: [ruby-core:37023] Re: Object#trust vs Object#taint

On Fri, Jun 10, 2011 at 3:41 PM, Bill Kelly <billk@cts.com> wrote:
> Note, I'm not particularly wedded to the $SAFE
> security model. ��(I have used $SAFE = 1 in a
> few web/CGI scripts.)
>
> What I'd really like is a mechanism in ruby
> that would provide a secure sandbox that could
> contain completely untrusted code.

A quick review of reasons why I don't like $SAFE and tainting.

* When propagating tainting, there are way, way too many things that
could go wrong. A new developer could add code to a minor release of
Ruby and forget to propagate tainting. Suddenly you've got a hole.
* When checking SAFE, there's way, way too many things that could go
wrong. You have to be sure you're checking SAFE in all the right
places, and if anyone modifies that code you have to make sure all
paths check SAFE too.

I don't have a particular problem with the general promises of the
SAFE levels, but I'd like to see them more clearly specified. It ought
to be possible to implement the non-taint-related SAFE restrictions on
any implementation. Tainting and untrust, however, I really don't see
being an effective security mechanism. Not only do you have to be able
to trust that an object's taint/untrust flags are set appropriately,
you have to trust that some piece of code somewhere won't
intentionally or accidentally clear those flags. Security properties
should be under the strict control of the security subsystem, not
floating around as bits on every object in the system.

Java's security policies might not be a bad model to learn from.
There, the security bits are attached to *code* and the context from
which that code is loaded. Objects themselves have absolutely no
security information attached to them (other than being instances of
clases with code loaded from specific contexts), because they're just
data. The security restrictions apply to code executing in constrained
contexts; i.e. if a piece of code is loaded in constrained context X,
it only has access to a set of operations Y. Associating security
restrictions and permissions to executable code keeps those policies
close to behavior, rather than floating around the system attached to
data (as is the case with taint and untrust).

- Charlie