Даже не от root служба видит весь диск и чужие домашние каталоги. systemd умеет закрыть их, не трогая код службы.
Ограничения (в Вики) ставят строками в той же секции [Service] drop-in'а:
| Строка | Что делает |
|---|---|
ProtectSystem=strict |
вся файловая система только для чтения, кроме явно открытых путей |
ProtectHome=yes |
каталоги /home и /root служба не видит |
NoNewPrivileges=yes |
процесс и его потомки не могут повысить права (например, через sudo или setuid) |
PrivateTmp=yes |
свой /tmp, отдельный от общего |
С ProtectSystem=strict служба не запишет даже в /etc, а NoNewPrivileges=yes снимает действие setuid-бита: sudo под таким процессом откажет. Службе, которая только раздаёт готовые файлы, запись никуда не нужна — ограничения ей не мешают.
Закрой службе диск и дом
В тот же drop-in службы lab-preview добавь ограничения: вся файловая система только для чтения (ProtectSystem=strict), каталоги /home и /root скрыты (ProtectHome=yes), повышение прав запрещено (NoNewPrivileges=yes). После перезапуска служба должна по-прежнему отдавать отчёт на http://127.0.0.1:8095/q3.txt.
Цели · 0 из 3
- Сделать диск только для чтения и скрыть домашние каталоги ещё не выполнена
- Запретить службе повышение прав ещё не выполнена
- Оставить службу отвечающей на запросы ещё не выполнена
У службы стоит ProtectSystem=strict. Она пробует записать файл в /etc. Что произойдёт?
-
ProtectSystem=strictделает диск только для чтения и для root тоже.systemd-run -p ProtectSystem=strict touch /etc/xотвечает «Read-only file system». -
Юнит с
ProtectSystem=strictзапускается нормально; запрет срабатывает на самой записи, а не при старте. -
systemd не перенаправляет путь — он отказывает в записи. Файл по пути
/etc/...просто не создастся.
ProtectSystem=strict делает всю файловую систему только для чтения, кроме явно открытых путей, поэтому запись в /etc отклоняется — даже у root.