Limiting stackless pythons ability to import

See the __import__() function and the imp module. You can overload __import__() to redefine the semantics of import statement for your purposes.

so something like this:
pseudo code

def My_overloaded_import(name):        if isBlocked(name) == true                mod = __import__(unblocked module)                [...]        else                #do normal stuff here

and i could hard code that in so that only game modules would load?

Quote:

Original post by M_D_K so something like this...

No.

Quote:

def My_overloaded_import(name):

That's not overloaded. Overloaded functions must have the same name. Here's how you do it:

def __import__(name, globals = None, locals = None, fromlist = None, level = None):    # 1. check status of default arguments    # 2. check name of module to be imported: if acceptable...    # 2.1. imp.find_module(), imp.load_module()    # 3 else raise error

Everything I have read has said that CPython cannot be securely sandboxed this way (Stackless is a fork of CPython).

SandboxedPython

How can I run an untrusted Python script safely?

The introspective features of Python have been found able to work around every restricted execution scheme. Jython or IronPython maybe can be sandboxed through their respective VMs, I personally haven't researched that so I can't say for sure how difficult it is. You would have to use some other concurrency framework like greenlet or Kamaelia.

PyPy will be the way to do this in the future. It's not ready for production use yet, but if you're in an experimenting mood: PyPy sandboxing

Thanks for the links. I did some looking and found that overloading __import__ is trivial and a malicious user only has to add a few extra lines to get what he wants.

So i guess i'll explore other options till PyPy is finished. This really sucks cause python could so everything i needed.

Quote:

Original post by M_D_K Thanks for the links. I did some looking and found that overloading __import__ is trivial and a malicious user only has to add a few extra lines to get what he wants. So i guess i'll explore other options till PyPy is finished. This really sucks cause python could so everything i needed.

Why are you trying to limit things in this way, anyway? Why not allow arbitrary module loading?

I'm trying to limit python so that writing malicious code is near impossible, by making so scripts can only load game specific modules.

Quote:

Original post by M_D_K I'm trying to limit python so that writing malicious code is near impossible, by making so scripts can only load game specific modules.

In that case you would probably be better off with a language intended purely for scripting - lua comes to mind and is trivial to sandbox in this way.

Quote:

Original post by M_D_K I'm trying to limit python so that writing malicious code is near impossible, by making so scripts can only load game specific modules.

Impossible. The game is running on the user's computer. Even if you did sandbox the code, what would stop the user from un-sandboxing it? In the context of single-player games there is no such thing as "malicious code". In the context of multi-player games there is very little such thing, and sandboxing your interpreter won't stop it.

Well i've gone back to lua, stated another thread this is why i dropped Lua to start with.

http://www.gamedev.net/community/forums/topic.asp?topic_id=510722

Lua won't keep users from un-sandboxing the VM either.

Quote:

Original post by Sneftel Lua won't keep users from un-sandboxing the VM either.

Given that you are careful in providing functions to the Lua VM, wouldn't un-sandboxing it require hacking the application itself? Lua doesn't have access to raw memory or the filesystem unless you have provided functions to access it.

Ultimately, of course you can't stop the user from doing whatever they desire with their own machine, but if you make it at least a little less than trivial, I think the majority of users wont bother. This comes down to security-through-obscurity, and is ultimately futile, but if it makes you feel warm and fuzzy, why not?

Of course there will always be ways around something, and i'm going to be opening up my engine through scripting. I just want it to be as difficult as possible. Anyway i can't even open my engine more till i fix the error in the link.

"Hacking" this application will be a matter of about ten easy-to-write lines of code. If you're loading any modules, more like five lines. Also, only one person has to do it, and then they'll share the code for it with everyone else.

From looking at it I don't see how a Lua script could un-sandbox itself, if you've stripped out the io, debug and some os functions (by physcially nulling them out in the C code itself). These are the only C hooks which could leak malacious code. If you want to go further u can implement CPU usage control by adding in operator counters to prevent malacious scipts (each within their own Lua thread ) from hogging all the CPU. Just don't let Lua load up random dlls and it seems you'll be ok.

I'm basing this off this wiki article:

http://lua-users.org/wiki/SandBoxes

That's the route I'm taking anywways.

Good Luck!

-ddn

M_D_K isn't talking about preventing the user from hacking his own computer, as Sneftel seems to be suggesting. He is talking about third-party mods. For example if I download an UT mod consisting of UnrealScript files I don't have to trust the author not to screw with my system -- he can't. On the other hand, if I download a Half-life mod consisting of DLL files I understand that it can potentially do anything it wants to my system (especially if I'm running as administrator). M_D_K just wants to allow "untrusted" third-party mods.

Ah, I see. I misinterpreted.

A long time ago, I hacked the real Cpython code in order to limit the import to a specific directory.

Just found where the load is done in Python source ( not as easy done ), and do whatever you want !

Emmanuel