On 08/04/16 16:18, Jon Ribbens wrote: > I've made another attempt at Python sandboxing, which does something > which I've not seen tried before - using the 'ast' module to do static > analysis of the untrusted code before it's executed, to prevent most > of the sneaky tricks that have been used to break out of past attempts > at sandboxes. > > In short, I'm turning Python's usual "gentleman's agreement" that you > should not access names and attributes that are indicated as private > by starting with an underscore into a rigidly enforced rule: try and > access anything starting with an underscore and your code will not be > run. > > Anyway the code is at https://github.com/jribbens/unsafe > It requires Python 3.4 or later (it could probably be made to work on > Python 2.7 as well, but it would need some changes). > > I would be very interested to see if anyone can manage to break it. > Bugs which are trivially fixable are of course welcomed, but the real > question is: is this approach basically sound, or is it fundamentally > unworkable? That one is trivially fixable, but here goes: async def a(): global c c = b.cr_frame.f_back.f_back.f_back b = a() b.send(None) c.f_builtins['print']('broken') Also, if the point of giving me a subclass of datetime is to prevent access to the actual class, that can be circumvented: >>> real_datetime = datetime.datetime.mro()[1] >>> real_datetime <class 'datetime.datetime'> But I'm not sure what good that is.
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