[pypy-dev] PyPy for restricted execution Python

holger krekel hpk at trillke.net
Thu Aug 19 11:57:33 CEST 2004

[Christopher Armstrong Thu, Aug 19, 2004 at 05:22:22AM -0400]
> On Thu, 19 Aug 2004 10:49:09 +0200, holger krekel <hpk at trillke.net> wrote:
> > 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
> > PyPy.
> 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.

Maybe you could put those application specific things into a module 
and whitelist it using the above scheme. 

> 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. [...]

Ah, now it gets interesting! :-) 
> 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.

I begin to see.  Wouldn't you need quite a lot of access to the
gaming application code if you want to give users freedom to script
their objects? 

Btw, have you looked at zope3's security model?  Kapil Thangavelu has 
written a nice readme file (with an example of distributed agents moving 
between sandboxes where they have different access capabilities): 


I have to admit that if i would go for the "scripting within
games" goal i probably wouldn't go for neither of the above.
I'd probably think more about kernel-level sandboxes and using
unix permissions or posix-acls for file accesses (if any) and a
pipe to a VW server to communicate actions and events (with
its own security/sanity checks). 

Hum, maybe there would be a nice application for a (user-mode)
linux-kernel and a lean PyPy on top of it with no c-libraries
involved whatsoever as this could reduce memory/resource usage
to a degree where granting "free accounts" is cheap enough. 



More information about the Pypy-dev mailing list