PL/PythonU

Hi All:

This is an off-shoot of the "Do we really want to migrate plproxy and
citext into PG core distribution?" thread.

On the way home from PyOhio, I had a conversation with a few people
that use Zope a lot. I happened to mention that Postgres doesn't have
an untrusted version of pl/python and they were curious as to why.
They directed me to Zope's Restricted Python implementation [1][2]. In
doing some research, I found the "Pl/Python -- current maintainer?"
[3] thread from 2006. I also found this [4] thread on the python-dev
mailing list.

Hannu: You had mentioned bringing pl/python up to the level of some of
the other pl's. Have you thought any more about pl/pythonu?

David Blewett
------------------
A few quotes from the python-dev thread (links at bottom):
"Here is some context for Python-Dev.

RestrictedPython is a custom Python compiler that, when combined with a
restricted environment, provides a sandbox safe enough to allow
partly-trusted people to write and execute scripts on a Zope server. It
has been used in Zope 2 for a long time and will have a future in Zope
3. The sandbox is more extensive than what the rexec module provides.

The safety of RestrictedPython has been validated in a somewhat formal
process with Python 2.4. Ranjith is working to validate it with Python
2.5." -- Shane Hathaway [5]

"No, he means the restricted Python compiler and capability-proxy
system used by Zope. You know, the one I always bring up whenever
anybody says they want to implement capabilities in Python? ;-)

Zope's restricted Python is basically a combination of a special
compiler, __builtin__ replacements, and a proxy type. Instead of
using LOAD_ATTR opcodes, the compiler generates code that calls a
special getattr() function instead, and most objects other than
relatively-safe builtin types are wrapped in proxies that control
what attributes can be accessed and what operations can be performed.

The restricted Python framework itself doesn't impose any particular
security policy; proxies delegate checks to "checker" objects that
are essentially capabilities. Mostly, it focuses on creating a safe
sandbox that can be expanded." -- Phillip J. Eby [6]

1. http://svn.zope.org/RestrictedPython/trunk/
2. http://svn.zope.org/zope.security/trunk/src/zope/security/untrustedpython/
3. http://archives.postgresql.org/pgsql-hackers/2006-02/msg01036.php
4. http://mail.python.org/pipermail/python-dev/2008-July/081340.html
5. http://mail.python.org/pipermail/python-dev/2008-July/081412.html
6. http://mail.python.org/pipermail/python-dev/2008-July/081347.html

On Mon, 2008-08-04 at 13:08 -0400, David Blewett wrote:
> Hi All:
>
> This is an off-shoot of the "Do we really want to migrate plproxy and
> citext into PG core distribution?" thread.
>
> On the way home from PyOhio, I had a conversation with a few people
> that use Zope a lot. I happened to mention that Postgres doesn't have
> an untrusted version of pl/python and they were curious as to why.
> They directed me to Zope's Restricted Python implementation [1][2]. In
> doing some research, I found the "Pl/Python -- current maintainer?"
> [3] thread from 2006. I also found this [4] thread on the python-dev
> mailing list.
>
> Hannu: You had mentioned bringing pl/python up to the level of some of
> the other pl's. Have you thought any more about pl/pythonu?

My recollection of old times (about python v. 1.6) was that the
restricted sandboxes had some fatal flaws. I have not followed zope's
RestrictedPython enough to have an opinion on its safety.

> David Blewett
> ------------------
> A few quotes from the python-dev thread (links at bottom):
> "Here is some context for Python-Dev.
>
> RestrictedPython is a custom Python compiler that, when combined with a
> restricted environment, provides a sandbox safe enough to allow
> partly-trusted people to write and execute scripts on a Zope server. It
> has been used in Zope 2 for a long time and will have a future in Zope
> 3. The sandbox is more extensive than what the rexec module provides.
>
> The safety of RestrictedPython has been validated in a somewhat formal
> process with Python 2.4. Ranjith is working to validate it with Python
> 2.5." -- Shane Hathaway [5]

Will definitely look at it. Thanks.

> "No, he means the restricted Python compiler and capability-proxy
> system used by Zope. You know, the one I always bring up whenever
> anybody says they want to implement capabilities in Python? ;-)
>
> Zope's restricted Python is basically a combination of a special
> compiler, __builtin__ replacements, and a proxy type. Instead of
> using LOAD_ATTR opcodes, the compiler generates code that calls a
> special getattr() function instead, and most objects other than
> relatively-safe builtin types are wrapped in proxies that control
> what attributes can be accessed and what operations can be performed.
>
> The restricted Python framework itself doesn't impose any particular
> security policy; proxies delegate checks to "checker" objects that
> are essentially capabilities. Mostly, it focuses on creating a safe
> sandbox that can be expanded." -- Phillip J. Eby [6]
>
> 1. http://svn.zope.org/RestrictedPython/trunk/
> 2. http://svn.zope.org/zope.security/trunk/src/zope/security/untrustedpython/
> 3. http://archives.postgresql.org/pgsql-hackers/2006-02/msg01036.php
> 4. http://mail.python.org/pipermail/python-dev/2008-July/081340.html
> 5. http://mail.python.org/pipermail/python-dev/2008-July/081412.html
> 6. http://mail.python.org/pipermail/python-dev/2008-July/081347.html

Hannu Krosing wrote:
> On Mon, 2008-08-04 at 13:08 -0400, David Blewett wrote:
>> Hi All:
>>
>> This is an off-shoot of the "Do we really want to migrate plproxy and
>> citext into PG core distribution?" thread.
>>
>> On the way home from PyOhio, I had a conversation with a few people
>> that use Zope a lot. I happened to mention that Postgres doesn't have
>> an untrusted version of pl/python and they were curious as to why.

Personally I'm also constantly mentioning it :-)

>> They directed me to Zope's Restricted Python implementation [1][2]. In
>> doing some research, I found the "Pl/Python -- current maintainer?"
>> [3] thread from 2006. I also found this [4] thread on the python-dev
>> mailing list.
>>
>> Hannu: You had mentioned bringing pl/python up to the level of some of
>> the other pl's. Have you thought any more about pl/pythonu?
>
> My recollection of old times (about python v. 1.6) was that the
> restricted sandboxes had some fatal flaws. I have not followed zope's
> RestrictedPython enough to have an opinion on its safety.

Yes, the old sandbox (restricted execution and bastion) used a
realatively naive approach of basically limiting only imports and iirc.
some file access objects.
That beeing not really bullet proof so these modules have been
removed. This should not be confused with the different approach
restricted python uses and which proofes to be successfull to date.

Regards
Tino