Post by Aahz Post by John Roth Post by Aahz
Restricted Python was withdrawn because of a number of holes, of which
new style classes were the last straw.
RestrictedPython was *not* withdrawn; rexec was withdrawn. This is a
difficult enough issue to discuss without confusing different modules.
Post by Aahz Post by John Roth
I'm not sure what you're trying to say. The Zope page you reference
says that they were (prior to 2.1) doing things like modifying generated
byte code and reworking the AST. That's fun stuff I'm sure, but it
doesn't have anything to do with "Restricted Execution" as defined in the
Python Library Reference, Chapter 17, which covers Restricted Execution,
RExec and Bastion (which was also withdrawn.)
If I confused you with a subtle nomenclature difference, sorry. I don't
care what Zope is doing or not doing, except for the fact that it seems
to come up in this discussion. I'm only concerned with what Python is
(or is not) doing. The approach in the Wiki page you pointed to does,
however, seem to be a substantially more bullet-proof approach than
Python's Restricted Execution.
Well, I don't care what you do or don't care about, but I do care that
if you're going to post in a thread that you actually read what you're
responding to and that you post accurate information. If you go back to
the post that started this thread, it's quite clear that the reference
was specifically to Zope's RestrictedPython.
I beg to differ. That's what the OP said he started with, not what he's
mostly interested in nor where he wants to end up. I'm including
the first paragraph below:
[extract from message at head of thread]
I've been playing around with Zope's RestrictedPython, and I think I'm
on the way to making the modifications necessary to create a
capabilities-based restricted execution system. The idea is to strip out
any part of RestrictedPython that's not necessary for doing capabilities
and do all security using just capabilities.
To me, at least, it's clear that while he's *started* with a consideration
of Zope's RestrictedPython, he's talking about what would be needed
in regular Python. If he was focusing on Zope, this is the wrong forum
for the thread.
My fast scan of Zope yesterday showed that it was quite impressive,
but some of the things they did seem to be quite specific to the Zope
environment, and don't seem (at least to me) to be all that applicable
to a general solution to having some form of restricted execution.
Much of this thread has focused on "capabilities" and the use of
proxies to implement capabilities. AFIAC, that's not only putting
attention on mechanism before policy, but it's putting attention on
mechanism in the wrong place.
What I *haven't* seen in this thread is very much consideration of
what people want from a security implementation. I've seen that in
some other threads, which included some ways of taming exec and
eval when all you want is a data structure that contains nothing but
known kinds of objects. You don't, however, need exec and eval
for that if you're willing to use the compiler tools (and, I presume,
take a substantial performance hit.)
One problem I've been playing around with is: how would you
implement something functionally equivalent to the Unix/Linux
chroot() facility? The boundaries are that it should not require
coding changes to the application that is being restricted, and it
should allow any and all Python extension (not C language
extension) to operate as coded (at least as long as they don't
try to escape the jail!) Oh, yes. It has to work on Windows,
so it's not a legitimate response to say: "use chroot()."
Post by Aahz
programs, then the first woodpecker that came along would destroy civilization.
Have to be a pretty non-aggressive woodpecker, if it allowed something
that extensive and complicated to happen before attacking it.