Steve Dower <steve.do...@python.org> added the comment:
> I'd been expecting this was commonly used as the way to give access to > python3X.dll. Yeah, both. The idea is to delete the files you don't want - so if you don't need python.exe, just don't include it. Same goes for some of the native modules (e.g. deleting _socket.pyd and _ssl.pyd are an easy way to make sure you aren't offering networking). > I've been mostly focusing on `PYTHONPATH` because that's where I encountered > the issue. Which if any of the other env variables are respected? It's the equivalent of passing -I. That's the flag that gets set when a ._pth is detected: PC/getpathp.c#L563 > Would there be an argument to add additional command line options that could > be used as a more secure alternative to the env variables? ... Maybe this > doesn't make sense since you said it is the ._pth that causes this...just > thinking aloud. Yeah, the ._pth file is the more secure alternative. To change the import search path, an attacker has to be able to modify a (likely admin-only) file on disk, rather than just launching an executable with a specific command line. (For a bit more context, many exploits try to schedule tasks, which allows arbitrary executable path and arguments. So anything resembling a security feature can't be allowed to be overridden by environment or arguments.) > The two options you mention (modify ._pth and append to sys.path) aren't > great because we 1) would prefer to use the un-modified python distro 2) > don't own the scripts that we are embedding, they are from a 3rd party so > modifications are complicated. None of the other options are better :) Overriding the ._pth file should just be a matter of replacing the file. It's deliberately relative to its location, which means it should almost always be static. If you need your embedded interpreter to pick up paths from the local environment, just delete the file instead of updating it (which will make your copy of Python exploitable, but that's the tradeoff). I don't know what your particular scripts look like, but I've had to go through and modify a number of third-party packages to make them work with this kind of setup. It's certainly possible to work around the limitation in a number of ways, often transparently to the code that's eventually going to be executed - the runpy module is often helpful. (And yeah, an attacker could do it as well, just not as trivially as it would be without the restriction.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42252> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
