5

Как известно, при установке пакетов из AUR следует соблюдать осторожность, поскольку PKGBUILD может не выполнять то, что вы ожидаете, и может быть вредоносным. По этой причине мой рабочий процесс по установке и обновлению пакетов из AUR следующий (с использованием yaourt):

Проверьте PKGBUILD:

  • Часть source=(...) содержит только URL-адреса из ожидаемого источника?
  • Быстро отсканируйте часть package(){...} если она выполняет только обычные операции установки / копирования

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

Вопросы:

  • Это так безопасно, как я предполагаю? Есть ли другие места (в PKGBUILD или где-либо еще), где можно провести атаку?
  • Очень неудобно проверять весь PKGBUILD при каждом обновлении пакета. В большинстве случаев меняются только номера версий или URL-адреса. Есть ли инструмент или простой способ представить / выделить отличия от последнего PKGBUILD?
  • Есть ли инструмент, который поддерживает пользователя с проверкой файлов PKGBUILD?

1 ответ1

1

Ответы на вопросы

Это так безопасно, как я предполагаю? Есть ли другие места (в PKGBUILD или где-либо еще), где можно провести атаку?

Пока вы доверяете программному обеспечению, оно безопасно для вас. Если нет редактора программного обеспечения, то, что вы делаете, является минимальным в соответствии с [Arch Wiki], потому что вы на самом деле не проверяете исходный код загруженных источников, куда может быть введен вредоносный код.

Цитировать вики:

Предупреждение: внимательно проверьте все файлы. Внимательно проверьте PKGBUILD и любой файл .install наличие вредоносных команд. PKGBUILD - это скрипты bash, содержащие функции, которые должны быть выполнены makepkg: эти функции могут содержать любые допустимые команды или синтаксис Bash, поэтому для PKGBUILD вполне возможно содержать опасные команды из-за злого умысла или невежества со стороны автора. Так как makepkg использует fakeroot (и никогда не должен запускаться с правами root), существует некоторый уровень защиты, но вы никогда не должны на это рассчитывать. В случае сомнений не создавайте пакет и не обращайтесь за советом на форумы или в список рассылки.


Очень неудобно проверять весь PKGBUILD при каждом обновлении пакета. В большинстве случаев меняются только номера версий или URL-адреса. Есть ли инструмент или простой способ представить / выделить отличия от последнего PKGBUILD?

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

Странные ошибки могут делать плохие вещи.

AUR включает Git, чтобы вы могли проверить изменения, внесенные в репозиторий AUR, по https://aur.archlinux.org/cgit/aur.git/log/?h=yourPackageNameHere .


Есть ли инструмент, который поддерживает пользователя с проверкой файлов PKGBUILD?

В то время, когда я пишу это, инструмента для этого не существует, но давайте посмотрим, каким будет будущее!


Обнаружение / Избегать злонамеренных

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

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

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

  • Загрузите пакет и его исходный код, распакуйте его, но не устанавливайте его.
  • Запустите проверку на наличие вирусов в распакованных / исходных файлах. Это поможет вам найти некоторые известные проблемы или взломы.
  • Прежде чем использовать его, установите его на виртуальную машину и убедитесь, что он не делает ничего плохого, например, касается файла, к которому он не должен подключаться, или, например, не связывается с серверами. Использование руткит-детектора должно автоматизировать обнаружение таких вещей.
  • Установите его в ограниченной среде, такой как SELinux, chroot jail, виртуальная машина, отдельные машины ...

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .