[pypy-dev] PyPy for restricted execution Python
radeex at gmail.com
Thu Aug 19 12:30:59 CEST 2004
On Thu, 19 Aug 2004 11:57:33 +0200, holger krekel <hpk at trillke.net> wrote:
> 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?
Yeah, there would be a sizeable API. But the access would be very
carefully moderated and hand-picked. This is really the hard project;
I think implementing the r-exec system at the core is much easier than
doing the actual API design and auditing.
> 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):
Hmm, no I haven't. *just skimmed* Did he actually write a sandbox that
allows untrusted python code to run securely? I was under the
impression that running Python code with CPython's runtime securely is
an absolutely futile idea. I'll try to grab kapil on IRC.
> 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.
That would be cool, but it seems pretty hard (well, maybe in a few
more years of computing power advancement ;), and I think it's
acceptable to only use a limited pool of UMLs that run multiple users'
code. Here's why.
An important distinction to make is that between host and simulation
security; r-exec is still absolutely necessary even if you have a UML
for each script. r-exec *can* protect both the host and the
simulation. Of course, it's probably a good idea to keep a UML or
whatever as an extra layer of security, for the same reason that you
run various system daemons under chroots. For simulation-security,
though, a UML won't help; you still need to carefully restrict every
capability you give to the user (so that he can't use a python object
system trick to gain a reference to someone three rooms over and hit
them with his sword).
Twisted | Christopher Armstrong: International Man of Twistery
Radix | Release Manager, Twisted Project
More information about the Pypy-dev