Безопасно ли устанавливать программы, кроме как с помощью менеджера пакетов дистрибутива?

Когда я перешёл с Windows на Linux, мне было милосердно даровано наличие менеджеров пакетов. Большую часть времени официальные репозитории моей дистрибуции (в данный момент Debian 12) содержат необходимые мне пакеты. Но иногда их не оказывается, что означает, что если я хочу установить некоторые приложения, мне придётся делать это без использования менеджера пакетов; возможно, клонируя репозиторий GitHub и собирая из исходников, или используя wget или curl, чтобы получить специальный установщик от разработчиков.

Безопасно ли это делать? Я не спрашиваю о надёжности этих пакетов. Скорее, повредит ли это систему управления пакетами, если я это сделаю? Будут ли пакеты, установленными таким способом, обновляться, когда я использую менеджер пакетов дистрибуции для выполнения обновления системы, например? Могу ли я использовать менеджер пакетов для их удаления?

Вот конкретный пример. Скажем, я хочу установить Rust. Официальный сайт Rust сообщает пользователям Linux выполнить следующую команду.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Другими словами, загрузите файл rustup.rs с сайта, а затем запустите его, чтобы установить Rust. Этот пример вызывает у меня двойное замешательство, поскольку в Debian доступен пакет rustup в репозиториях. Так стоит ли мне использовать Debian-пакет, или следовать инструкциям на сайте?

Вот ещё один пример. Скажем, я хочу установить Minecraft, который не доступен в репозиториях Debian. Поэтому мне нужно перейти на сайт Minecraft, который позволяет скачать файл minecraft.deb. Если я прав, я затем использую apt для его установки. В этом случае будет ли пакет отслеживаться менеджером пакетов? Могу ли я его удалить или обновить с помощью apt?

Спасибо за помощь в разъяснении этой путаницы, которая беспокоит меня уже довольно долго.

В общем, да, это безопасно, при условии, что поставщик программного обеспечения имеет хорошую репутацию и устанавливаемое вами программное обеспечение не было изменено (я не касался этого, потому что вы ясно сказали, что “не спрашиваете о надёжности этих пакетов”; смотрите ответ Жиля для тщательного сравнения безопасности с атаками). Пока что-либо, установленное не с помощью пакета, устанавливается в /usr/local или /opt, и не добавляет себя в глобальные системные конфигурационные файлы, вы не повредите свою систему.

Ваш вопрос не упоминает установку из исходников; но обычно, когда это делается, программное обеспечение устанавливает себя по умолчанию в /usr/local, если может (то есть, вы можете запустить установку от имени root).

Другим “безопасным” местом установки является что-то в вашем домашнем каталоге. Это имеет то преимущество, что не требует административных прав, что гарантирует, что ваша система не может быть полностью разрушена — вы всё равно сможете войти как другой пользователь. Однако поскольку большая часть данных, которые вам важны, находится в вашем домашнем каталоге, это может не сильно помочь против ошибочных установщиков или ошибок. В частности, никогда не используйте свой домашний каталог в качестве префикса установки (я видел, как пользователи теряли все свои данные таким образом), используйте подкаталог — $HOME/.local — хороший кандидат.

Я сначала отвечу на последнюю часть вашего вопроса, потому что это проще. Если вы загружаете файл .deb и устанавливаете его (используя apt install ./minecraft.deb, например, что лучше, чем dpkg -i minecraft.deb, потому что он позаботится о зависимостях), менеджер пакетов тогда будет в курсе пакета. Это хорошо, потому что это значит, что зависимости пакета не будут случайно удалены. Вы также сможете удалить пакет, используя apt. Однако установка пакета таким образом не гарантирует, что вы сможете обновить его с помощью apt; исключение составляют пакеты, которые настраивают собственный репозиторий (например, многие пакеты Google). Вы всегда можете вручную обновить такие пакеты, загрузив новый пакет и снова используя apt install для его установки.

Язык экосистем и сопутствующие инструменты, такие как rustup, немного сложнее. Просто чтобы убрать rustup с пути, он доступен как пакет Debian, но только в Debian 13 и позже (см. руководство по установке rustup); поэтому вы не можете использовать apt install rustup как есть на Debian 12.

