Опубликовано: 07.10.2026 | Источник: Xakep.ru

Защита Linux-процессов в ВКР: перекрываем запуск через аргументы и переменные окружения

В разборе на «Хакере» от 27 марта 2026 года показан приём, ломающий запуск программы в Linux без правки бинарника и без возни с правами доступа. Атака бьёт по данным, которые процесс получает на старте: по аргументам командной строки и переменным окружения. Механика проста — ядро при вызове execve копирует argv и envp в свежую область стека, и как только одна строка вида «ИМЯ=значение» переваливает за MAX_ARG_STRLEN (32 страницы, то есть 128 КиБ на архитектуре x86_64), вызов падает с E2BIG. Ветка, унаследовавшая такое окружение, больше не запускает ничего.

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

Быстрые ответы: что чаще всего спрашивают на консультации

Законно ли вообще ставить такие эксперименты в рамках диплома?

Законно и нормально, если вы работаете в изолированном контуре: собственные виртуальные машины, локальный Docker или изолированный стенд в лаборатории кафедры. Никакого прода, никаких чужих хостов, никакой эксплуатации в сети вуза. В тексте работы обязательно зафиксируйте: среда эксперимента — изолированный полигон, сгенерированный заново после каждой итерации. Это снимает 90% вопросов комиссии и снимает риски по ст. 272 УК РФ.

Обязательно писать эксплойт на C или хватит Python и shell?

Отдельный код на C нужен только в одном сценарии: когда вы хотите показать поведение execve на уровне системного вызова и точно поймать E2BIG. Во всех остальных случаях хватит Python и shell — они отлично воспроизводят «отравление» окружения и наследование переменных. Зато модуль защиты на eBPF/LSM без C не напишете, это стоит заложить в смету задач с самого начала.

Нужна ли тут ML-модель? Вуз требует «интеллектуальности»

Не нужно втягивать нейросеть ради галочки. Гораздо убедительнее звучит гибрид: детерминированные правила по длине и структуре строк плюс статистический профиль нормального окружения (средняя длина переменной, число переменных, доля небуквенных символов). Если кафедра настаивает на ML — берите изолирующий лес или простую логистическую регрессию на 8–10 признаках и честно покажите, что выигрыш по F1 не перекрывает рост сложности сопровождения. Такой вывод комиссия любит больше, чем «мы прикрутили LSTM к системному вызову».

Какие метрики считать, чтобы защита выглядела доказанной?

Минимум четыре: доля ложных срабатываний (FPR), доля пропущенных атак (FNR), накладные расходы на один execve в микросекундах и коэффициент снижения успешных попыток блокировки запуска. Плюс одна интегральная — снижение риска недоступности сервиса, привязанное к характеристике Security из ISO/IEC 25010. Замеры делайте не на одном прогоне, а на серии из 30–50 повторов, иначе любой дотошный рецензент разобьёт ваши выводы одним вопросом про дисперсию.

Темы ВКР, которые вырастают из этого кейса

• Тема 1. Разработка подсистемы контроля запуска процессов в Linux на основе ограничений argv/envp.

  Актуальность: приём из статьи показывает, что стандартные механизмы прав доступа и мандатного контроля не закрывают вектор «переполнение параметров запуска». Цель: снизить риск отказа в обслуживании хоста, вызванного аномальными параметрами execve.

  Задачи: 1) разобрать лимиты ядра ARG_MAX, MAX_ARG_STRLEN и путь execve → bprm → E2BIG; 2) построить модель угроз по STRIDE и наложить её на CWE-400 и CWE-770; 3) реализовать перехватчик на eBPF/LSM и whitelist-политику окружения; 4) провести серию экспериментов и посчитать метрики.

  Структура: Глава 1 — теория и анализ вектора; Глава 2 — проектирование и реализация подсистемы; Глава 3 — методика испытаний, замеры, оценка эффекта.

• Тема 2. Сравнительный анализ механизмов изоляции и ограничения процессов в Linux применительно к защите от DoS через параметры запуска.

  Актуальность: разработчику предлагается не один инструмент на выбор, а целый зоопарк — seccomp, AppArmor, SELinux, лимиты systemd и cgroups. Нужен внятный критерий выбора, а не «нам так привычнее».

  Задачи: 1) сформировать матрицу критериев по ISO/IEC 25010 (безопасность, производительность, сопровождаемость); 2) собрать единый стенд для всех механизмов; 3) провести сравнительные замеры; 4) выработать рекомендации по комбинированию.

  Структура: Глава 1 — обзор механизмов и стандартов; Глава 2 — методика сравнения и стенд; Глава 3 — результаты, таблицы приоритетов, выводы.

