On Mon, Apr 11, 2016 at 08:35:11AM -0700, Nikolaus Rath wrote: > On Apr 11 2016, Jon Ribbens <jon+python-...@unequivocal.co.uk> wrote: > >> What I see is that you asked to break your sandbox, and less than 1 > >> hour later, a first vulnerability was found (exec called with two > >> parameters). A few hours later, a second vulnerability was found > >> (async generator and cr_frame). > > > > The former was just a stupid bug, it says nothing about the viability > > of the methodology. The latter was a new feature in a Python version > > later than I have ever used, and again does not imply anything much > > about the viability. > > It implies that new versions of Python may break your sandbox. That > doesn't sound like a viable long-term solution.
That is obviously always going to be true of major new versions with major new features, no matter what language we're talking about or what method is being used to sandbox - unless the sandboxing were to be built in to the language itself, which I have deliberately not suggested. But having said that, I already pointed out in the message you're responding to that with the method I'm using now, coroutines would not have been an issue even if I hadn't specifically fixed them. > > I think now I've blocked the names of frame > > object attributes it wouldn't be a vulnerability any more anyway. > > It seems like you're playing whack-a-mole. Well, no, quite the opposite in fact. If that was true then I would have given up already as the method having been proved useless. So far it looks like blocking "_*" and the frame object attributes appears to be sufficient. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
