Running insecure python code

[Noen]

Im developing a game where the players will program their equipment with
python. Are there any ways to run insecure code? I dont want the clients
to mess with the server-code through their own code, or even DOS the box
by using up too much memory.

Here is some examples of how the equipment should be programmed:
---
# Proxmity explosive example

import cpu

explosive = cpu.connection(0x01,"explosive")
motion_detector = cpu.connection(0x02,"explosive")
class Main:
def event_Motion(self):
explosive.trigger(delay=0)

cpu.reg_event(motion_detector.event_Motion, self.event_Motion)
cpu.start()

---
# Broadcast chat equipment

import cpu
import io

terminal = cpu.connection(0x01,"User personal terminal connection")
radio = cpu.connection(0x02,"Radio tranceiver")
mem = cpu.connection(0x03,"Memory chip")
if mem.get("FREQ") == None: freq = 12345 ; mem.store("FREQ",12345)

class Main:
cpu.reg_event(radio.receive, self.event_Message)
cpu.reg_event(terminal.input, self.event_Input)
def event_Message(self,message):
terminal.write(message + "\r\n")
def event_Input(self,data):
if data[0] == "/":
if string.upper(string.split(data[1:]))[0] == "CHANNEL":
radio.setFreq(int(string.split(data)[2]))
mem.store("FREQ",int(string.split(data)[2])
else:
radio.send(data)
---

I see the following problems:
1. looping code
Are there any way to avoid this by checking the "eip" within a usercode?
Is it possible to multiplex between user codes to avoid this?
Is it possible to limit execution speed (set the cpu to 5 instructions
pr second)

2. blocking code / untrusted/insecure code
Is there a effective way to limit the available functions the usercode?
(perhaps like the java securityhandler way)

3. memory-dos
Limiting the storage size (or even forcing the user to store EVERYTHING
in the mem object)


I dont know if this is even possible (without modifying the python
source, which would force me to perhaps seperate server code and user code)

 

[Terry Reedy]

Im developing a game where the players will program their equipment with
python. Are there any ways to run insecure code?

safely, without letting

> clients mess with the server-code through their own code, or even DOS the box
by using up too much memory.

There have been several threads on this topic. Quick answer: nothing as
good as you would want. Stackless, with its tasklets, may be your best bet
once updated to run with 2.3.3.

Terry J. Reedy

 

[Bob Ippolito]

safely, without letting


There have been several threads on this topic. Quick answer: nothing as
good as you would want. Stackless, with its tasklets, may be your best bet
once updated to run with 2.3.3.

Even with stackless, you're not going to be able to stop them from
using "too much memory". Besides, you can't stop a determined and
experienced python hacker from getting ANYTHING (even if it's written
in C)

Stackless 3.0 (Python 2.3.3) compiles and works just fine from CVS
HEAD, and I believe windows binaries are even available. Of course,
documentation is lacking, and we're planning to do quite a bit of stuff
during the sprints next month.. but it's good enough to use if you want
to.

-bob

 

[Noen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob Ippolito wrote:
Perhaps writing a new script language using the builtin parser module
would solve the problems... Any pre-made scripting languages written in
python out in the wild?

| On 2004-02-26 21:21:37 -0500, "Terry Reedy" <[email protected]> said:
|
|>
|> |>
|>> Im developing a game where the players will program their equipment with
|>> python. Are there any ways to run insecure code?
|>
|>
|> safely, without letting
|>
|> > clients mess with the server-code through their own code, or even DOS
|> the box
|>
|>> by using up too much memory.
|>
|>
|> There have been several threads on this topic. Quick answer: nothing as
|> good as you would want. Stackless, with its tasklets, may be your
|> best bet
|> once updated to run with 2.3.3.
|
|
| Even with stackless, you're not going to be able to stop them from using
| "too much memory". Besides, you can't stop a determined and experienced
| python hacker from getting ANYTHING (even if it's written in C)
|
| Stackless 3.0 (Python 2.3.3) compiles and works just fine from CVS HEAD,
| and I believe windows binaries are even available. Of course,
| documentation is lacking, and we're planning to do quite a bit of stuff
| during the sprints next month.. but it's good enough to use if you
want to.
|
| -bob
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAP7kZ9vKlXPxSchIRAnFEAJ9hyB2zj54ZWvm4xyCaXwMk+xeQAQCdGEqB
4uZcunGZf7tO1xqS78QER8Q=
=dFNj
-----END PGP SIGNATURE-----

 

[Bob Ippolito]

You can try looking into PyPy or something. In practice, an
interpreter written in Python is probably going to be far too slow to
be used for any sort of modern game.

You're probably better off just not worrying about the "safety" and
giving them regular Python. When something secure and/or sufficiently
multistate exists, you could migrate.

There is also the possibility of running these user tasks in separate
processes altogether (or in just one) and brokering objects between the
two (i.e. sending pickles, or something more sanitized if you're REALLY
concerned about security). This would let you use operating system
facilities to monitor the resource consumption and would give you the
same kind of security that you have between any two separate processes.
The IDLE IDE actually does something like this for running an
interpreter, and I believe it can even do debugging this way.

-bob

 

[Mark 'Kamikaze' Hughes]

You can try looking into PyPy or something. In practice, an
interpreter written in Python is probably going to be far too slow to
be used for any sort of modern game.

You could translate your more limited scripting language into Python,
and then eval it. This should be reasonably fast, and if you're careful
not to pass unescaped strings from the player through to Python, it
should be secure.

For maximum fun, the limited scripting language should be a subset of
Python.

 

[Bob Ippolito]

You could translate your more limited scripting language into Python,
and then eval it. This should be reasonably fast, and if you're careful
not to pass unescaped strings from the player through to Python, it
should be secure.

For maximum fun, the limited scripting language should be a subset of
Python.

You have to be awfully careful about resource consumption (long
strings, infinite loops, etc)...

It wouldn't be trivial to do correctly, let's leave it at that.

-bob

 

[Mark 'Kamikaze' Hughes]

You have to be awfully careful about resource consumption (long
strings, infinite loops, etc)...
It wouldn't be trivial to do correctly, let's leave it at that.

There are two possibilities. The first is that resource consumption
is irrelevant to your concerns, you just want something that can't 'rm
-rf' your files. If the user runs you out of memory, so what? If the
user eats a lot of CPU time, so what? You kill the app, and it goes
away (if your OS's task switching is so primitive that you can't kill a
CPU-eating app, the problem is not in the scripting language). This is
very easy to provide, and in real scripting applications this is all you
need 99.9% of the time.

The second, which exists only in very theoretical ivory-tower
discussions and will never be found in the wild, is that you do care
about loops, recursion, and memory hogging. Even so, this is a little
harder, but not by much. You check all the strings, you check the range
of all loops, your custom list class checks maximum sizes before
appending, and you don't allow any cycles in function-calling graphs.