[Python-Dev] Adding a builtins parameter to eval(), exec() and import(). (original) (raw)
Victor Stinner victor.stinner at gmail.com
Fri Mar 9 00:26:32 CET 2012
- Previous message: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().
- Next message: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 07/03/2012 16:33, Mark Shannon wrote:
It should also help with sandboxing, as it would make it easier to analyse and thus control access to builtins, since the execution context of all code would be easier to determine.
pysandbox patchs builtins in:
- the caller frame
- the interpreter state
- all modules
It uses a read-only dict with only a subset of builtins. It is important for:
- deny replacing a builtin function
- deny adding a new "superglobal" variable
- deny accessing a blocked function
If a module or something else leaks the real builtins dict, it would be a vulnerability.
pysandbox is able to replace temporary builtins everywhere and then restore the previous state.
Can you please explain why/how pysandbox is too restrictive and how your proposition would make it more usable?
Currently, it is impossible to allow one function access to sensitive functions like open(), while denying it to others, as any code can then get the builtins of another function via f.globals['builtins']._ Separating builtins from globals could solve this.
For a sandbox, it's a feature, or maybe a requirement :-)
It is a problem if a function accessing to the trusted builtins dict is also accessible in the sandbox. I don't remember why it is a problem: pysandbox blocks access to the globals attribute of functions.
Victor
- Previous message: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().
- Next message: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]