• Тема 3. Автоматизация выявления аномальных параметров запуска в CI/CD-конвейере.

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

  Задачи: 1) проанализировать риски по OWASP Top 10 CI/CD Security Risks; 2) спроектировать шаг проверки окружения перед запуском джобов; 3) реализовать плагин и политику пайплайна; 4) оценить накладные расходы на конвейер и число предотвращённых сбоев.

  Структура: Глава 1 — анализ конвейеров и угроз; Глава 2 — архитектура решения и интеграция; Глава 3 — испытания, метрики, экономическая оценка.

Раскладка материала статьи по главам диплома

Глава 1: превращаем новостной кейс в аналитическую часть

Здесь кейс из «Хакера» работает как источник актуальности, но пересказом ограничиваться нельзя. Раскрутите цепочку до уровня ядра: do_execveat_common() считает суммарный размер argv+envp и ограничивает его через bprm_stack_limits(). Суммарный ARG_MAX на типовой конфигурации измеряется в мегабайтах, а вот на отдельную строку действует жёсткий предел в 32 страницы. Это и есть ключевая точка: одна переменная окружения длиной 140 КБ гарантированно валит execve с E2BIG, причём она спокойно переживает наследование через shell, sudo и менеджер сервисов.

Обязательно вставьте проверяемые команды: getconf ARG_MAX, xargs --show-limits, ulimit -s. Зафиксируйте результаты в таблице «Конфигурация стенда — измеренный предел». Это превратит главу из реферата в исследование. Модель угроз постройте по STRIDE и привяжите к MITRE ATT&CK (техника T1499, Endpoint Denial of Service) и к CWE-400/CWE-770.

Глава 2: проектирование и реализация

Архитектуру описывайте в нотации C4: контекст (администратор, хост, система мониторинга), контейнеры (перехватчик, хранилище политик, сборщик событий), компоненты (валидатор строк окружения, реестр whitelist, эмиттер метрик). Ниже — уровень потока данных DFD первого уровня, по ГОСТ 19.701-90 рисуете блок-схему алгоритма проверки перед разрешением запуска. Не смешивайте нотации в одном рисунке — это первая ошибка, на которой спотыкается нормоконтроль.

Глава 3: эксперимент, стенд и метрики

Стенд разворачивается скриптом, иначе воспроизводимость не докажете. Берёте базовый образ, фиксируете ядро, страницы по 4 КиБ, одинаковый лимит стека. Прогоняете сценарии: нормальное окружение, «раздутая» одна переменная, «раздутые» множество переменных в пределах суммарного лимита, легитимные длинные строки (например, вложенные JWT в переменной окружения — да, так тоже бывает). Считаете FPR и FNR именно на последнем сценарии, иначе защита окажется бесполезной в реальной эксплуатации.

Приложение: код и конфигурации

/* demo_e2big.c — воспроизводим отказ запуска через окружение */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>

int main(void) {
    const size_t len = 140 * 1024;          /* > MAX_ARG_STRLEN = 128 КиБ */
    char *blob = malloc(len + 16);
    if (!blob) return 2;

    memset(blob, 'A', len);
    memcpy(blob + len, "=x", 3);            /* формат ИМЯ=значение */

    char *envp[] = { blob, NULL };
    char *argv[] = { "/bin/true", NULL };

    execve(argv[0], argv, envp);
    perror("execve");                        /* ожидаем E2BIG (errno 7) */
    return 1;
}

# /etc/systemd/system/myservice.service.d/harden.conf
[Service]
# передаём только явно разрешённые переменные, остальное отсекаем
PassEnvironment=
EnvironmentFile=/etc/myservice/env.allow
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
TasksMax=256
LimitNOFILE=4096

#!/bin/sh
# audit-len.sh — ищем подозрительно длинные переменные окружения в /proc
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  [ -r "/proc/$pid/environ" ] || continue
  tr '\0' '\n' < "/proc/$pid/environ" 2>/dev/null | awk -v p="$pid" '
    { n = length($0); if (n > 8192) printf "PID %s: строка %d байт\n", p, n }'
done

Метрики: чем доказать, что защита работает

Чему вы научитесь

• Воспроизводить поведение ядра на границе лимитов ARG_MAX и MAX_ARG_STRLEN и подтверждать его замерами, а не цитатами из документации.
• Проектировать систему контроля запуска процессов с описанием в C4 и схемами по ГОСТ 19.701-90.
• Настраивать ограничения окружения средствами systemd, PAM и LSM-хуков, понимая, где какой механизм уместен.
• Считать метрики качества защиты по характеристикам ISO/IEC 25010 и оформлять их в таблицы, готовые к защите.
• Оценивать накладные расходы внедрения — тот самый аргумент, который отличает инженера от рефератчика.

Источник: Мощные аргументы. Блокируем запуск процессов в Linux через переменные окружения (опубликовано 2026-03-27)