NobodySubjectPolicy

Материал из ALT Linux Wiki
Версия от 13:23, 8 января 2024; ArsenyMaslennikov (обсуждение | вклад)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Stamp90cw.png
Действующая политика Sisyphus

Политика действует с 2023-12-20.

Ответственный за проведение политики в жизнь — arseny@.


Введение

Как известно, в файле passwd по умолчанию в наших системах присутствуют пользователь и группа nobody.

Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д. Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под nobody, чтобы отсечь ему доступ к "более важным" службам. Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга. Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.

В ядре Linux достаточно давно есть понятие overflowuid/overflowgid: зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы. Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан overflowuid/overflowgid. Другой пример: NFS-клиент может представлять рута на клиентской машине overflowuidом на сервере. Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число ((uint16_t)-2), оно же 65534, дефолт в ядре, и обозвать этого пользователя nobody. Тем самым они объединяют понятия nobody и overflow[ug]id.

Вообще говоря, под пользователем nobody и группой nobody в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid. Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.[1]

Нормативные предписания

Здесь и далее словосочетание "под nobody" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.

  • В пакеты запрещается помещать файловые объекты под nobody. Исполнение правила контролирует sisyphus-check;
  • Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под nobody или имели nobody в числе дополнительных (supplementary) групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;
  • Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой nobody или помещать nobody в число дополнительных (supplementary) групп.

FAQ

Q: Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе?

A: Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с CAP_DAC_OVERRIDE и т. п., как обычно, сможет сделать с ними всё, что угодно.

Примечания

  1. А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.