Ограничения службы: User=, ProtectSystem, NoNewPrivileges

По умолчанию служба получает всё: работает от root, пишет в любой каталог, видит домашние каталоги, может запустить sudo. Ошибка в ней — это root на машине. Ограничения — ключи секции [Service]: systemd накладывает их на процесс до запуска ExecStart, программа о них не знает. Ключи кладут в drop-in, и юнит из пакета остаётся как есть. Общее правило — минимальные привилегии: службе только то, без чего она не работает.

Учебная служба demo-web — python3 -m http.server на порту 8090. Без ограничений она работает от root со всеми capabilities:

student@ubuntu:~$ ps -o user,pid,cmd -C python3
USER         PID CMD
root        2382 python3 -m http.server 8090 --bind 127.0.0.1
  --directory /srv/demo
student@ubuntu:~$ sudo grep -E 'Uid|CapEff' /proc/2382/status
Uid:	0	0	0	0
CapEff:	000001ffffffffff

От чьего имени

User= и Group= запускают службу от названного пользователя. Ему не нужны ни пароль, ни вход, ни домашний каталог:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin demo

Тот же cat от root читает /etc/shadow, от demo — нет:

student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p User=demo \
> cat /etc/shadow
/usr/bin/cat: /etc/shadow: Permission denied

DynamicUser=yes обходится без useradd: systemd заводит временного пользователя на время работы службы (uid=64021(run-u50)) и убирает его после. Данные такой службы живут в /var/lib/private/<имя>.

Файловая система

student@ubuntu:~$ sudo systemd-run --pipe --wait -q \
> -p ProtectSystem=strict touch /etc/demo-file
/usr/bin/touch: cannot touch '/etc/demo-file': Read-only file system
student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p ProtectHome=yes \
> ls -la /home
total 4
d---------  2 root root   40 Oct 21 05:05 .
drwxr-xr-x 21 root root 4096 Oct 20 23:33 ..

Для логов, кэша и сокетов есть такие же ключи: LogsDirectory= (/var/log/<имя>), CacheDirectory=, RuntimeDirectory= (/run/<имя>).

demo-web при старте дописывает строку в /var/lib/demo/started. Каталог создан ещё при запуске от root, и после User=demo и ProtectSystem=strict запись не проходит — служба падает:

student@ubuntu:~$ sudo journalctl -u demo-web -o cat -n 3
/bin/sh: 1: cannot create /var/lib/demo/started: Permission denied
demo-web.service: Main process exited, code=exited,
  status=2/INVALIDARGUMENT
demo-web.service: Failed with result 'exit-code'.

StateDirectory=demo чинит это: systemd отдаёт каталог пользователю demo и открывает его для записи, остальная система так и остаётся только для чтения:

student@ubuntu:~$ ls -ld /var/lib/demo
drwxr-xr-x 2 demo demo 4096 Oct 21 05:06 /var/lib/demo

Новые привилегии

NoNewPrivileges=yes ставит процессу флаг no_new_privs: ни он, ни его потомки не поднимут права через setuid-программы (sudo, su) и capabilities файлов. sudo внутри такой службы отвечает прямо:

student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p User=demo \
> -p NoNewPrivileges=yes sudo -n true
sudo: The "no new privileges" flag is set, which prevents sudo from
  running as root.
sudo: If sudo is running in a container, you may need to adjust the
  container configuration to disable the flag.

Без флага sudo дошёл бы до проверки пароля (sudo: a password is required) — а у пользователя со своим правилом в sudoers и дальше.

Capabilities

CapabilityBoundingSet= — потолок capabilities службы: пустое значение отбирает все, список оставляет только названные. Служба от root с пустым потолком не обойдёт права файлов и не загрузит модуль ядра. AmbientCapabilities= выдаёт части службе с User=, например порт ниже 1024:

[Service]
User=demo
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Часть из AmbientCapabilities= действует, только если она есть и в потолке. Пустой CapabilityBoundingSet= в другом drop-in'е срезает её, и служба снова получает PermissionError: [Errno 13] Permission denied.

Другие ключи

systemd-analyze security

systemd-analyze security <юнит> проверяет около 80 ключей и печатает таблицу из трёх столбцов: NAME, DESCRIPTION, EXPOSURE. ✗ — защита не включена, справа её вес; ✓ — включена. Несколько строк для demo-web:

В конце — итог, оценка открытости от 0 до 10:

student@ubuntu:~$ systemd-analyze security demo-web | tail -1
→ Overall exposure level for demo-web.service: 9.6 UNSAFE :-{

Без имени юнита команда печатает одну строку на службу: на учебной машине почти все службы — 9.5–9.6 UNSAFE, у rsyslog — 6.3 MEDIUM, у polkit — 1.6 OK. Уровни:

Как менялась оценка demo-web:

Оценка — сумма весов строк. Первые ключи закрывают самое опасное, но строк у них три, и оценка падает только на 0.9. Больше всего строк у capabilities: пустой CapabilityBoundingSet= закрывает их разом.

--threshold=N превращает оценку в проверку. Порог — в десятых долях: оценка 9.6 — это 96. Выше порога — код 1, равна или ниже — 0:

student@ubuntu:~$ for t in 95 96; do
>   systemd-analyze security --threshold=$t demo-web >/dev/null
>   echo "threshold=$t rc=$?"
> done
threshold=95 rc=1
threshold=96 rc=0

Оценка считается по настройкам юнита: после daemon-reload она уже новая, а работающий процесс остаётся прежним до restart. Проверяй и процесс — ps -o user, /proc/<PID>/status.

• systemd — юниты и drop-in.
• capabilities — части root, потолок и ambient-набор.
• systemctl — show, restart, daemon-reload.
• journalctl — почему служба упала.
• apparmor — ограничение профилем ядра.
• users-groups — системные пользователи.
• nologin — оболочка пользователя службы.