Seccomp w Linux – jak ograniczyć możliwości procesów i zwiększyć bezpieczeństwo systemu

Bezpieczeństwo systemu Linux nie kończy się na firewallu, aktualizacjach czy odpowiednich uprawnieniach. Nawet poprawnie skonfigurowana aplikacja może zostać wykorzystana przez atakującego, jeśli po przejęciu procesu będzie miała pełny dostęp do funkcji oferowanych przez jądro systemu.

Tutaj pojawia się Seccomp (Secure Computing Mode) – mechanizm pozwalający kontrolować, z jakich wywołań systemowych (system calls, syscall) może korzystać proces.

To rozwiązanie jest powszechnie wykorzystywane przez:

• Docker,
• Kubernetes,
• Podman,
• Chrome,
• Firefox,
• systemd,
• wiele aplikacji działających w środowiskach produkcyjnych.

Seccomp nie chroni przed wszystkimi zagrożeniami, ale znacząco ogranicza możliwości napastnika, jeśli dojdzie do przejęcia procesu.

Czym jest Seccomp?

Seccomp to funkcja jądra Linux umożliwiająca filtrowanie wywołań systemowych wykonywanych przez proces.

Każdy program działający w Linux komunikuje się z jądrem za pomocą syscalli.

Przykładowo:

• otwarcie pliku,
• utworzenie procesu,
• otwarcie połączenia sieciowego,
• przydzielenie pamięci,
• zakończenie procesu,

to wszystko odbywa się właśnie poprzez wywołania systemowe.

Schemat wygląda następująco:

Aplikacja

↓

System Call (syscall)

↓

Kernel Linux

↓

Sprzęt

Seccomp działa pomiędzy aplikacją a jądrem.

Aplikacja

↓

Seccomp Filter

↓

Kernel

↓

Sprzęt

Jeżeli aplikacja spróbuje wykonać niedozwolony syscall, jądro może:

• zablokować operację,
• zakończyć proces,
• zwrócić błąd,
• zapisać zdarzenie w logach.

Dlaczego Seccomp jest potrzebny?

Nowoczesne jądro Linux udostępnia kilkaset syscalli.

Typowa aplikacja WWW wykorzystuje jedynie niewielką część z nich.

Na przykład serwer HTTP zwykle potrzebuje:

• odczytu plików,
• zapisu logów,
• obsługi sieci,
• pamięci operacyjnej.

Nie potrzebuje natomiast możliwości:

• ładowania modułów jądra,
• zmiany zegara systemowego,
• tworzenia nowych przestrzeni nazw,
• wykonywania operacji administracyjnych.

Ograniczenie dostępu do niepotrzebnych syscalli zmniejsza powierzchnię potencjalnego ataku.

Jak działa Seccomp?

Mechanizm wykorzystuje filtry BPF (Berkeley Packet Filter).

Podczas wykonywania syscalla kernel sprawdza przygotowane reguły.

Jeżeli wywołanie spełnia warunki:

Proces

↓

syscall

↓

Filtr Seccomp

↓

Dozwolony

↓

Kernel

Jeżeli nie:

Proces

↓

syscall

↓

Filtr Seccomp

↓

Odrzucony

↓

SIGSYS lub EPERM

Tryby działania Seccomp

Strict Mode

Najprostszy tryb.

Proces może korzystać wyłącznie z kilku podstawowych syscalli.

Między innymi:

• read
• write
• exit
• sigreturn

Każde inne wywołanie powoduje zakończenie procesu.

Jest to rozwiązanie bardzo restrykcyjne i obecnie stosowane rzadko.

Filter Mode

Najczęściej używany tryb.

Administrator lub aplikacja definiuje dokładnie, które syscall’e są dozwolone.

Przykład:

openat        ✔

read          ✔

write         ✔

execve        ✔

mount         ✖

ptrace        ✖

kexec_load    ✖

To właśnie z tego mechanizmu korzysta Docker.

Jak sprawdzić syscall’e procesu?

Jednym z najpopularniejszych narzędzi jest:

strace

Przykład:

strace ls

Wynik pokazuje kolejne syscall’e wykonywane przez proces.

Można zobaczyć między innymi:

• openat()
• mmap()
• read()
• write()
• close()

To bardzo przydatne podczas tworzenia własnych polityk Seccomp.

TIP administratora

Jeżeli aplikacja przestaje działać po włączeniu filtra Seccomp, pierwszym krokiem powinno być uruchomienie jej z strace. Pozwala to szybko zidentyfikować brakujące syscall’e i dostosować politykę bez zgadywania.

Seccomp w Dockerze

Docker domyślnie korzysta z profilu Seccomp.

Oznacza to, że wiele niebezpiecznych syscalli jest blokowanych automatycznie.

Przykładowo ograniczane są operacje związane z:

• ładowaniem modułów jądra,
• debugowaniem innych procesów,
• manipulacją pamięcią jądra,
• zmianą przestrzeni nazw.

Profil można wyłączyć:

docker run --security-opt seccomp=unconfined nginx

Nie jest to jednak zalecane w środowisku produkcyjnym.

Własny profil Seccomp

Docker umożliwia wykorzystanie własnego pliku JSON.

Przykład:

docker run \
--security-opt seccomp=my-profile.json \
nginx

Pozwala to bardzo precyzyjnie określić, z jakich syscalli może korzystać aplikacja.

Seccomp a Kubernetes

Kubernetes również obsługuje profile Seccomp.

Można przypisać je do konkretnego Poda.

Przykład:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Dzięki temu każdy kontener korzysta z domyślnego profilu bezpieczeństwa środowiska uruchomieniowego.

Seccomp i systemd

Systemd oferuje prostą integrację z Seccomp.

Przykład:

SystemCallFilter=@system-service

Można również blokować konkretne syscall’e:

SystemCallFilter=~mount

Oznacza to:

proces uruchomiony jako usługa systemd nie będzie mógł wykonywać operacji montowania systemów plików.

Warto wiedzieć

Dyrektywy SystemCallFilter, SystemCallArchitectures czy SystemCallErrorNumber pozwalają budować bardzo skuteczne polityki bezpieczeństwa bez konieczności ręcznego pisania filtrów BPF.

Seccomp a AppArmor i SELinux

To częste źródło nieporozumień.

Każdy z tych mechanizmów odpowiada za coś innego.

Największą skuteczność osiąga się, łącząc wszystkie te mechanizmy.

Ograniczenia Seccomp

Seccomp nie analizuje logiki aplikacji.

Nie wykryje:

• SQL Injection,
• XSS,
• błędów programistycznych,
• podatności w kodzie.

Kontroluje wyłącznie to, jakie syscall’e mogą zostać wykonane.

Dlatego należy traktować go jako kolejną warstwę ochrony, a nie jedyne zabezpieczenie.

Najczęstsze błędy administratorów

Wyłączanie Seccomp dla wygody

Podczas rozwiązywania problemów niektórzy uruchamiają kontenery z opcją:

--security-opt seccomp=unconfined

i zapominają przywrócić odpowiednią politykę.

W efekcie aplikacja działa z dużo większymi możliwościami niż jest to konieczne.

Brak testów po aktualizacji

Nowa wersja aplikacji może wykorzystywać dodatkowe syscall’e.

Dlatego każdą zmianę warto przetestować przed wdrożeniem na produkcję.

Stosowanie jednej polityki dla wszystkich usług

Serwer WWW, baza danych i broker komunikatów mają zupełnie inne wymagania.

Dobrą praktyką jest przygotowanie osobnych profili dla różnych typów aplikacji.

Najlepsze praktyki

• Korzystaj z domyślnego profilu Seccomp w Dockerze lub Kubernetes, jeśli nie masz własnej polityki.
• Twórz własne profile tylko wtedy, gdy rozumiesz wymagania aplikacji.
• Testuj nowe wersje oprogramowania przed wdrożeniem do produkcji.
• Łącz Seccomp z AppArmor lub SELinux, namespaces oraz cgroups v2.
• Regularnie analizuj syscall’e za pomocą strace, aby zrozumieć zachowanie aplikacji i wykrywać niepotrzebne uprawnienia.

Podsumowanie

Seccomp jest jednym z najważniejszych mechanizmów bezpieczeństwa współczesnego Linuxa. Dzięki filtrowaniu wywołań systemowych pozwala ograniczyć możliwości procesów do absolutnego minimum, zgodnie z zasadą least privilege.

Choć użytkownik często nawet nie zauważa jego działania, Seccomp odgrywa kluczową rolę w ochronie kontenerów, usług systemowych i aplikacji internetowych. W połączeniu z Linux Namespaces, cgroups v2, AppArmor lub SELinux tworzy solidny fundament bezpiecznego środowiska produkcyjnego.

Dla administratora zrozumienie działania Seccomp to nie tylko wiedza o jednym z mechanizmów jądra, ale także umiejętność budowania wielowarstwowej ochrony, która może znacząco ograniczyć skutki skutecznego ataku.

Polecane wpisy

Automatyzacja zadań z Cron w Linux: Planowanie skryptów i procesów

🕒 Automatyzacja zadań z Cron w Linux: Planowanie skryptów i procesów 🔍 Wprowadzenie do Crona Cron to jeden z najstarszych Czytaj dalej

Jak usunąć pliki lub foldery starsze niż 30 dni w BASH

Jak usunąć pliki lub foldery starsze niż 30 dni w BASH Usuwanie starych plików i folderów jest niezbędne do utrzymania Czytaj dalej