Большинство языковых экосистем осознают ограничения упаковки дистрибуций и хорошо работают наряду с пакетами в дистрибуции. Вы можете установить последнюю версию Go, например, наряду с пакетированным Go в Debian, и всё будет работать хорошо. То же самое касается Java, и с Debian 12, Python, если вы используете виртуальные окружения. Единственное, на что нужно обратить внимание, это то, что вы никогда не должны заменять системные бинарные файлы (те, что в /usr/bin) несовместимыми версиями; это особенно распространено в Python, и здесь множество вопросов возникло из-за пользователей, заменяющих /usr/bin/python3. Пока вы не делаете что-то подобное, всё должно быть в порядке.

Программное обеспечение, установленное вне менеджера пакетов, как правило, не отслеживается им.

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

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

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

.deb пакет можно установить с помощью dpkg или apt

Как установить deb файл, с помощью dpkg -i или с помощью apt?

sudo apt install package.deb

sudo dpkg -i package.deb

dpkg — это инструмент низкоуровневого управления пакетами для систем на основе Debian, который устанавливает, удаляет и управляет .deb пакетами напрямую.

Старайтесь использовать репозитории Debian, если это возможно.

Не забывайте, что не все пакеты находятся в основных репозиториях Debian.

Вы должны изменить ваш /etc/apt/sources.list

Это мой sources.list:

## MAIN STABLE
deb http://deb.debian.org/debian bookworm main
deb-src http://deb.debian.org/debian bookworm main

deb http://deb.debian.org/debian-security/ bookworm-security main
deb-src http://deb.debian.org/debian-security/ bookworm-security main

deb http://deb.debian.org/debian bookworm-updates main
deb-src http://deb.debian.org/debian bookworm-updates main

## NON-FREE
#deb http://deb.debian.org/debian bookworm main non-free-firmware
#deb-src http://deb.debian.org/debian bookworm main non-free-firmware

#deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware
#deb-src http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware

#deb http://deb.debian.org/debian bookworm-updates main non-free-firmware
#deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware

## BACKPORTS
#deb http://deb.debian.org/debian bookworm-backports main contrib non-free
#deb-src http://deb.debian.org/debian bookworm-backports main contrib non-free

## UNSTABLE
#deb http://deb.debian.org/debian/ unstable main
#deb-src http://deb.debian.org/debian/ unstable main

После внесения изменений выполните sudo apt-get update или apt update, чтобы обновить список пакетов.

В чем разница между apt и apt-get?

Просто чтобы вы знали, существует другой менеджер пакетов под названием Synaptic.

Это графический интерфейс для apt и dpkg, который предоставляет удобный интерфейс для пользователя.

Пользователи могут искать пакеты, просматривать информацию о них и устанавливать или удалять их одним щелчком мыши.

Он отображает зависимости и рекомендуемые пакеты, предоставляя пользователю больший контроль над управлением пакетами.

Synaptic — это графический интерфейс для системы управления пакетами Debian.

На это в общем нельзя однозначно ответить, так как мы не знаем, что включает установка, тем более при установке чего-то через команду, подобную этой:

 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Скрипт может делать что угодно. Он может добавлять репозиторий и устанавливать что-то из этого репозитория (и есть множество curl | sh скриптов, которые это делают). Он может проявиться в виде разных скриптов в разных местах (возможно, здесь этого не происходит, но может). Этот пакет minecraft deb может добавлять репозиторий. Любой из этих случаев может очень легко нарушить систему управления пакетами (если они её используют в случае curl | sh скриптов), если они добавляют репозиторий, который затем добавляет какой-то пакет, который затеняет или конфликтует с другим пакетом, который вы хотите использовать из репозиториев дистрибуции.

