As pointed out in another subthread, Python code is practically impossible to sandbox. Most competition isolate player code by running it in a separate process which has the additional benefit of easily allowing different implementation languages.
Making sure the process doesn't use your network to spread malware is not 100% trivial but still easier than sandboxing Python code within Python.
Seccomp might be a possibility here, but will require one process per live robot (and Linux). With seccomp your process can do nothing but read/write from its file descriptors (so you have to make sure they are safe) but can do nothing more (thus you cannot import modules). So you can exchange messages via file descriptors and otherwise use any Python (or even any other language at all features). Here's one recent article about it: http://pythonsweetness.tumblr.com/post/65442885019/secure-lo...
RestrictedPython, used in zope, is nice too. However it cuts you out of many Python features that it cannot statically validate.
turning down your server is not as much fun as cheating.
shameless plug, I have just worked out a JavaScript class loader[1] of Robocode a few week ago. you don't have to turn security off with this class loader, unlike some approaches suggested on RoboWiki[2]. I'm currently trying to get Jython work with Robocode.
I wonder whether modern virtualization techniques are secure enough to allow you to provide unrestricted access to a virtualized OS and allow people complete access to fight for control?
I wasn't born then, but me and my friends implemented a CoreWars 88' standard microprocessor in an FPGA for a school hardware project. It was possible to write code snippets in redcode and then we compiled it and sent it through usb and the FPGA was connected to a screen so we could see the progress.
Not me, but I read about a contest that was similar to this. Unfortunately I can't find a link but the general idea was that people could write worms under a very small size limit and fight for control of memory much like this game.
In the mid or late nineties, I remember playing a game where you wrote autopilot and targeting code in C to control autonomous spaceships that fought against each other in an Asteroids-like 2D universe that ran as a distributed screensaver. It was mostly with people working at Canon Research here in Sydney, but I don't remember if they were the source/writers of it, or if they were just the social scene I discovered it through. (That's where I first learned about Kalmann Filters for predictive aiming, as being discussed in another HN frontage thread.)
I'm having a lot of fun with this. I'll submit something soon. You swallow all exceptions and make the robot guard instead. This is nice, but it makes it hard to develop, because you can't see what went wrong. Here's a way you can modify it to have your exception and eat it too:
You might find this interesting: http://blog.delroth.net/2013/03/escaping-a-python-sandbox-nd... (And before you go "Oh, I've got that blocked"... read it, like, really really read it, not just skim for "one thing I can do to block that stuff", but to see just how many things there are in Python for this sort of hackery. Personally I'd guess the "I blocked double-underscores" would not have slowed them down much.)
Holy shit, that article was brilliant. A few of those tricks I was aware of ( __class__.__class__ ), but crafting code objects? I need to re-read this a few times to properly grok how it works.
Is this python 2 or 3? Your description said that you didn't allow underscores, but if this is python 2, people would still be able to run threads (threads were renamed _thread in python 3).
Same question here. I am a total novice to Python, so it might be a stupid question. When I launch with python2.6 it does not find the RestrictedPython package. If I launch with Python 3.2 then it complains about the "print" syntax.
You might also want to consider using a sandbox/jail such as AppArmor, to prevent the Python (sub)process itself from accessing any resources should those methods fail.
I came across a project called CodeJail, which seems to help configure Python (or other scripting languages) nicely with AppArmor, to help execute untrusted code in a safe(r) manner:
https://github.com/edx/codejail
If you try to run run.py from outside of its directory, it can't import settings.py
Traceback (most recent call last):
File "kit/run.py", line 1, in <module>
import game
File "/home/<name>/robotgame/kit/game.py", line 30, in <module>
settings = SettingsDict('settings.py').d
File "/home/<name>/robotgame/kit/game.py", line 28, in __init__
self.d = AttrDict(ast.literal_eval(open('settings.py').read()))
IOError: [Errno 2] No such file or directory: 'settings.py'
So, has anyone compiled a list of these types of software?
Because it feels like there's some space for i) Something that can run on RPi for youth to learn programming and ii) a bi-monthly competition for HN, with rankings (most victories, smallest code with at least one win etc).
We still have bot challenges, and can easily host something like, with the added advantage of supporting a dozen other advantages, and a truck load of users.
I started my first match. The page were I'm taken keeps saying the match is running and hasn't finished yet. I don't see what could take so much, but it's ok. The problem is that if robot A is fighting against B, in A's profile it'll say it's lost against B, and in B's profile it'll say it's lost against A.
This is happening with all the robots in the warehouse, ("I", which is my robot, and the other two, who are fighting with each other).
It looks like I won. There's no log from the battle, though, so if I had lost I wouldn't know what to improve. In the page for the battle there's just some kind of weird string (http://robotgame.org/match/2)
I've been working on a similar concept off and on for a few years. To avoid all the security problems you're having, I've written a virtual machine that emulates a CPU and 64k of RAM. Instead of submitting code, you submit a 64k memory image of robot byte code.
Every turn of the game involves running a single cycle of the virtual CPU for every robot. Conceptually, the robots have radios and weapons that are controlled via memory-mapped IO in the virtual machine.
Things are slightly more complex than that because you don't want to give the first robot in the cycle an advantage (especially if they're firing lasers at each other), so you have to do each turn in multiple stages (run cycle, resolve real-world effects, update robot sensor state)
I'd LOVE to collaborate with a group of people to get something like this going because I think this would be a great way to introduce kids to programming at a machine level/electrical engineering. If anyone is interested, please send me an email. You can find my address in my profile.
That sounds like the much more fully developed version of what I have that I'd like to get to someday. I'm down for that collaboration thing. Let's get a group started.
The radios you mentioned are something I'd like to have someday. I think what makes games like these cool is the fact that your code controls an army of robots. It's more fun than just having two robots duel it out.
That's what I was thinking too; instead of a one-on-one, what if you could have 10-100 bots that operated with different strategies and worked together? I think it would so cool to have multiple teams of players all competing at once.
Sort of a programmable MMO/RTS, where the fun would be the strategy development and extra-game political aspects.
Where I'm getting hung up is on the exact game mechanics; I want to make it so the simulation runs for a long time, but I don't want a single player or team able to develop an insurmountable advantage. I'm thinking to start you get a robot in a sandbox world where it would gather resources and you could test strategies, and when you're ready you can transport the bot to the real world to compete.
I was writing this in C++ so the memory overhead per robot was just barely over 64k. A server with 8gigs of RAM could run a simulation in memory with about 100,000 bots, periodically saving the game state to disk in case of a failure.
I am working on a marginally similar concept (interface in browser, battles on server) game, but I chose Lua as the scripting language since it is much easier to sandbox. I could not find an effective way to sandbox python for sure, and I am still not 100% on Lua.
I'm not the one you ask for, but I too created a programming game. I thought you might be interested: I used Lua to sandbox the players code. My game allows updating of code during the game is running. The game is split into client/server and it provides a SDL client that can connect to a running game server to show the current state of the game. Players interface with the server using a tcp connection.
I'll post to link to it on HN probably tomorrow (theoretically will be finished then...).
The main difference is you write the AI for one of your units, but that AI is applied to many units, so you must write an AI that can interact with itself.
Why don't you white-list imports? Bare python is to my knowledge pretty safe. simply block all imports short of the ones you know wont cause a security risk.
edit: never mind, just read your security section. I obviously don't know python.
Hey, I think something that would make the experience a lot better would be to incorporate Ace editor into it, so you get a very well-featured editor incase you don’t have easy access to a better-than-<textarea> editor.
Thanks for the idea! Yeah, I'm thinking it would be ideal if eventually there could be some kind of IDE on the site with simulator and all (like on fightcodegame.com).
Is there any way to access the map in the Robot class? For the default map, I can just hardcode it, but if you do intend for a robot to be playable on multiple maps, they'll need some way of knowing which squares are obstacles and spawn points.
Without preserving state between turns, there's no way to figure that information out over time, either.
Sad, I spent two days writing a program I was sure to beat all the rest. Now I won't be able to run it :( Hope you fix the "gaping security holes" soon (whilst keeping the code Python-based), as seriously, I love Python.
Sorry, the games weren't being run for a bit. I was only catching security exception and one game threw some other exception, which crashed the whole process. I restarted it and now it should be working.
Any suggestions for the language? The game and site are written in Python so that seemed most natural, plus it's a high-level language with a simple syntax. I could add more if people wanted though.
The interpreter was specifically designed with the assumption that Embryo scripts would come from untrusted sources. I believe that Enlightenment allows Embryo scripts to be embedded inside of theme files, for example.
wrt to sanboxing/security edx has some open source code for running python code in a sandbox. Though you could just as easily use something like docker.
I realize this is annoying, and ideally I shouldn't even be doing this. It was just a quick hack for the version 1. I'll probably try to run user scripts in something like Docker. Any suggestions would be appreciated.
Docker is a bit overkill; just use what it's built on, Linux containers. `sudo lxc-unshare -s "NETWORK|PID" sudo -u nobody python script.py` will do the trick for you. (all one command--the first sudo to make you root, so you can create a new container; the second sudo to make the user inside the container unprivileged)
You'll need to communicate with the Python script using IPC.
Docker is a clean and thin layer on top of lxc. Not managing lxc instances without it seems like a mistake given portability/reproducability of container management.
- Portability: it's just as portable as lxc, so if you meant portability in the sense of 'well he could use it on FreeBSD if he wants to switch from Linux' I don't think there's a win there. If you mean that his containers won't depend on the environment used to spawn them, I guess I don't think that's so important. I always make sure my environments are easily reproducible, and I am happy to reap the reward of that--the reward being that I can do 'unportable' things and not have to worry. Instead of running the environment you want in a container, why not just run it normally and skip that step?
- Reproducibility: see last point. If he wants reproducibility, he can shove that one-liner in a script somewhere and call it.
All he wants to do is isolate a process. You don't need a chroot for that, or service discovery, or lifecycle managment, or a Dockerfile, or whatever else. It's like if someone advocated the use of a 'grep manager' instead of just running grep. The simplest possible thing to do is unshare the namespaces he wants to isolate from harm. So I suggested exactly that.
EDIT: also re portability, it sounds like the rest of his environment depends on these Python scripts anyway, so I don't think he'd gain anything from being able to use them in a different environment.
