[devel] NobodySubjectPolicy draft

[Arseny Maslennikov <arseny@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 6411 bytes --]

Hi!

(Видимо, потребуется проходить процедуру PolicyPolicy, но писать статью
на вики и воевать с разметкой MediaWiki сейчас некогда, так что начнём
обсуждение этим письмом, а страницу по его тексту составим позже)

=== Введение ===

Как известно, в файле 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 и группой nobody в системе не
должно работать ничего, а в ФС на несъёмных устройствах хранения не должно
создаваться файловых объектов с такими uid и gid. Для того, чтобы это
гарантировать, следует ввести автоматические проверки на этапе
сборки пакетов, а лучше даже во время работы системы (что-то вроде
seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого
пользователя), но не всё сразу.

=== Предложение ===

Вношу следующее предложение:
- Сменить пользователю и группе nobody численный идентификатор с 99 на
  65534. Для обозначения 99-го оставить другое имя, например, _nobody99;
- Передать /var/nobody этому самому _nobody99;

Для пакетов в Sisyphus:
- Запретить установку файловых объектов под nobody с пакетами;
- Рекомендовать мейнтейнерам не допускать, чтобы собираемые ими
  системные службы исполняли код под nobody;
- Рекомендовать администраторам не запускать процессы под юзером и группой
  nobody.

=== Footprint ===

Я взялся выявить пакеты, которые по ошибке собираются или
устанавливаются так, чтобы работать под nobody:

- Упоминают username nobody в тексте значащей части спека:
  bozohttpd	george @everybody
  freeipa	slev sem sin
  kf5-kdesu	zerg
 
Все они устанавливают в систему либо файлы под nobody, либо инструкции
для процессов в виде инит-скриптов, юнитов или частей sshd-конфига.

Вот этот пакет зачем-то пытается ставить в систему исполнимый бинарник с setgid nobody:
  kf5-kdesu	zerg
Забавно, что этот бинарник после установки в хешерницу всё же оказывается 2711/root/root.
Я планирую запретить так делать на уровне sisyphus_check.
 
- Используют username nobody при работе и при этом как-то упоминают nobody в спеке:
  checkinstall-helper-sh-safely	imz @everybody
В этом конкретном случае явный вред от того, что checkinstall-нагрузка
работает под nobody, представляется мне малым, но с точки зрения
уменьшения ментальной нагрузки ему лучше тоже иметь своего сист.
пользователя.

Приветствую вопросы и предложения.

Спасибо!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]