Модуль 4.4: Профілі Seccomp

Безпека Linux | Складність: [MEDIUM] | Час: 25–30 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 2.3: Capabilities та LSM
Обов’язково: Модуль 1.1: Архітектура ядра (розуміння системних викликів).
Бажано: Розуміння концепції BPF.

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Написати власні профілі seccomp, що дозволяють лише ті системні виклики, які потрібні контейнеру
Застосувати профілі seccomp до подів Kubernetes через security context
Дебажити порушення seccomp, відстежуючи заблоковані syscalls за допомогою strace та аудит-логів
Оцінити стандартний профіль seccomp Docker/containerd та вирішити, коли потрібен власний профіль

Чому цей модуль важливий

seccomp (Secure Computing Mode) фільтрує системні виклики (syscalls) на рівні ядра. На відміну від AppArmor чи SELinux, які контролюють доступ до ресурсів (файлів, мережі), seccomp контролює, чи може процес взагалі викликати певні функції ядра.

Розуміння seccomp допоможе вам:

Радикально зменшити поверхню атаки — повністю заборонити небезпечні виклики.
Зміцнювати контейнери — стандартні профілі Docker/K8s блокують ~44 небезпечні системні виклики.
Скласти іспит CKS — робота з профілями seccomp є важливою частиною.
Діагностувати помилки “Operation not permitted” — коли навіть прав root замало.

Коли контейнер видає помилку при спробі виконати дію, яку root зазвичай може робити — причиною часто є seccomp, що блокує відповідний виклик до ядра.

Як працює seccomp

Фільтрація системних викликів

┌─────────────────────────────────────────────────────────────┐
│                    SECCOMP ФІЛЬТРАЦІЯ                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Додаток (User Space)                                       │
│       │                                                     │
│       │ write(fd, buf, size)                                │
│       │                                                     │
│       ▼                                                     │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                SECCOMP BPF ФІЛЬТР                   │   │
│  │                                                     │   │
│  │   якщо (syscall_nr == SYS_write)  → ДОЗВОЛИТИ       │   │
│  │   якщо (syscall_nr == SYS_ptrace) → ВБИТИ           │   │
│  │   якщо (syscall_nr == SYS_reboot) → ПЕРЕДАТИ ПОМИЛКУ│   │
│  │                                                     │   │
│  └─────────────────────────────────────────────────────┘   │
│       │                                                     │
│       ▼                                                     │
│  Ядро Linux виконує виклик (якщо дозволено)                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Seccomp у контейнерах та Kubernetes

Стандартний профіль Docker

Docker автоматично застосовує профіль, який блокує небезпечні виклики, як-от mount, reboot, ptrace (відладка інших процесів) та завантаження модулів ядра.

Kubernetes seccomp

В Kubernetes ви можете вказати профіль для всього Пода або конкретного контейнера:

apiVersion: v1
kind: Pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault    # Використовувати стандартний профіль рантайму
  containers:
  - name: secure-app
    image: nginx

Варіанти профілів:

RuntimeDefault: Стандартний захист (рекомендовано).
Localhost: Ваш власний JSON-профіль, що лежить на вузлі.
Unconfined: Жодних фільтрів (небезпечно!).

Тест

У чому головна різниця між seccomp та AppArmor?

Відповідь
Seccomp фільтрує самі системні виклики (функції ядра), тоді як AppArmor фільтрує доступ до об'єктів системи (шляхів до файлів, портів тощо).
Яка технологія використовується для реалізації фільтрів seccomp?

Відповідь
BPF (Berkeley Packet Filter) — та сама високоефективна технологія, що використовується для фільтрації мережевих пакетів.
Що станеться з процесом, якщо він спробує виконати системний виклик, заборонений дією SCMP_ACT_KILL?

Відповідь
Ядро Linux миттєво вб'є цей процес або конкретний потік (thread), що зробив виклик.
Де в Kubernetes мають лежати файли кастомних профілів seccomp на вузлі?

Відповідь
За замовчуванням у директорії `/var/lib/kubelet/seccomp/`.

Практична вправа

Завдання: Перевірити статус seccomp для процесу.

Перевірте, чи підтримує ваше ядро seccomp:
Terminal window
```
grep SECCOMP /boot/config-$(uname -r)
```
Подивіться статус seccomp вашої поточної оболонки:
Terminal window
```
grep Seccomp /proc/$$/status
# 0 = вимкнено, 2 = фільтрація (mode 2)
```
Запустіть контейнер Docker і перевірте статус seccomp всередині нього:
Terminal window
```
docker run --rm alpine grep Seccomp /proc/1/status
```

Критерії успіху: Ви бачите, що процеси в контейнерах за замовчуванням працюють під наглядом seccomp (статус 2).

Підсумок

seccomp — останній рубіж захисту на рівні ядра.
Syscall filtering — блокування функцій ядра, а не файлів.
RuntimeDefault — обов’язковий мінімум для будь-якого пода в продакшні.
Помилки seccomp зазвичай проявляються як “Operation not permitted”.

Вітаємо! Ви завершили розділ «Безпека та зміцнення». Тепер ви знаєте, як захистити систему на рівні ядра, файлів та системних викликів.

Далі: Розділ 5: Продуктивність (Performance) — навчіться аналізувати та оптимізувати ресурси вашого сервера.