И не только deb файлы или случайные скрипты. Установка произвольных пакетов Python от имени root (что мог бы делать скрипт) известна нарушением систем управления пакетами, и именно поэтому PEP-668 появился (что привело к таким вопросами, как ошибка pip в Ubuntu: управляемая внешними средами × Эта среда управляется внешне и Как мне решить “ошибка: указанная среда управляема внешне” каждый раз, когда я использую pip 3?). Скрипт может компилировать и устанавливать OpenSSL или какую-то основную библиотеку и нарушать ваши команды управления пакетами просто потому, что библиотека была установлена таким образом, что переопределила системные библиотеки.

В случае curl | sh сценариев я обычно предпочитаю сам просмотреть скрипт, выбрать из него части, которые имеют отношение ко мне и к системам, которые я использую, и выполнить их самостоятельно.

В этом случае, будет ли пакет отслеживаться менеджером пакетов? Могу ли я его удалить или обновить с помощью apt?

В этом случае, да, пакет будет отслеживаться apt/dpkg. Вы сможете его удалить. Некоторые deb файлы (например, Google Chrome) действительно добавляют репозитории в процессе установки пакета, что затем позволяет вам использовать apt для их обновления, но вам, возможно, придётся вручную загружать новые deb файлы и устанавливать их снова, если такие репозитории не добавляются.

Невозможно точно определить, когда вы фактически “принимаете подход Windows” и загружаете и запускаете какой-то случайный кусок программного обеспечения. Некоторые из них ведут себя хорошо и помещают всё под /opt или /usr/local, как это необходимо, чтобы не мешать системному менеджеру пакетов. Например, официальная цепочка инструментов Go от https://go.dev действительно помещает всё под /usr/local в UNIX-подобных системах (фактически /usr/local/go). Но не все программные обеспечения ведут себя так хорошо, и трудно быть уверенным.

Существуют несколько особых исключений ко всему этому:

• Flatpaks безопасны. Они специально предназначены для данного типа распределения программного обеспечения и в значительной степени гарантируют правильное управление вещами. В некоторых случаях их даже предпочитают менеджеру пакетов дистрибуции, поскольку они работают более надёжно (Steam является ярким примером этого) или обеспечивают лучшую безопасность.
• Snaps и AppImages также безопасны в том же смысле, что и Flatpaks, хотя я бы в целом рекомендовал Flatpak выше, чем Snap или AppImage (Flatpak обычно имеет меньшие накладные расходы, лучшую интеграцию с рабочим столом и более простую в работе модель разрешений).
• OCI-контейнеры, такие как Docker/Podman, безопасны. Снова же, они предназначены для этого типа использования. Эти варианты, действительно, предпочитаемый подход для цепочек инструментов, таких как Rust, Elixir, Node.JS или даже Python в многих случаях, так как вы, вероятно, захотите другие вещи, не упакованные вашей дистрибуцией, в процессе работы с языком.
• Применения/инструменты, написанные на Go, как правило, безопасны, если установлены с использованием инструментов go (go install). Цепочка инструментов Go управляет ими в подкаталоге вашего домашнего каталога, и они по сути на 100% самодостаточны, так что риск практически отсутствует, если они не записывают в произвольные файлы по всей системе.
• Сторонние репозитории для менеджера пакетов системы безопасны (конкретно в том смысле, что они не повредят менеджер пакетов), но могут не работать полностью с системой.
• Изолированные пакеты в родном формате системы безопасны в том же смысле, что и сторонние репозитории, но они склонны использовать автоматические обновления в стиле Windows (например, Minecraft DEB просто обеспечивает установку необходимых пакетов, а затем устанавливает минимальную начальную настройку, которая затем загрузит фактический установщик Minecraft, который в свою очередь загрузит сам Minecraft; Dropbox известен тем, что делает что-то подобное, и я думаю, что Google Chrome тоже это делает), что имеет потенциально неприятные последствия для безопасности.

Сравнение безопасности пакетов

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

Под “пакетом дистрибуции” я имею в виду пакеты, распространяемые напрямую крупными дистрибуциями, такими как Debian, Ubuntu, Red Hat, SuSE, Arch, FreeBSD и т. д. Дистрибуции с меньшим числом специалистов могут иметь меньшую относительную безопасность. Пакеты, загружаемые вручную в формате дистрибуции (например, .deb или .rpm), не имеют преимуществ безопасности пакетов дистрибуций. Пакеты, установленные из дополнительных источников пакетов (например, Ubuntu PPA) занимают промежуточное положение.

