Capabilities: права root по частям

Ядро проверяет права двумя способами. Обычному процессу — по правам файла и его владельцу. Процессу root раньше разрешалось всё. Теперь сила root разделена на части — capabilities (по-русски их зовут возможностями), и ядро спрашивает конкретную часть: слушать порт ниже 1024 можно с CAP_NET_BIND_SERVICE, читать чужой файл — с CAP_DAC_OVERRIDE.

У root по умолчанию все части, поэтому он может всё. Но процесс root без нужной части получает отказ, а процесс обычного пользователя с одной частью делает то, что она разрешает, и ничего сверх. На этом стоит принцип минимальных привилегий: службе — её часть, а не весь root.

На машине их 41. Список печатает capsh --decode=000001ffffffffff; частые:

Наборы процесса

У процесса пять наборов. Ядро хранит их битовыми масками и показывает в /proc/<PID>/status:

student@ubuntu:~$ grep Cap /proc/self/status
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000
student@ubuntu:~$ sudo grep Cap /proc/self/status
CapInh:	0000000000000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000

У student действующих частей нет, у процесса под sudo — все 41. Маску в имена переводит capsh --decode=<маска>, процесс по PID показывает getpcaps:

student@ubuntu:~$ getpcaps $(pgrep -xo systemd-timesyn)
456: cap_sys_time=eip
student@ubuntu:~$ getpcaps $(pgrep -xo systemd-resolve)
451: cap_net_raw=eip
student@ubuntu:~$ getpcaps $(pgrep -xo nginx)
611: =ep

Буквы после = — наборы: e effective, i inheritable, p permitted. Службы времени и имён работают от своих пользователей с одной частью каждая. =ep без имён — все части сразу: главный процесс nginx работает от root.

Capabilities файла

Исполняемый файл тоже может нести capabilities — как setuid, только вместо всего root процесс получает названные части. Таких файлов на машине три:

student@ubuntu:~$ getcap -r / 2>/dev/null
/usr/bin/mtr-packet cap_net_raw=ep
/usr/bin/ping cap_net_raw=ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
  cap_net_bind_service,cap_net_admin,cap_sys_nice=ep

Поэтому ping работает у student: ICMP без привилегий на машине выключен (net.ipv4.ping_group_range = 1 0), и CAP_NET_RAW программа получает от своего файла.

Выдаёт части файлу setcap, и только root. Проверка — скрипт bind81.py, который занимает порт 81:

import socket
s = socket.socket()
s.bind(('127.0.0.1', 81))
print('bound 81')

Часть получает копия Python: на символическую ссылку /usr/bin/python3 setcap не ставит.

sudo cp /usr/bin/python3.12 /usr/local/bin/py-bind
sudo setcap cap_net_bind_service=+ep /usr/local/bin/py-bind

student@ubuntu:~$ python3 bind81.py
PermissionError: [Errno 13] Permission denied
student@ubuntu:~$ getcap /usr/local/bin/py-bind
/usr/local/bin/py-bind cap_net_bind_service=ep
student@ubuntu:~$ /usr/local/bin/py-bind bind81.py
bound 81

Процесс из такого файла — обычный student с одной частью: CapEff у него 0000000000000400, это cap_net_bind_service. Граница непривилегированных портов — net.ipv4.ip_unprivileged_port_start = 1024.

Capabilities живут в расширенном атрибуте файла. Простой cp их не переносит, cp -a переносит. Новый файл на месте старого — после обновления пакета или пересборки — приходит без них: ping получает свою часть из скрипта установки пакета. На файловой системе с опцией nosuid capabilities файлов не действуют.

Root без нужной части

capsh --drop запускает команду от root, убрав из bounding-набора названные части:

student@ubuntu:~$ echo secret > ~/secret; chmod 600 ~/secret
student@ubuntu:~$ sudo cat /home/student/secret
secret
student@ubuntu:~$ sudo capsh \
> --drop=cap_dac_override,cap_dac_read_search \
> -- -c 'cat /home/student/secret'
cat: /home/student/secret: Permission denied

Root остался root (UID 0), но без CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH права файла для него действуют, как для всех. Так же root без CAP_NET_BIND_SERVICE получает Permission denied на порт 84.

Службы и контейнеры

Службе части выдаёт и отбирает systemd. AmbientCapabilities= даёт службе с User= нужную часть, CapabilityBoundingSet= задаёт потолок:

student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p User=demo \
> -p AmbientCapabilities=CAP_NET_BIND_SERVICE grep Cap /proc/self/status
CapInh:	0000000000000400
CapPrm:	0000000000000400
CapEff:	0000000000000400
CapBnd:	000001ffffffffff
CapAmb:	0000000000000400
student@ubuntu:~$ sudo systemd-run --pipe --wait -q \
> -p CapabilityBoundingSet=CAP_NET_BIND_SERVICE cat /home/student/secret
/usr/bin/cat: /home/student/secret: Permission denied

Во втором случае служба работает от root, но её потолок — CapBnd: 0000000000000400, и чужой файл ей не прочитать. Как собрать эти ключи в юнит — systemd-hardening. Docker запускает контейнер с урезанным набором частей, --cap-drop и --cap-add меняют его (см. docker).

• systemd-hardening — User=, CapabilityBoundingSet= и AmbientCapabilities= в юните.
• special-bits — setuid: весь root через файл.
• proc-filesystem — /proc/<PID>/status и другие файлы процесса.
• ping — программа с cap_net_raw.
• docker — части контейнера.
• apparmor — профиль тоже ограничивает части.
• sudo — команда от root целиком.