[Catalog-sig] Use user-specific site-packages by default?

[Jeroen Dekkers]

At Tue, 5 Feb 2013 11:36:46 +1000,
Nick Coghlan wrote:
> Something that caught my attention in the recent security discussions
> is the observation that one of the most common insecure practices in
> the Python community is to run "sudo pip" with unsigned packages
> (sometimes on untrusted networks).
> 
> To my mind, this is a natural reaction to the user experience of pip:
> you run "pip install package", it complains it can't write to the
> system site packages directory, so you run "sudo pip install package"
> to give it the permissions it clearly wants.
> 
> If pip used the user site packages by default (when running as anyone
> other than root), that dangerous UI flow wouldn't happen. Even when
> pip was run outside a virtualenv, it would "just work" from the users
> perspective. It also has the advantage of keeping systems cleaner by
> default, since there will be a clear separation between system
> packages and pip-installed packages.
> 
> Thoughts?

How this is going to improve anything with regards to security? There
might be other good reasons for changing it, but I don't see the
security benefit when installing untrusted packages.

If this is a single user installation (which given the use case it
probably is), then all the interesting data is going to be under that
single user account and is going to be compromised without the need
for root access. If it is a multi-user system, then the system
administrator will probably install it system-wide only when it is
needed and will do that regardless of pip defaults.

And in both cases a malicous software package can just replace "sudo"
on the path and wait for the user to use sudo and give their password.

The real security problem is that pip happily installs malicious
software without giving a blink and PyPI doesn't have anything for pip
to check whether the software is valid. Running pip under sudo or not
doesn't really matter much in my eyes, you're simply powned if you're
going to execute malicious code.

One way of fixing this is to generate a signed index file similar to
what Debian/Ubuntu does (see http://wiki.debian.org/SecureApt for more
details). I guess other distributions also do something like that and
it isn't really rocket science. The index file will contain the hashes
of all source distributions and has a signature that can be
verified. If the hash of the downloaded file doesn't match, you know
the tarball/zipfile has been tampered with.


Kind regards,

Jeroen Dekkers