Прозрачность

Пакеты дистрибуции подписаны и реплицируются, а установщик проверяет подпись. Так что вы знаете, что получаете. Если в данной версии обнаружена ошибка, вы, по крайней мере, сможете узнать, была ли у вас проблемная версия.

В отличие от этого, когда вы устанавливаете что-то с помощью curl https://example.com/run_me.sh | bash, у вас нет возможности узнать, что вы установили. Зловредный веб-сервер может вернуть чистый установщик, если вы загружаете .sh, но установщик с бэкдором, если вы запускаете curl … | bash, определив время пауз в выполнении сценария установщика. Это даже различает curl -o install.sh … и curl … | bash.

Сторонние источники пакетов находятся где-то между: они подписаны лишь своим поставщиком, но некоторые (такие как Ubuntu PPA) размещаются дистрибуциями, что, по крайней мере, предотвращает незамеченные замены.

Проверка

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

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

Доступность обновлений безопасности

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

Некоторые поставщики следуют тем же принципам. Другие — нет.

Автоматичность обновлений безопасности

Для любого программного обеспечения, которое приходит через ваш менеджер пакетов, одна команда (например, apt update && apt upgrade) применяет все обновления безопасности. Некоторые дистрибуции или рабочие окружения настроены на автоматическое применение задач для обновлений безопасности или предлагают вам применить обновления безопасности.

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

Автоматизация пакетов

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

Вы не получаете этих преимуществ от вручную установленного программного обеспечения.

Качество пакетов

Дистрибуции имеют минимальные требования к качеству пакетов. Например, они следуют соглашениям о структуре каталогов. Они не нарушат вашу систему или ваш аккаунт пользователя произвольными способами. Они очищают после себя, когда вы их удаляете.

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

Качество интеграции

Дистрибуции не проводят много тестирования большинства программного обеспечения, которое они поставляют. Но, по крайней мере, они гарантируют, что все зависимости удовлетворены — вы не окажетесь с программным обеспечением B, требующим A версии 1.3, и программным обеспечением C, требующим A версии 1.4, и без возможности установить обе версии A. В частности, данная версия дистрибуции компилирует все программы против заданного набора версий библиотек. Дистрибуции решают проблему DLL-ада.

Если вы устанавливаете программное обеспечение, которое не из дистрибуции, вы остаётесь наедине со своими проблемами. Поставщик мог проверить это или не проверить с системой, похожей на вашу. Два разных поставщика могут иметь совершенно разные ожидания от типичной системы.

Именно поэтому многие поставщики теперь поставляют “приборы”: вместо того, чтобы просто отправлять приложение, они отправляют приложение и все библиотеки, от которых оно зависит. Иногда они даже размещают приложение в контейнере: flatpak, образ Docker, виртуальная машина… Это решает проблему зависимостей, но это также означает, что библиотеки в контейнере не получают исправлений ошибок (и в частности исправлений безопасности), если поставщик не применил исправления к своей собственной копии библиотеки. На практике это никогда не происходит, так что мы возвращаемся к проблеме доступности обновлений безопасности, которую я упомянул ранее.

О языковых экосистемах

Если вы разработчик, во многих языках программирования каналы распределения, специфичные для языка (pip, npm, rustup, hackage, opam и т. д.), трудно избежать.

К сожалению, состояние упаковки довольно плохое. Единственное хорошее — это то, что они обрабатывают версионированные зависимости. Эти менеджеры пакетов едва ли отслеживают, какие файлы принадлежат кому. Они могут или не могут быть в состоянии очистить всё при удалении.

Эти экосистемы обычно сдаются перед проблемой DLL-ада и просто говорят вам установить отдельные копии всего в каждом дереве сборки, или по крайней мере по одной на (версию) проекта. Но если ваш проект требует библиотек A и B, которые обе требуют библиотеку C, но разных версий… вам не повезло.

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