Запретить `apt-get`,` yum` устанавливать бинарные файлы setuid, когда они запускаются через sudo

Предположим, что вы можете установить что-то в системе, потому что у вас есть права sudo для этого, но у вас есть только права sudo для установщика. В этом случае довольно просто создать пакет, который устанавливает двоичный файл, принадлежащий root, который имеет бит setuid, установленный во время установки, и этот бинарный файл выполняет любую команду, которую вы его кормите, с правами root. Это делает его небезопасным, чтобы разрешить ограниченный доступ sudo для любого данного пользователя к пакету, который может произвольно изменять разрешения на изменение. Другое очевидное (IMO) отверстие безопасности – это то, что пакет может обновить файл /etc/sudoers и предоставить пользователю все виды дополнительных прав.

Насколько я знаю, у apt-get или yum есть опция, которую вы можете установить или проверить, как они вызывается, что вызывает то, что установлено в нормальных, по умолчанию, местоположениях, но ограниченным образом (например, не перезаписывать уже имеющиеся файлы , или не устанавливают биты setuid).

Я что-то пропустил и существует ли установка с такими ограничениями? Доступен ли он у других инсталляторов? Или существуют другие известные обходные пути, которые сделают такие ограничения неэффективными (и не будут ли они тратить время)?

2 Solutions collect form web for “Запретить `apt-get`,` yum` устанавливать бинарные файлы setuid, когда они запускаются через sudo”

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

Как вы заметили, пакет может объявить, что он устанавливает /etc/sudoers . Даже если вы делаете ad hoc правило, чтобы каким-то образом предотвратить это, пакет может удалить файл в /etc/sudoers.d . Или он может отбросить файл в файле /etc/profile.d , который будет читаться при следующем входе в систему любого пользователя. Или он может добавить службу, запущенную root во время загрузки. У этого списка нет конца; это неуправляемо, и даже если вы столкнулись с проблемными случаями, вы бы запретили так много пакетов устанавливать, что вы могли бы не беспокоиться (например, этот объект не позволит большинство обновлений безопасности). Еще одна вещь, которую может сделать пакет, – это установить программу, которую вы обманываете при использовании позже (например, если вы запретите вообще писать доступ к /bin , он может установить /usr/local/bin/ls ) и который вводит бэкдор через вашу учетную запись при следующем вызове программы. Чтобы предотвратить установку пакета из потенциального отверстия безопасности, вам необходимо либо ограничить установку доверенными пакетами, либо убедиться, что вы никогда не используете установленные пакеты.

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

Если вы хотите предоставить ненадежному пользователю возможность устанавливать больше пакетов (из предопределенного списка источников, которые вы одобряете как безопасные) или обновлять существующие пакеты в основной системе, это может быть безопасным, но вам необходимо принять меры предосторожности, в частности для отключения взаимодействия во время установки. См. Безопасно ли для моего пользователя ssh предоставить пароль sudo для `apt-get update` и` apt-get upgrade`? для некоторых идей о apt-get upgrade .

В последних версиях Linux (ядро ≥ 3.8) любой пользователь может запустить пространство имен пользователей, в котором у них есть идентификатор пользователя 0. Это в основном позволяет пользователю установить собственный дистрибутив в своем собственном каталоге.

Если пользователь может создать любой пакет и загрузить его в репозиторий, которому доверяет установщик, я не знаю, как защитить систему в том виде, в котором вы ищете (по крайней мере, не с apt-get ). Сценарии maintainer в пакете выполняются как root (будь то в apt , yum или dnf типах), поэтому установка пакета эффективно дает автору root доступ к этой системе.

Возможно, с помощью чего-то вроде SELinux вы могли бы разработать политику, которая предоставила бы пользователям достаточный доступ для установки пакетов в определенных местах, но не приносила никакого ущерба ( например, не касаться /etc/sudoers , /sbin , /usr/sbin и т. Д. И конечно, конфигурация менеджера пакетов), но я сомневаюсь, что вы могли поймать все. (Я не знаю достаточно о SELinux, чтобы быть уверенным.)

Если вы можете контролировать то, что входит в репозитории, тогда вы в порядке. Если кто-либо может загрузить что-либо в репозиторий, требующие подписи на самом деле не помогут вам, по крайней мере, с помощью apt-get : несогласованные подписи вызывают предупреждения и подсказки, которые могут быть переопределены, и я не думаю, что есть способ конфигурации apt-get поэтому он не позволит переопределить.

  • Не найдено ни одной версии кандидата для sudo
  • Как ограничить su от root до nis клиентов
  • Почему пароль «sudo» отличается от пароля su?
  • Почему $ HOME наследуется, когда я запускаю оболочку с sudo?
  • Как запустить перезагрузку в качестве обычного пользователя без необходимости вводить пароль?
  • Сломанный sudo на веб-сервисах amazon ec2 linux centOS
  • Как добавить себя в список sudoers?
  • Запуск в корневой оболочке из скрипта пользователя bash
  • Bash, выполнить команду после вызова новой оболочки
  • Как я могу поместить пользователя в файл суперпользователей?
  • Запустить команду sudoed после завершения скрипта?
  • Linux и Unix - лучшая ОС в мире.