NoNewPrivileges=yes: запрет получения новых привилегий
Запрещает процессам службы и всем их потомкам получать новые привилегии: setuid-программы перестают повышать права, возможности не добавляются.
Что делает
Это одна из самых полезных защит с точки зрения соотношения «эффект к риску»: она почти ничего не ломает у обычных служб и закрывает целый класс способов повышения прав. Флаг наследуется потомками и снять его нельзя.
Ломает она только то, что действительно рассчитывает на повышение прав: вызовы sudo и su внутри службы, setuid-программы вроде ping в старых системах, выдачу постоянных возможностей.
Где ставится. В секции [Service]. Включается автоматически при DynamicUser=yes.
Значения
| Значение | Что происходит |
|---|---|
yes | запрет включён; снять его внутри службы невозможно. |
no | по умолчанию для обычных служб. |
По умолчанию: no, но yes при DynamicUser=yes
Пример
Обычный набор защит для прикладной службы.
[Service]
User=app
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
StateDirectory=myappТакой набор подходит большинству прикладных служб и почти ничего не ломает. Проверить цену изоляции помогает systemd-analyze security.
Типичные ошибки
Служба, вызывающая внутри sudo или setuid-программы, перестанет работать.
Несовместим с AmbientCapabilities=: постоянные возможности не выдаются.
Флаг наследуется: скрипты, запускаемые службой, тоже не смогут повысить права.
Связанные ошибки
- status=227/NO_NEW_PRIVILEGES в systemdКод 227/NO_NEW_PRIVILEGES: не удалось включить запрет получения новых привилегий. Редкий код, обычно из-за окружения.
- status=218/CAPABILITIES в systemdКод 218/CAPABILITIES: не удалось применить набор возможностей процесса из CapabilityBoundingSet= или AmbientCapabilities=.
- Permission denied в журнале службыОтказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
Рядом стоящие параметры
Источники
- systemd.exec(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)