On 01.09.2014 10:09, Nick Coghlan wrote:
On 1 September 2014 17:13, Christian Heimes firstname.lastname@example.org wrote:
On 01.09.2014 08:44, Nick Coghlan wrote:
Yes, it would have exactly the same security failure modes as sitecustomize, except it would only fire if the application imported the ssl module.
The "-S" and "-I" switches would need to disable the implied "sslcustomize", just as they disable "import site".
A malicious package can already play havoc with your installation with a custom ssl module. If somebody is able to sneak in a ssl.py then you are screwed anyway. sslcustomize is not going to make the situation worse.
That's not quite true - we're fairly careful about putting the standard library before userspace directories, so aside from the "current directory" problem, shadowing "ssl" itself can be tricky to arrange.
It's really easy to modify sys.modules to override any module that has already been loaded or add new ones bypassing sys.path entirely, so the sys.path layout doesn't provide any protection against such hacks.
If you gain access to one of the dirs on sys.path, you can play such tricks in sitecustomize.py. Any 3rd party package can do the same.
We'd have to add digital API signatures to the ssl module to prevent such stunts :-)