Creating a capabilities-based restricted execution system

[John Roth]

"Aahz" <aahz at pythoncraft.com> wrote in message
news:bt82d7$ort$1 at panix3.panix.com...
> In article <vveohcpod4oje0 at news.supernews.com>,
> John Roth <newsgroups at jhrothjr.com> wrote:
> >"Aahz" <aahz at pythoncraft.com> wrote in message
> >news:bt7lbp$ovg$1 at panix2.panix.com...
> >> In article <vveg0bb6is2f60 at news.supernews.com>,
> >> John Roth <newsgroups at jhrothjr.com> wrote:
> >>>
> >>>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.
See
> >>
http://dev.zope.org/Wikis/DevSite/Projects/SupportPython21/RestrictedPython
> >
> >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.
[end extract]

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()."

John Roth

> -- 
> Aahz (aahz at pythoncraft.com)           <*>
http://www.pythoncraft.com/
>
> Weinberg's Second Law: If builders built buildings the way programmers
wrote
> 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.