В НАЙС.ОС по умолчанию включены ключевые hardening-флаги, которые значительно повышают устойчивость системы к эксплуатации уязвимостей. Эти флаги активируют защитные механизмы на уровне бинарных файлов: PIE (перемещаемые исполняемые файлы), RELRO (защита таблиц GOT), SSP (Stack Smashing Protection), ASLR (рандомизация адресного пространства), FORTIFY_SOURCE (дополнительные проверки функций libc). Вместе они делают практически невозможным эксплуатацию типовых багов вроде переполнения буфера, возврата в libc или ROP-атак без сложных обходов. Эти защиты активированы как для системных сервисов, так и для пользовательских приложений, включая sudo, sshd, rpm, gpg. Пользователи получают безопасную по умолчанию систему, а разработчики — возможность собирать устойчивые к атакам приложения без лишних усилий.

1. Область применения

Требования настоящего документа распространяются на:

• системные пакеты и сервисы НАЙС.ОС, собираемые в RPM-окружении;
• прикладные бинарные файлы и библиотеки, распространяемые в составе решений на базе НАЙС.ОС;
• пользовательские проекты на C/C++ (а также смешанные проекты), собираемые на НАЙС.ОС.

Документ не заменяет регуляторные требования (сертификация, применение СКЗИ, контроль целостности и т.п.). Hardening рассматривается как инженерная мера снижения эксплуатационности уязвимостей класса memory corruption.

2. Термины, определения и сокращения

3. Модель угроз и цель hardening

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

• переполнение буфера (stack/heap), выход за границы массива (OOB);
• use-after-free (UAF), двойное освобождение, повреждение метаданных аллокатора;
• подмена адресов переходов/вызовов функций (return-to-libc, ROP/JOP);
• перезапись таблиц динамической линковки (GOT/PLT) и релокаций;
• выполнение внедрённого кода из данных (shellcode) при ошибках в проверках границ.

4. Механизмы hardening: состав и назначение

В НАЙС.ОС hardening рассматривается на трёх уровнях: компиляция, линковка, исполнение. Механизмы должны применяться согласованно.

5. Политика НАЙС.ОС: применение по умолчанию

В НАЙС.ОС hardening-флаги рассматриваются как базовая характеристика поставки. Системные пакеты должны собираться с включёнными защитными механизмами по умолчанию. Применение обеспечивается:

• глобальными RPM-макросами для компилятора и линковщика;
• единым набором %optflags и глобальных LDFLAGS;
• контролем соответствия в QA/CI для критических пакетов и образов.

Администратор может проверить эффективные флаги окружения сборки:

rpm --eval '%{optflags}'
rpm --eval '%{__global_cflags}'
rpm --eval '%{__global_cxxflags}'
rpm --eval '%{__global_ldflags}'

6. Проверка включённых механизмов

Проверка должна выполняться на уровне готовых ELF-объектов (исполняемые файлы и разделяемые библиотеки), а также на уровне параметров системы (для ASLR и смежных механизмов).

6.1 Автоматическая проверка (checksec)

Утилита checksec предоставляет агрегированное состояние защит ELF (RELRO, canary, NX, PIE, Fortify и др.).

checksec --file /usr/bin/sudo

Типовой набор атрибутов, который должен присутствовать у критических системных бинарников:

• RELRO: Full
• Canary: Yes
• NX: Enabled
• PIE: Enabled
• FORTIFY: Enabled (для динамических сборок при поддержке libc)

6.2 Автоматическая проверка (hardening-check)

Утилита hardening-check применяется для быстрого контроля соответствия набору требований hardening (характерна для практик дистрибутивной сборки и аудит-процедур).

hardening-check /usr/bin/ssh
hardening-check /usr/sbin/sshd

6.3 Ручная верификация ELF (readelf)

Проверка PIE (тип ELF):

readelf -h /usr/bin/ssh | egrep 'Type:|Entry point'

Для PIE характерен тип ET_DYN (в отличие от ET_EXEC у не-PIE исполняемых файлов).

Проверка RELRO (наличие сегмента GNU_RELRO):

readelf -l /usr/bin/ssh | grep -F 'GNU_RELRO' || true

Проверка «Full RELRO» (принудительное раннее связывание символов):

readelf -d /usr/bin/ssh | egrep 'BIND_NOW|FLAGS' || true

Проверка NX стека (GNU_STACK должен быть без флага E):

readelf -W -l /usr/bin/ssh | grep -F 'GNU_STACK' || true

6.4 Проверка ASLR (параметры ядра)

Для систем общего назначения обычно используется режим полной рандомизации адресного пространства. Проверка выполняется через sysctl-интерфейс ядра:

cat /proc/sys/kernel/randomize_va_space

7. Подключение hardening в собственных проектах

Рекомендуется централизованно задавать флаги через переменные окружения и/или настройки системы сборки. Ниже приведены минимально достаточные примеры. Конкретный профиль должен соответствовать политике сборки НАЙС.ОС.

7.1 Makefile

CFLAGS  += -O2 -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE
LDFLAGS += -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -pie

all: app
app: main.o
	$(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)

7.2 CMake

cmake_minimum_required(VERSION 3.16)
project(app C)

add_executable(app main.c)

target_compile_options(app PRIVATE
  -O2 -pipe
  -fstack-protector-strong
  -D_FORTIFY_SOURCE=2
  -fPIE
)

target_link_options(app PRIVATE
  -Wl,-z,relro
  -Wl,-z,now
  -Wl,-z,noexecstack
  -pie
)

7.3 Meson

project('app', 'c', default_options : ['buildtype=release'])

add_project_arguments(
  '-O2', '-pipe',
  '-fstack-protector-strong',
  '-D_FORTIFY_SOURCE=2',
  '-fPIE',
  language: 'c'
)

