NobodySubjectPolicy: различия между версиями
(Новая страница: «{{DraftPolicy |responsible=arseny@ |discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u |discussion_since=2023-11-15 }} == Введение == Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}. Одно время в кругу разработчиков и администраторов хо...») |
Нет описания правки |
||
| (не показаны 4 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
{{ | {{Policy | ||
|responsible=arseny@ | |responsible=arseny@ | ||
| | |since=2023-12-20 | ||
}} | }} | ||
| Строка 25: | Строка 24: | ||
<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'') групп. | ||
== 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 в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.