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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4