Принцип минимальных привилегий (least privilege)

Как это выглядит на VPS

UID 0 только у root. Каждый сервис работает от собственного пользователя с оболочкой nologin. Администраторы используют sudo с узкими правилами, а не неограниченный доступ, и никто не входит напрямую как root. Членство в группах вроде docker считается равнозначным root и остаётся коротким.

Как применять

Начните с аудита, у кого и у чего сейчас есть root, затем ужесточите правила sudo и сервисные учётные записи. Шаги описаны в нашем руководстве по пользователям, sudo и минимальным привилегиям.

Найдите, что работает от root прямо сейчас

В глоссарии NIST минимальные привилегии описаны как ограничение прав доступа теми, что нужны для поставленных задач. На сервере быстрее всего измерить отклонение от этого можно, посмотрев, что работает от root и что слушает сеть:

ps -eo user,pid,comm | awk '$1 == "root"'
sudo ss -tlnp
systemctl show -p User myapp.service

Первая команда перечисляет все процессы root. Список будет длинным, в нём есть потоки ядра в квадратных скобках, поэтому ищите имена приложений, а не считайте строки. Вторая показывает слушающие TCP сокеты с процессом-владельцем (-t TCP, -l слушающие, -n числовой вывод, -p процесс). База данных, сервер приложений или обработчик очереди, который работает от root и слушает сетевой порт, это первое, что нужно исправить. Некоторые демоны законно стартуют от root только чтобы занять порт, а затем передают работу непривилегированному пользователю, поэтому для каждого вопрос в том, сбрасывает ли он привилегии вообще. Третья команда показывает, от какого пользователя настроена служба systemd: пустое значение означает, что у юнита нет параметра User=, и он обычно работает от root (исключение: юнит с DynamicUser=). Сохраните вывод как точку отсчёта и сравнивайте после каждого развёртывания.

Как измерить и ужесточить юнит службы

Когда вы знаете, какая служба слишком сильна, systemd умеет и оценить её, и ограничить. Согласно руководству systemd-analyze, команда security оценивает, насколько открыт юнит, и выдаёт общий уровень от 0.0 до 10.0, где большее значение означает меньшую изоляцию. Она учитывает только защиту, которую обеспечивает сам systemd, а высокая оценка не доказывает, что служба уязвима. Это список дел, а не приговор.

systemd-analyze security myapp.service
sudo systemctl edit myapp.service

Команда edit создаёт дополнительный файл переопределения, поэтому исходный файл юнита остаётся нетронутым. Добавьте несколько осторожных настроек:

[Service]
User=myapp
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes

По документации systemd, NoNewPrivileges не даёт службе и её потомкам получать привилегии через биты setuid или файловые возможности, PrivateTmp выдаёт ей собственные /tmp и /var/tmp, а ProtectHome делает /home, /root и /run/user недоступными. Перезапустите службу, проверьте её работу и снова запустите оценку. Усиливайте ограничения по одному, чтобы знать, какое из них что-то ломает. Сторону учётных записей и sudo в той же работе разбирает руководство по пользователям, sudo и минимальным привилегиям.

Связанные термины: UID 0, Вход под root, authorized_keys, Docker socket, sudoers, /etc/passwd, sudo (выполнение команд с правами root).