On Tue, Feb 5, 2013 at 11:55 PM, Jeroen Dekkers <[email protected]> wrote: > 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.
It limits the primary threat to data destruction and one shot retrieval of local data (with one obvious choice on *nix systems being to upload the contents of ~/.ssh). The default PATH on Linux doesn't include any user writable directions before the system directories, so you can't use those to shadow system utilities like sudo, and not running as root means more pernicious attacks (like setting up persistent keylogging, or zombie systems) won't work. A useful security barrier is one which prevents some threats, without opening up the overall system to additional dangers. "pip" and similar tools confining themselves to user writable directories by default, and always requiring an explicit flag in order to touch system directories with intent to modify them, would be one such barrier. (There is no additional complexity introduced, as the "--user" option means the capability is already present - it is merely a matter of switching the default behaviour). Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
