Служба с минимальными правами

Не запущена Запускается обычно ~20 с

Шаг 5 из 6 · лаба · 25 мин

Служба может всё

Служба заявок техподдержки работает от root и без единого ограничения — перед проверкой безопасности это нужно исправить. Ограничь её средствами systemd так, чтобы она продолжала принимать и хранить заявки.

Ситуация

Служба lab-tickets — приложение tickets-api — принимает заявки техподдержки. Её юнит писали наспех: служба работает от root, и ничто не мешает ей делать всё, что может root. На следующей неделе — проверка безопасности, а systemd-analyze security lab-tickets.service сейчас ставит службе 9.6 UNSAFE.

Заявки лежат в /var/lib/tickets, ключ API — в /etc/tickets/api.key. Учётную запись tickets для службы завёл пакет, но в юнит её так и не вписали. Как обращаться к службе, написано в /usr/share/doc/tickets-api/README:

curl -s http://127.0.0.1:8097/health
key=$(sudo cat /etc/tickets/api.key)
curl -s -H "X-Api-Key: $key" http://127.0.0.1:8097/tickets

Задача

lab-tickets работает и включена: прежние заявки на месте, новая заявка (POST /tickets) сохраняется в /var/lib/tickets. Код приложения прежний.
Процесс службы работает не от root, без привилегий и с NoNewPrivileges=yes. Ключ API может прочитать root и сама служба — больше никто.
ProtectSystem=strict: служба не может писать в /etc, /usr, /var/lib, /var/log и /opt.
systemd-analyze security lab-tickets.service — не выше 4.9, оценка OK.

Интернета на машине нет, всё нужное уже установлено. Команды администратора запускай через sudo.

Лаба · самостоятельно

Команды в этой лабе не даны: набирай их в терминале сам. Цели проверяются на машине после каждой команды.

Цели

0 из 4

lab-tickets работает и включена, прежние заявки на месте, новая сохраняется в /var/lib/tickets; код приложения прежний — ещё не выполнена
Процесс службы не root, без привилегий и с NoNewPrivileges; ключ API не может прочитать посторонний пользователь — ещё не выполнена
ProtectSystem=strict действует — служба не пишет в /etc, /usr, /var/lib, /var/log и /opt — ещё не выполнена
systemd-analyze security lab-tickets.service — не выше 4.9 (оценка OK) — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

0 из 4

lab-tickets работает и включена, прежние заявки на месте, новая сохраняется в /var/lib/tickets; код приложения прежний — ещё не выполнена
Процесс службы не root, без привилегий и с NoNewPrivileges; ключ API не может прочитать посторонний пользователь — ещё не выполнена
ProtectSystem=strict действует — служба не пишет в /etc, /usr, /var/lib, /var/log и /opt — ещё не выполнена
systemd-analyze security lab-tickets.service — не выше 4.9 (оценка OK) — ещё не выполнена

node1 Ubuntu 24.04

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Цели лабы

0 из 4

lab-tickets работает и включена, прежние заявки на месте, новая сохраняется в /var/lib/tickets; код приложения прежний — ещё не выполнена
Процесс службы не root, без привилегий и с NoNewPrivileges; ключ API не может прочитать посторонний пользователь — ещё не выполнена
ProtectSystem=strict действует — служба не пишет в /etc, /usr, /var/lib, /var/log и /opt — ещё не выполнена
systemd-analyze security lab-tickets.service — не выше 4.9 (оценка OK) — ещё не выполнена

Службы и systemd · подобрано по лабе

systemd

Шпаргалка

$_ — вставить в терминал

systemctl status nginx состояние
systemctl start nginx запустить сейчас
systemctl stop nginx остановить сейчас
systemctl enable nginx включить автозапуск
systemctl reload nginx перечитать конфиг без обрыва
systemctl daemon-reload после правки юнит-файлов
journalctl -u nginx -f логи службы в реальном времени
systemd-analyze blame тайминги загрузки

Юниты ищутся в (по возрастанию приоритета):

/lib/systemd/system/ — пакетные (не редактировать);
/etc/systemd/system/ — локальные переопределения (редактировать здесь).

Структура .service:

ini

[Unit]
Description=My App
After=network-online.target

