[pypy-dev] PyPy for restricted execution Python
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
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