NobodySubjectPolicy: различия между версиями
м (→Нормативные предписания: Уточнили, что в brp будут проверки юнитов) |
Нет описания правки |
||
| (не показаны 3 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
{{ | {{Policy | ||
|responsible=arseny@ | |responsible=arseny@ | ||
| | |since=2023-12-20 | ||
}} | }} | ||
| Строка 27: | Строка 26: | ||
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета; | * Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета; | ||
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп. | * Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп. | ||
== FAQ == | |||
'''Q:''' Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе? | |||
'''A:''' Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с {{term|CAP_DAC_OVERRIDE}} и т. п., как обычно, сможет сделать с ними всё, что угодно. | |||
== Примечания == | == Примечания == | ||
Текущая версия от 13:23, 8 января 2024
Введение
Как известно, в файле 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 и т. п., как обычно, сможет сделать с ними всё, что угодно.
Примечания
- ↑ А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.