NobodySubjectPolicy: различия между версиями
(Новая страница: «{{DraftPolicy |responsible=arseny@ |discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u |discussion_since=2023-11-15 }} == Введение == Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}. Одно время в кругу разработчиков и администраторов хо...») |
м (→Нормативные предписания: Уточнили, что в brp будут проверки юнитов) |
||
| Строка 25: | Строка 25: | ||
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small> | <small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small> | ||
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check; | * В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check; | ||
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. | * Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета; | ||
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп. | * Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп. | ||
== Примечания == | == Примечания == | ||
Версия от 02:42, 1 декабря 2023
Введение
Как известно, в файле 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) групп.
Примечания
- ↑ А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.