[pypy-dev] PyPy for restricted execution Python
radeex at gmail.com
Thu Aug 19 11:22:22 CEST 2004
On Thu, 19 Aug 2004 10:49:09 +0200, holger krekel <hpk at trillke.net> wrote:
> I think the challenge is to find an easy scheme for doing
> restricted execution in Python. So far it seems that there is
> a lot of complexity involved.
Yes, doing it in an easy way (without the painstaking auditing) is
indeed a challenge, and not really one I'm interested in. Of course, a
lot of the auditing could be shared; i.e., I could come up with a
whitelist that's generally useful and secure in pretty much any
context and so other people wouldn't have to re-audit these functions.
However, the only truly "easy" way is blacklisting (at least this is
how it seems most people think when they think of restricted
execution), but I find blacklisting totally inadequate.
> The specific goal of disallowing File/IO operations and
> restricting memory/cpu usage seems interesting enough to look
> for a specific solution and not for some general scheme of
> dis/allowing object accesses.
*shrug*. Really, what applications is that useful for? Pretty much all
blacklisting schemes I've seen (e.g. disallowing File/IO operations)
have either been boring or still allow access to things I don't want
users to access.
> One basic idea is to be able to allow/disallow the usage of code
> objects according to in which module they live. We then
> wouldn't disallow "import socket" or any other import which
> leads to importing socket but we would say "when i execute
> this function f() here i don't want to execute code that comes
> from the module 'socket'". (Of course you can also have a positive
> list of allowed modules etc.pp.).
> So we would have to keep exact references where code
> originates/was build (mostly 'co_filename') and we would need
> the interpreter to check for these references and some
> policies at certain points. This seems easy enough to do in
Hmm, strange. Well, I still don't think it's relevant to my case; I
doubt I will allow access to *any* stdlib modules in my particular
use-case (which I will explain further down) for restricted-execution.
I will only put very application-specific things in my whitelist.
> We'll see. In some ways PyPy is not that far away from being
> self-contained. FYI, we really have only been hacking for ca.
> 7 sprint weeks so far plus some extra weeks spent by a few
I hope that whatever hacking I do for restricted execution would also
improve PyPy as a general purpose CPython replacement.
> > :-( I'm in the middle of a move and a new full-time job (that has no
> > interest in me researching this subject ;) so I doubt I'll have the
> > time to go to any sprints within the next year, but who knows! Maybe I
> > can organize one in Australia ;-)
> Uh oh, i see. Well then good luck at your new job, anyway. It's not
> even related to Twisted?
Oh, it involves Python, Twisted, and lots of other things I'm pretty
involved with, but unfortunately, not games or restricted execution
;-( I plan on putting almost all of my free time into those two goals
over the coming years, though.
I guess I might as well explain what I really want to do with this
restricted execution: as many do, I want to deploy it in the context
of a multiplayer distributed virtual world where untrusted users
(i.e., free accounts) can add custom behavior to their avatar or the
objects they create. SecondLife has done this in an amazing way (in
that it's the most technologically advanced I've seen today), except
the language they use is crap, it's not open source, and there are
still many flaws. Other older text-based systems (LambdaMOO, IIRC?)
offer scripting to untrusted users as well.
In a slightly different application, the users themselves wouldn't be
able to script their objects, but server administrators (in a
distributed VW) will. If you want a more focused *game* virtual world,
it's pretty impractical to let users script their own stuff (well,
maybe in more limited degrees...). However, it could still be very
useful for distributed worlds (in a network and social sense). For
example, you have server A and server B, run by Bob and Jane... They
want a portal between their servers, and they want to allow users to
bring objects developed by Bob and Jane to each other's server. But
Bob doesn't want users on Jane's machine bringing an Ultimate Sword of
Immense Kitten Slaying onto his server (or an Ultimate Bomb of L33t
/etc/shadow reading, for that matter). So he'll run her code in his
restricted execution environment so they can't read his /etc/shadow or
do more than 5000 points of damage.
2: mostly server-crashing bugs, but I'm sure there are some that can
be used more maliciously.
Twisted | Christopher Armstrong: International Man of Twistery
Radix | Release Manager, Twisted Project
More information about the Pypy-dev