add_project_link_arguments(
  '-Wl,-z,relro',
  '-Wl,-z,now',
  '-Wl,-z,noexecstack',
  '-pie',
  language: 'c'
)

executable('app', 'main.c')

7.4 Autotools

export CFLAGS="-O2 -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE"
export LDFLAGS="-Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -pie"

./configure
make -j"$(nproc)"
make install

8. Ограничения и типовые конфликтные случаи

8.1 Производительность и старт процесса

• RELRO + -z now может увеличивать время старта процессов за счёт раннего разрешения символов.
• PIE добавляет косвенные издержки на адресацию; эффект зависит от архитектуры и профиля нагрузки.
• FORTIFY добавляет проверки, которые проявляются на горячих путях только при фактическом использовании защищаемых API.

8.2 Совместимость и особенности сборок

• Некоторые низкоуровневые компоненты (загрузчики, рантаймы, JIT, особые статические сборки) могут требовать специализированных профилей.
• Плагины, загружаемые сторонним рантаймом, требуют согласования флагов (PIE/PIC, visibility, LTO) на уровне всего графа зависимостей.
• FORTIFY требует оптимизаций компилятора (как минимум -O1) и поддержки соответствующей libc.

8.3 Отладка

PIE/ASLR усложняют анализ адресов при отладке. Для воспроизводимости допускается временное отключение рандомизации в отладочных сессиях (в рамках регламента разработки), без изменения production-профиля.

# пример для отладочной сессии
gdb -q ./app
(gdb) set disable-randomization on
(gdb) run

9. Контроль соответствия: CI/CD и аудит

Контроль соответствия должен быть автоматизирован и выполняться на артефактах сборки. Минимальный контроль включает:

• проверку критических бинарников на PIE/RELRO/NX/SSP/FORTIFY;
• контроль отсутствия RPATH/RUNPATH;
• проверку, что профиль сборки не деградировал при изменениях спеков/toolchain.

9.1 Пример: GitHub Actions

name: hardening-check

on:
  push:
  pull_request:

jobs:
  hardening:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          make -j"$(nproc)"

      - name: Check hardening (example)
        run: |
          checksec --file ./app || true
          hardening-check ./app || true

9.2 Пример: пакетная проверка каталога

set -euo pipefail

BIN_DIR="${1:-./bin}"

find "$BIN_DIR" -type f -maxdepth 1 -print0 | while IFS= read -r -d '' f; do
  if file "$f" | grep -q 'ELF'; then
    echo "==> $f"
    checksec --file "$f" || true
    hardening-check "$f" || true
  fi
done

10. Порядок исключений и документирование отклонений

Отклонение от профиля hardening допускается только при наличии технического обоснования и при соблюдении процедуры:

1. фиксируется причина (несовместимость, требование real-time, ограничение рантайма);
2. описывается область действия (конкретный бинарник/библиотека/модуль);
3. определяются компенсирующие меры (изоляция, sandbox, ограничение привилегий, конфигурация сервиса);
4. в CI добавляется отдельный контроль, подтверждающий, что исключение не расширилось на другие артефакты.

11. План развития

Политика hardening рассматривается как непрерывно развиваемая. При наличии поддержки со стороны toolchain и ядра могут расширяться следующие направления:

• аппаратные механизмы защиты управления потоком (включая CET — при наличии аппаратной и программной поддержки);
• усиление профилей компиляции для части C/C++ библиотек (включая дополнительные проверки стандартной библиотеки);
• расширение набора автоматических проверок (включая анализ RPATH/RUNPATH, запрет небезопасных флагов линковки);
• интеграция результатов hardening-сканирования в отчётность поставки (SBOM/аттестационные артефакты), при необходимости.

12. Приложения

12.1 Контрольный список (минимальный профиль)

12.2 Приложение: шаблон отчёта проверки

# Объект проверки:
#   Пакет/компонент:
#   Версия:
#   Сборка (git hash / release):
#   Дата:
#
# Команды:
#   checksec --file <path>
#   hardening-check <path>
#   readelf -h/-l/-d <path>
#
# Результаты:
#   PIE:
#   RELRO:
#   NX:
#   SSP:
#   FORTIFY:
#   RPATH/RUNPATH:
#
# Заключение:
#   Соответствует / Не соответствует
#   Отклонения (если есть) + обоснование

12.3 Ссылки (для сопровождения документа)

• ld(1) — описание линковочных опций семейства -z (RELRO, NOW, NOEXECSTACK и др.).
• checksec — инструмент проверки защит ELF (RELRO, NX, PIE, Fortify и др.).
• hardening-check — утилита быстрого контроля hardening-профиля.
• _FORTIFY_SOURCE — механизм усиленных проверок libc.

Заключение

Hardening-флаги являются обязательным инженерным уровнем защиты для системного и прикладного ПО в НАЙС.ОС. Корректная реализация включает: единый профиль сборки, верификацию артефактов, автоматический контроль в CI, формализованный порядок исключений. Такой подход снижает эксплуатационность типовых уязвимостей класса memory corruption без изменения функциональности программного кода.

Источники

• ld(1) man page: https://man7.org/linux/man-pages/man1/ld.1.html
• Пример вывода checksec (свойства RELRO/NX/PIE/Fortify): https://lib.rs/crates/checksec
• Описание практик Linux hardening (PIE/ASLR и др.): https://book.hashbang.sh/docs/security/linux_hardening/
• Документация hardening-check (Debian): (поиск/описание пакета) https://packages.debian.org/
• Документация glibc по FORTIFY_SOURCE: (справочные материалы glibc) https://sourceware.org/glibc/