[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
Jon Ribbens
jon+python-dev at unequivocal.co.uk
Mon Apr 11 22:00:29 EDT 2016
On Tue, Apr 12, 2016 at 01:08:36PM +1200, Greg Ewing wrote:
> Jon Ribbens wrote:
> >So far it looks like blocking "_*" and the frame object attributes
> >appears to be sufficient.
>
> Even if your sandbox as it currently exists is secure, it's
> only an extremely restricted subset.
I'm not sure what you think the restrictions are, but yes a highly
restricted Python that was secure would be very useful sometimes.
> You seem to be assuming that if your technique works so far, then it
> can be extended to cover a larger subset, but I don't think that's
> certain.
No, I'm not assuming that.
> One problem that's been raised is how to prevent untrusted
> code from monkeypatching imported modules. Possibly that
> could be addressed by giving the untrusted code a copy of
> the module,
Yes, that's what it does.
> but I'm not entirely sure -- accidentally importing two copies of
> the same source file is a well-known source of bugs, after all.
I'm not sure what you mean by that.
> A related, but more difficult problem is that if we allow
> the untrusted code to import any pure-Python classes, it
> will be able to monkeypatch them. So it seems like it will
> need its own copy of those classes as well
Yes, that's also what it does.
> -- and having two copies of the same class around is *another* well
> known source of bugs.
I'm not sure what you mean by that either.
More information about the Python-Dev
mailing list