NobodySubjectPolicy

Введение

Как известно, в файле 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. Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.

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

Здесь и далее словосочетание "под 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 и т. п., как обычно, сможет сделать с ними всё, что угодно.