On Mon, 27 Feb 2023 at 06:02, python--- via Python-ideas <python-ideas@python.org> wrote: > > I override the import mechanism in cpython, so yes, the __import__ function > is also accounted for.
Okay, cool. (Like I said, I didn't feel like wading through >1000 commits to find out exactly what you'd changed.) > The sys.modules was something I had not considered, that's a good point. I > will have to look into it. Once something's been imported, it becomes VERY easy to access. Blocking sys.modules would make it a bit harder, but thanks to tricks like object.__subclasses__, it'll be a massive game of whack-a-mole. > I am not sure how arbitrary code execution will be able to use native APIs > without importing them. The question is whether there's a way for something to cause some other subsystem to import a module, thus bypassing the restrictions and making it available via tricks like I mentioned above. I don't know of any way off-hand, but I also know that there are a *lot* of ways to cause code to be called upon from elsewhere, so it would depend heavily on exactly what your boundaries are. Even if the boundary is something like "if this module is in the call stack, importing is disallowed", it would be possible to bypass it, for instance by spinning off a new thread to do the import. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JVQ7JZX3TK2RY7E2SCKEWM2EEZYTPBQH/ Code of Conduct: http://python.org/psf/codeofconduct/
