What are the risks of running 'sudo pip'?

Иногда я сталкиваюсь с комментариями или ответами, в которых категорически утверждается, что запуск pip под sudo является "неправильным" или "плохим", но бывают случаи (включая то, как у меня настроена куча инструментов), когда это либо намного проще, либо даже необходимо запускать таким образом.

Какие риски связаны с запуском pip под sudo?

Обратите внимание, что это не тот же вопрос, что и этот, который, несмотря на название, не предоставляет никакой информации о рисках. Это также вопрос не о том, как избежать использования sudo, а о том, почему именно этого хотелось бы.

Когда вы запускаете pip с sudo, вы запускаете setup.py с sudo. Другими словами, вы запускаете произвольный код Python из Интернета от имени пользователя root. Если кто-то размещает вредоносный проект на PyPI и вы устанавливаете его, вы предоставляете злоумышленнику root-доступ к вашему компьютеру. До некоторых недавних исправлений pip и PyPI злоумышленник мог также запустить атаку "человек посередине", чтобы внедрить свой код при загрузке надежного проекта.

Помимо очевидных рисков безопасности (которые, я думаю, на самом деле невелики при установке известного вам программного обеспечения), упомянутых в других ответах, есть еще одна причина. Python, поставляемый с системой, является частью этой системы, и когда вы хотите управлять системой, вы используете инструменты, предназначенные для обслуживания системы, такие как менеджеры пакетов в случае установки / обновления / деинсталляции программного обеспечения. Когда вы начинаете изменять системное программное обеспечение с помощью инструментов сторонних производителей (pip в данном случае), у вас нет никаких гарантий относительно состояния вашей системы. Еще одна причина заключается в том, что sudo может вызвать проблемы, которых у вас не было бы или которые были бы очень малы в противном случае. Смотрите, например, Несоответствие между sys.executable и sys.version в Python

Дистрибутивы знают об этой проблеме и пытаются ее смягчить. Например, Fedora – Делает sudo pip безопасным и Debian – dist-пакеты вместо пакетов сайта.

Использование pip таким образом означает, что вы доверяете ему до уровня, на котором вы позволяете ему вносить какие-либо изменения в вашу систему. Не только pip, но и любой код, который он будет загружать и выполнять из источников, которым вы можете не доверять, и которые могут быть вредоносными.

И pip не нужны все эти привилегии, только доступ на запись к определенным файлам и каталогам. Если вы не можете использовать системный менеджер пакетов и не хотите использовать виртуальную среду, вы можете создать определенного пользователя с правами записи в каталог установки python и использовать его для pip. Таким образом, вы лучше контролируете, что может делать pip, а что нет. И вы можете использовать sudo -u для этого!

Есть несколько причин, которые не были упомянуты другими пользователями, но по-прежнему важны.

Отсутствие проверки кода среди pip пакетов

Первая причина заключается в том, что пакеты PyPI (пакеты, которые вы можете установить через pip) не отслеживаются и не анализируются кодом, к чему вы, возможно, привыкли с другими менеджерами пакетов. Было много случаев, когда вредоносные пакеты PyPI публиковались, а затем загружались тысячами пользователей перед удалением. Если вам посчастливилось загрузить один из этих вредоносных пакетов от имени root, то вы, по сути, предоставляете вредоносному ПО доступ ко всей вашей системе. Хотя это происходит не каждый день, о таком векторе атаки следует помнить. Вы можете узнать больше об этом, прочитав о концепции наименьших привилегий.

Запуск pip от имени root создает помехи для пакетов системного уровня

Вторая и более важная причина заключается в том, что запуск pip с sudo или от имени пользователя root приведет к вмешательству в пакеты системного уровня и может нарушить функциональность вашей системы. В ответе Петра Доброгоста кратко упоминается влияние, которое менеджеры пакетов могут оказывать на состояние вашей системы, но я думаю, что более подробное объяснение поможет людям лучше понять, почему эта практика может быть вредной.

Возьмем, к примеру, дистрибутив Linux, который поставляется с Python 3.6 и пакетом Python cryptography для выполнения криптографических операций. В иллюстративных целях представьте, что cryptography пакет версии 1.0.0 используется системой для хэширования паролей и позволяет пользователям входить в систему. Если версия 1.0.1 того же пакета вводит регрессию, которую система не учитывает, и вы обновляете глобальный cryptography пакет, запустив sudo pip3 install -U cryptography, вы случайно только что нарушили возможность входа пользователей в систему в масштабах всей системы, введя регрессию системных зависимостей.

Это надуманный пример, и на самом деле его было бы легче отследить, чем большинство других, но это, безусловно, возможный сценарий. В реальном мире вы, скорее всего, сломали бы что-то менее важное, но урок тот же. В некоторых сценариях этот пример было бы легче отменить, потому что вы бы точно знали, что вы сломали, когда все мгновенно перестало работать, но в конечном итоге вы могли бы сломать что-то, что гораздо сложнее отследить, и вы могли бы узнать об этом гораздо позже, когда у вас не будет воспоминаний о том, что вы изменили.

Почему вы хотели бы запустить pip с sudo?

Я не видел, чтобы кто-нибудь отвечал на последний вопрос в вашем посте, поэтому я затрону его здесь. Есть несколько причин, по которым кто-то хотел бы запустить pip с sudo, но они встречаются гораздо реже.

Первая причина, по которой люди захотели бы сделать это таким образом, заключается в том, что люди ленивы, а это быстрый способ заставить систему установить нужный вам пакет. Скажите, что кому-то нужно установить coloredlogs пакет, потому что им абсолютно необходимо, чтобы их журналы были окрашены прямо сейчас, и они ничего не знают о наличии безопасной системы. Неопытным пользователям часто намного проще добавлять sudo в начало всего, что не работает, потому что "это просто работает", вместо того, чтобы изучать, почему это не сработало с первого раза.

Вторая причина, и единственная законная причина, о которой я могу думать, заключается в том, что администратору нужно исправить что-то общесистемное. Скажем, что уязвимость появилась в pip версии 20.0.0 и есть исправление, которое устраняет проблему в версии 20.0.1. Системный администратор, вероятно, не хочет ждать, пока дистрибутив исправит это для них, и вместо этого хочет исправить это прямо сейчас, чтобы устранить проблему. В этом сценарии, я думаю, для системного администратора было бы безопасно использовать python3 -m pip install --upgrade pip для обновления своей версии pip, но им нужно быть осторожными, чтобы убедиться, что нет непредвиденных последствий.