[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

Drop-in: дополнение юнита

Юнит из пакета правят через drop-in: обновление пакета перезапишет сам файл юнита, а drop-in останется. Drop-in — файл .conf в каталоге /etc/systemd/system/<юнит>.d/. systemd читает юнит, затем drop-in'ы по алфавиту, и их строки дополняют или заменяют строки юнита.

bash

sudo systemctl edit nginx       # редактор; сохранит override.conf
sudo mkdir -p /etc/systemd/system/demo.service.d       # или руками:
printf '[Service]\nMemoryMax=256M\n' \
  | sudo tee /etc/systemd/system/demo.service.d/memory.conf
sudo systemctl daemon-reload    # перечитать юниты после ручных правок
systemctl cat demo              # юнит и все его drop-in'ы
systemctl show demo -p DropInPaths

systemctl edit сам делает daemon-reload. После ручной правки без daemon-reload systemd работает со старой версией юнита. Ключ вроде ExecStart= в drop-in'е добавляет вторую команду; чтобы заменить первую, перед новой строкой ставят пустую ExecStart=.

Ключ в чужой секции systemd пропускает: LimitNOFILE= под [Unit] не действует, служба получает лимит по умолчанию. Предупреждение видно в журнале после daemon-reload и в systemd-analyze verify — код у него всё равно 0:

bash

systemd-analyze verify /etc/systemd/system/demo.service

text

/etc/systemd/system/demo.service:3: Unknown key name 'LimitNOFILE' in
  section 'Unit', ignoring.

Активация сокетом

Юнит .socket держит порт вместо службы: systemd слушает сам и запускает одноимённую службу при первом соединении. Учебная пара — demo-sock.socket и demo-sock.service:

ini

# /etc/systemd/system/demo-sock.socket
[Socket]
ListenStream=8085

[Install]
WantedBy=sockets.target

# /etc/systemd/system/demo-sock.service
[Unit]
Requires=demo-sock.socket
After=demo-sock.socket

[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/demo-sock.py

ListenStream=8085 — только порт, без адреса: сокет слушает все адреса, IPv4 и IPv6. До первого запроса порт держит процесс systemd, служба inactive:

text

student@ubuntu:~$ sudo ss -tlnp | grep 8085
LISTEN 0  4096  *:8085  *:*  users:(("systemd",pid=1,fd=71))
student@ubuntu:~$ systemctl list-sockets | grep -E 'LISTEN|demo'
LISTEN     UNIT              ACTIVATES
[::]:8085  demo-sock.socket  demo-sock.service
student@ubuntu:~$ curl -s http://127.0.0.1:8085/
hello
student@ubuntu:~$ sudo ss -tlnp | grep 8085
LISTEN 0  4096  *:8085  *:*
  users:(("python3",pid=2769,fd=3),("systemd",pid=1,fd=71))

Адрес меняют drop-in'ом. ListenStream= — список: пустая строка сбрасывает адреса из юнита, без неё новый адрес добавится к старому.

bash

sudo mkdir -p /etc/systemd/system/demo-sock.socket.d
printf '[Socket]\nListenStream=\nListenStream=127.0.0.1:8085\n' \
  | sudo tee /etc/systemd/system/demo-sock.socket.d/local.conf
sudo systemctl daemon-reload
sudo systemctl restart demo-sock.socket
sudo ss -tlnp | grep 8085           # 127.0.0.1:8085

restart сокета перезапускает и службу с Requires= на него: MainPID службы сменился (2769 → 2838). Остановить одну службу мало — следующее соединение запустит её снова, а systemctl stop предупредит:

text

Stopping 'demo-sock.service', but its triggering units are still active:
demo-sock.socket

Закрыть порт совсем — sudo systemctl disable --now demo-sock.socket.

Цели (targets)

Цель — группа юнитов, до которой systemd доводит загрузку: multi-user.target у сервера, rescue.target и emergency.target для починки. Подробно — boot-targets.

bash

systemctl get-default              # текущая цель по умолчанию
sudo systemctl set-default multi-user.target
systemctl isolate rescue.target    # переключиться сейчас

Служба не стартует

systemctl status <unit> — код выхода и последние строки журнала.
journalctl -xeu <unit> — подробности с пояснениями.
После ручной правки юнита всегда sudo systemctl daemon-reload.

«Unit not found»

Проверь имя и путь: systemctl cat <unit>. Если правил файл — daemon-reload.

Долгая загрузка

systemd-analyze critical-chain — кто держал загрузку; порядок разбора — systemd-analyze.