On Oct 21, 2008, at 8:29 AM, Chris Withers wrote:
> Sidnei da Silva wrote:
>>> I always was under the impression that Jim feared the code and the
>>> required security audit was perceived as a major painful
>> That was my perception too. But after looking at the code it is
>> not bad at all.
> The PyPy guys, who seem to be the authority on this kind of stuff,
> always shake their heads in woe at the mention of RestrictedPython.
As well they should. Relying on it is a lot of work and brittle.
> I've tried to understand what they perceive the "real problems" with
> to be but haven't managed to extract anything meaningful :-(
The problem is that it it starts with an environment in which things
are allowed by default, and takes things away. This means that if
anything is forgotten, then you end up with holes.
A better approach is to start with something that lets you do nothing
and add capabilities that are known to be safe. This is why some
folks get all excited about capability-based security.
The Zope 3 security proxy approach is much better than relying solely
on restricted Python, because, as with a capability-based approach, it
prevents what isn't explicitly allowed. It does this (for the most
part) without having
to do code manipulation. It still uses restricted Python do deal in a
narrow way with basic objects, like strings and numbers, that are
unproxied. It's use of restricted Python is so narrow that it is far
less problematic. It would be really great if Zope 2 would switch to
security proxies, although the transition is likely to be painful.
I'm not sure that the PyPy guys are really authorities on the sorts of
problems we're trying to address, although there is some overlap. If
I remember correctly, they are just focussed on protecting the system
from untrusted scripts. Our problem is harder because we also want to
protect objects available to the scripts.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -