Návody 20 min čítania

Kompletný sprievodca AppArmor na Linuxe: Povinná kontrola prístupu od základov po kontajnerovú bezpečnosť

Praktický sprievodca AppArmor na Linuxe — architektúra, tvorba profilov, AppArmor 4.0 novinky, Docker a Kubernetes integrácia, Wazuh monitoring a reálne scenáre ochrany pred útokmi na serveroch.

Editorial Team

Úvod: Prečo vaše Linux servery potrebujú povinné riadenie prístupu

Máte správne nakonfigurovaný firewall pomocou nftables, SSH je zabezpečené podľa najnovších štandardov, Wazuh monitoruje každú udalosť na vašej infraštruktúre a kontajnery bežia v rootless režime. Znie to perfektne, však? Ale čo sa stane, keď sa útočník dostane dovnútra cez zraniteľnosť v aplikácii? Čo keď kompromitovaný webový server začne pristupovať k súborom, ku ktorým by nikdy nemal mať prístup?

Tu štandardné Linuxové oprávnenia jednoducho zlyhávajú.

Takzvaný Discretionary Access Control (DAC) je založený na princípe, že vlastník súboru rozhoduje o prístupe. Ak proces beží pod používateľom, ktorý má prístup k súboru, nič mu nezabráni ho čítať, zapisovať alebo spustiť. A to je presne ten problém, ktorý rieši Mandatory Access Control (MAC).

V ekosystéme Linuxu existujú dva hlavné MAC systémy: SELinux a AppArmor. Zatiaľ čo SELinux je predvolený na distribúciách rodiny Red Hat (RHEL, Fedora, CentOS), AppArmor dominuje na Ubuntu, Debian a SUSE. Podľa štatistík z roku 2025 má viac ako 86 % Ubuntu serverov AppArmor povolený v predvolenom nastavení. A keďže Canonical uvádza, že viac ako 60 % verejných cloudových Linux inštancií beží na Ubuntu, AppArmor je de facto MAC framework za obrovským podielom cloudových workloadov.

V tomto článku sa ponoríme do AppArmoru — od jeho fungovania a architektúry, cez praktické vytváranie a správu bezpečnostných profilov, až po integráciu s Docker kontajnermi a najnovšie vylepšenia v Ubuntu 24.04 LTS. Ak ste čítali naše predchádzajúce články o nftables, Wazuh alebo zabezpečení kontajnerov, AppArmor je ďalšia vrstva, ktorú musíte mať vo svojom bezpečnostnom arzenáli.

Čo je AppArmor a ako funguje

AppArmor (Application Armor) je bezpečnostný modul jadra Linuxu, ktorý implementuje povinné riadenie prístupu na úrovni jednotlivých aplikácií. Na rozdiel od tradičných DAC oprávnení, kde root môže takmer čokoľvek, AppArmor vynucuje pravidlá, ktoré musia dodržiavať aj privilegovaní používatelia.

Prístup založený na cestách

Kľúčový rozdiel medzi AppArmor a SELinux je v modeli riadenia prístupu. SELinux používa label-based model — každému objektu v systéme priradí bezpečnostný kontext. AppArmor naopak používa path-based model — pravidlá sa definujú na základe ciest k súborom. A to prináša zásadnú výhodu: profily sú čitateľné pre človeka a jednoducho sa píšu.

Prakticky to znamená, že namiesto práce s abstraktnými bezpečnostnými kontextami ako system_u:system_r:httpd_t:s0 v SELinux, v AppArmor jednoducho napíšete:

/usr/sbin/nginx {
    /var/www/html/** r,
    /var/log/nginx/** w,
    /etc/nginx/** r,
}

Čitateľné, pochopiteľné, udržovateľné. To je celá podstata AppArmoru.

Režimy profilov

Každý AppArmor profil môže byť v jednom z dvoch režimov:

  • Enforce (vynucovací) — profil aktívne blokuje nepovolené operácie a zaznamenáva pokusy o ich porušenie. Toto je váš produkčný režim.
  • Complain (sťažnostný) — profil neblokuje žiadne operácie, iba zaznamenáva porušenia do logu. Ideálny na testovanie a ladenie nových profilov.

Tento dvojrežimový prístup je obrovská výhoda oproti SELinux, kde je prechod medzi režimami zložitejší a kde administrátori z frustrácie často SELinux jednoducho vypnú úplne. Úprimne, to som videl nespočetne veľakrát. AppArmor je navrhnutý tak, aby ste ho nikdy nemuseli vypnúť.

Architektúra systému

AppArmor sa skladá z niekoľkých kľúčových komponentov:

  • Modul jadra — súčasť mainline jadra Linuxu od verzie 2.6.36, vykonáva vynucovanie bezpečnostných pravidiel
  • Parser (apparmor_parser) — kompiluje textové profily do binárnej formy a načítava ich do jadra
  • Profily — textové súbory v /etc/apparmor.d/ definujúce pravidlá pre jednotlivé aplikácie
  • Utility — príkazové nástroje ako aa-status, aa-enforce, aa-complain, aa-genprof a ďalšie

Pri štarte systému systemd volá apparmor_parser na načítanie profilov z vyrovnávacej pamäte /etc/apparmor/earlypolicy/. Keď nie je nakonfigurovaná včasná politika, systemd unit súbor AppArmoru načíta zvyšné profily neskôr v procese bootovania.

Inštalácia a overenie stavu AppArmor

Na väčšine moderných distribúcií je AppArmor buď predinštalovaný, alebo ho môžete jednoducho nainštalovať. Poďme si prejsť najčastejšie scenáre.

Ubuntu 22.04/24.04 LTS

Na Ubuntu je AppArmor nainštalovaný a povolený v predvolenom nastavení. Stačí overiť stav a doinštalovať užitočné utility:

# Overenie, že AppArmor beží
sudo aa-status

# Inštalácia rozšírených utilít a profilov
sudo apt install apparmor-utils apparmor-profiles apparmor-profiles-extra

# Výstup aa-status zobrazí niečo ako:
# apparmor module is loaded.
# 47 profiles are loaded.
# 32 profiles are in enforce mode.
# 15 profiles are in complain mode.
# 12 processes have profiles defined.
# 10 processes are in enforce mode.
# 2 processes are in complain mode.

Debian 12 (Bookworm)

Debian tiež štandardne obsahuje AppArmor, ale niektoré utility a rozšírené profily treba doinštalovať:

# Inštalácia AppArmor utilít
sudo apt install apparmor-utils apparmor-profiles apparmor-profiles-extra

# Overenie, že je AppArmor povolený v GRUB
grep "apparmor" /proc/cmdline
# Ak nie je povolený, pridajte do GRUB:
# GRUB_CMDLINE_LINUX="apparmor=1 security=apparmor"
# sudo update-grub && sudo reboot

openSUSE / SLES

SUSE distribúcie majú AppArmor ako predvolený MAC systém s rozsiahlou dokumentáciou a nástrojmi YaST na grafickú správu profilov:

# Overenie stavu na SUSE
sudo systemctl status apparmor
sudo aa-status

# Inštalácia nástrojov (ak nie sú prítomné)
sudo zypper install apparmor-utils apparmor-profiles

Poznámka: openSUSE Tumbleweed vo februári 2025 prešiel na SELinux ako predvolený MAC systém. Ak používate Tumbleweed a chcete AppArmor, budete ho musieť nakonfigurovať manuálne.

Arch Linux

Na Arch Linux musíte AppArmor nainštalovať a povoliť manuálne (typický Arch, že?):

# Inštalácia
sudo pacman -S apparmor

# Povolenie a spustenie služby
sudo systemctl enable --now apparmor.service

# Pridanie do parametrov jadra
# Upravte /etc/default/grub:
# GRUB_CMDLINE_LINUX="apparmor=1 lsm=landlock,lockdown,yama,integrity,apparmor,bpf"
sudo grub-mkconfig -o /boot/grub/grub.cfg

Správa existujúcich profilov

Predtým, než začneme vytvárať vlastné profily, naučme sa pracovať s tými existujúcimi. Ubuntu a Debian dodávajú desiatky hotových profilov pre bežné služby a bola by škoda ich nevyužiť.

Zobrazenie stavu profilov

# Kompletný prehľad všetkých profilov a ich režimov
sudo aa-status

# Zobrazenie profilov v enforce režime
sudo aa-status --enforced

# Zobrazenie profilov v complain režime
sudo aa-status --complaining

# Kontrola konkrétneho profilu
sudo aa-status | grep nginx

Prepínanie medzi režimami

# Prepnutie profilu do complain režimu (iba loguje, neblokuje)
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Prepnutie profilu do enforce režimu (blokuje a loguje)
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Vypnutie profilu (odporúčam iba na diagnostiku)
sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

# Opätovné načítanie profilu po úprave
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# Načítanie všetkých profilov nanovo
sudo systemctl reload apparmor

Kontrola logov porušení

Keď AppArmor zablokuje operáciu alebo zaznamená porušenie v complain režime, informácie nájdete v systémových logoch:

# Zobrazenie AppArmor správ v systémovom logu
sudo dmesg | grep apparmor

# Alebo v syslog / journal
sudo journalctl -k | grep apparmor

# Na Ubuntu a Debian sa logy zvyčajne nachádzajú aj v:
sudo cat /var/log/syslog | grep apparmor

# Príklad záznamu o zablokovanom prístupe:
# [12345.678] audit: type=1400 audit(1234567890.123:456):
# apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
# name="/etc/shadow" pid=1234 comm="nginx"
# requested_mask="r" denied_mask="r" fsuid=33 ouid=0

Vidíte ten výstup? Proces nginx sa pokúsil čítať /etc/shadow a AppArmor mu to zamietol. Presne toto je typ ochrany, ktorú chceme — a ktorá vám v noci pomôže lepšie spať.

Vytváranie vlastných profilov

Hotové profily sú výborný začiatok, ale skutočná sila AppArmoru sa prejaví pri vytváraní vlastných profilov pre vaše aplikácie. AppArmor poskytuje dva hlavné nástroje: aa-genprof na generovanie nových profilov a aa-logprof na ich aktualizáciu.

Generovanie profilu pomocou aa-genprof

Nástroj aa-genprof je v podstate inteligentný wrapper okolo aa-logprof. Vytvorí prázdny profil, načíta ho v complain režime a potom interaktívne sleduje správanie aplikácie, aby navrhol pravidlá.

Predpokladajme, že chceme vytvoriť profil pre vlastný Python skript /opt/myapp/server.py:

# Krok 1: Spustite aa-genprof (v jednom termináli)
sudo aa-genprof /opt/myapp/server.py

# Zobrazí sa výzva:
# Setting /opt/myapp/server.py to complain mode.
# Please start the application to be profiled in another window
# and exercise its functionality now.

# Krok 2: V DRUHOM termináli spustite a používajte aplikáciu
python3 /opt/myapp/server.py
# Prechádzajte všetky funkcie — HTTP požiadavky, zápis logov,
# čítanie konfigurácie, prístup k databáze atď.

# Krok 3: Vráťte sa do prvého terminálu a stlačte S (Scan)
# aa-genprof analyzuje logy a navrhne pravidlá:
#
# Profile:  /opt/myapp/server.py
# Path:     /opt/myapp/config.yaml
# Old Mode: (none)
# New Mode: r
# [1 - /opt/myapp/config.yaml]
#
# (A)llow / (D)eny / (I)gnore / (G)lob / (N)ew / ...

# Krok 4: Pre každý prístup zvoľte akciu:
# A = povoliť prístup (pridá pravidlo do profilu)
# D = zakázať prístup (pridá deny pravidlo)
# G = globovať cestu (napr. /opt/myapp/*.yaml)
# I = ignorovať (nepridá žiadne pravidlo)

# Krok 5: Po dokončení stlačte F (Finish)
# Profil sa prepne do enforce režimu

Manuálne písanie profilu

Pre plnú kontrolu môžete profil napísať ručne. Tu je príklad komplexného profilu pre webovú aplikáciu:

# /etc/apparmor.d/opt.myapp.server
#include <tunables/global>

/opt/myapp/server.py {
    # Zahrnutie základných abstrakcií
    #include <abstractions/base>
    #include <abstractions/nameservice>
    #include <abstractions/openssl>

    # Spustiteľné súbory
    /usr/bin/python3* ix,
    /opt/myapp/server.py r,

    # Konfiguračné súbory (iba čítanie)
    /opt/myapp/config/** r,
    /opt/myapp/templates/** r,
    /opt/myapp/static/** r,

    # Dátové súbory (čítanie a zápis)
    /opt/myapp/data/** rw,

    # Logy (iba zápis a pripájanie)
    /var/log/myapp/** w,
    /var/log/myapp/ r,

    # Sieťový prístup
    network inet stream,
    network inet dgram,
    network inet6 stream,

    # Dočasné súbory
    /tmp/myapp-* rw,
    owner /tmp/myapp-*/ rw,

    # Zakázané operácie (explicitné deny)
    deny /etc/shadow r,
    deny /etc/passwd w,
    deny /root/** rwx,
    deny /home/** rwx,

    # Zakázanie mount operácií
    deny mount,

    # Python knižnice (iba čítanie)
    /usr/lib/python3/** r,
    /usr/lib/python3/dist-packages/** r,
    /opt/myapp/venv/** r,
    /opt/myapp/venv/bin/python3 ix,
}

Syntax profilových pravidiel

Pochopenie syntaxe je kľúčové pre efektívne písanie profilov. Tu sú najdôležitejšie prvky:

  • Oprávnenia na súbory: r (čítanie), w (zápis), a (pripájanie), x (spustenie), m (mmap so spustením), l (odkaz/link), k (uzamknutie/lock)
  • Glob vzory: * (jeden segment cesty), ** (ľubovoľný počet segmentov), {bin,sbin} (alternatívy), [0-9] (znakové triedy)
  • Modifikátory spustenia: ix (zdedí rodičovský profil), px (použije vlastný profil), ux (beží bez obmedzenia), cx (lokálny profil)
  • Sieťové pravidlá: network inet stream (TCP), network inet dgram (UDP), network inet6 (IPv6)
  • Capability: capability net_bind_service (viazanie na privilegované porty), capability dac_override (obchádzanie DAC kontroly)

Aktualizácia profilu pomocou aa-logprof

Po nasadení profilu v produkčnom prostredí sa môžete stretnúť so situáciami, keď aplikácia potrebuje prístup k novým zdrojom. Namiesto manuálnej úpravy profilu použite aa-logprof — ušetrí vám to kopec času:

# Prepnite profil dočasne do complain režimu
sudo aa-complain /etc/apparmor.d/opt.myapp.server

# Nechajte aplikáciu bežať a generovať logy porušení

# Spustite aa-logprof na analýzu logov
sudo aa-logprof

# Nástroj interaktívne navrhne úpravy profilu
# na základe zaznamenaných porušení

# Po schválení zmien prepnite späť do enforce režimu
sudo aa-enforce /etc/apparmor.d/opt.myapp.server

Dôležité upozornenie: Pravidlá deny sú vynucované aj v complain režime. Ak aplikácia nefunguje správne ani v complain režime, skontrolujte, či niektoré deny pravidlo v profile alebo v zahrnutých abstrakciách neblokuje potrebný prístup. Toto je jedna z tých vecí, ktorá vás dokáže zaskočiť, ak o nej neviete.

AppArmor 4.0: Novinky v Ubuntu 24.04 LTS

Ubuntu 24.04 LTS prinieslo AppArmor 4.0 — najväčšiu aktualizáciu za posledné roky. A musím povedať, že novinky stoja za pozornosť.

Detailné sieťové politiky

Jedna z najvýznamnejších noviniek je možnosť špecifikovať povolené sieťové adresy a porty priamo v bezpečnostnej politike. V predchádzajúcich verziách ste mohli kontrolovať iba vysokoúrovňové protokoly (TCP/UDP). AppArmor 4.0 umožňuje oveľa granulárnejšiu kontrolu:

# AppArmor 4.0 - detailné sieťové pravidlá
/usr/sbin/myservice {
    # Povolenie pripojenia iba na konkrétny port a adresu
    network inet stream,

    # Nové v 4.0: špecifikácia adries a portov
    # (syntax sa môže líšiť podľa finálnej verzie)
    network inet stream bind 0.0.0.0:8443,
    network inet stream connect 10.0.0.0/8:5432,
}

Obmedzenie neprivilegovaných menných priestorov

Toto je asi najambicióznejšia bezpečnostná funkcia Ubuntu 24.04 — obmedzenie neprivilegovaných user namespaces prostredníctvom AppArmoru. Neprivilegované menné priestory sú výkonný mechanizmus jadra, ktorý umožňuje procesom získať dodatočné schopnosti v izolovanom prostredí. Problém? Útočníci ho často zneužívajú na eskaláciu privilégií.

Ubuntu 24.04 implementuje nasledovné zmeny:

  • Predvolené povolenie parametra kernel.apparmor_restrict_unprivileged_userns=1
  • Aplikácie musia mať explicitné AppArmor profily s pravidlom userns na vytvorenie menných priestorov
  • Zavedenie nového default_allow profilu pre aplikácie, ktoré menné priestory potrebujú (Firefox, Chrome, Flatpak)
# Overenie stavu obmedzenia menných priestorov
sysctl kernel.apparmor_restrict_unprivileged_userns
# Výstup: kernel.apparmor_restrict_unprivileged_userns = 1

# Povolenie dodatočného obmedzenia (odporúčané po Qualys objavoch)
sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=1

# Trvalé nastavenie
echo "kernel.apparmor_restrict_unprivileged_unconfined=1" | \
    sudo tee /etc/sysctl.d/99-apparmor-userns.conf
sudo sysctl --system

Bezpečnostné objavy Qualys (2025)

V prvom štvrťroku 2025 bezpečnostný tím Qualys identifikoval tri metódy obchádzania obmedzení neprivilegovaných menných priestorov v Ubuntu 24.04. Je dôležité o nich vedieť, aby ste mohli implementovať príslušné mitigácie:

  1. Obchádzanie cez aa-exec — útočník mohol použiť nástroj aa-exec na prepnutie do predkonfigurovaných AppArmor profilov (Chrome, Flatpak), ktoré povoľujú menné priestory s plnými administrátorskými schopnosťami.
  2. Obchádzanie cez busybox — spustenie busybox shellu umožňovalo prechod do AppArmor profilov s vyššími oprávneniami.
  3. Obchádzanie cez LD_PRELOAD — načítanie škodlivej knižnice pred spustením programu (napríklad Nautilus) umožňovalo prístup k permisívnejším profilom.

Mitigácia: Povolením kernel.apparmor_restrict_unprivileged_unconfined=1 zabránite neobmedzeným procesom využívať permisívne profily. Ubuntu 25.04 a novšie verzie majú toto nastavenie povolené v predvolenom stave.

AppArmor a Docker kontajnery

Ak prevádzkujete Docker kontajnery — a buďme úprimní, v roku 2026 to robí takmer každý — AppArmor je jednou z kľúčových vrstiev ich zabezpečenia. Docker má natívnu integráciu s AppArmor a bola by škoda ju nevyužívať.

Predvolený profil docker-default

Docker automaticky generuje a načítava predvolený profil docker-default pre všetky kontajnery. Tento profil:

  • Zakazuje zápis do /proc/sys
  • Zakazuje zápis do /sys (okrem /sys/fs/cgroup)
  • Zakazuje pripájanie súborových systémov (mount)
  • Zakazuje prístup k raw socketom
  • Zakazuje načítavanie modulov jadra

Profil docker-default je stredne prísny — poskytuje rozumnú ochranu pri širokej kompatibilite s aplikáciami. Pre produkčné nasadenia ale odporúčam vytvoriť vlastné, prísnejšie profily. Ten predvolený je dobrý štart, no nie je dostatočný.

Vytvorenie vlastného Docker profilu

Povedzme, že prevádzkujete Nginx kontajner a chcete preň prísnejší profil:

# /etc/apparmor.d/containers/docker-nginx
#include <tunables/global>

profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
    #include <abstractions/base>

    # Sieťový prístup
    network inet stream,
    network inet6 stream,
    network inet dgram,
    network inet6 dgram,

    # Nginx binárka a konfigurácia
    /usr/sbin/nginx ix,
    /etc/nginx/** r,

    # Webový obsah (iba čítanie)
    /usr/share/nginx/html/** r,
    /var/www/html/** r,

    # Logy
    /var/log/nginx/** w,

    # PID a lock súbory
    /var/run/nginx.pid rw,
    /run/nginx.pid rw,

    # Dočasné súbory pre proxy a cache
    /var/cache/nginx/** rw,
    /tmp/** rw,

    # Systémové knižnice
    /lib/** r,
    /usr/lib/** r,

    # Proc filesystem (obmedzené)
    /proc/*/status r,
    /proc/sys/net/core/somaxconn r,

    # Zakázané operácie
    deny /etc/shadow r,
    deny /etc/passwd w,
    deny /root/** rwx,
    deny mount,
    deny /proc/sys/** w,
    deny /sys/** w,

    # Capability
    capability net_bind_service,
    capability setuid,
    capability setgid,
    capability dac_override,
}
# Načítanie profilu
sudo apparmor_parser -r /etc/apparmor.d/containers/docker-nginx

# Spustenie kontajnera s vlastným profilom
docker run -d \
    --name nginx-secure \
    --security-opt apparmor=docker-nginx \
    -p 443:443 \
    nginx:latest

# Overenie, že kontajner používa správny profil
docker inspect nginx-secure | grep -i apparmor
# "AppArmorProfile": "docker-nginx"

Testovanie Docker profilu

Po nasadení profilu ho otestujte pokusmi o nepovolené operácie. Toto je krok, ktorý veľa ľudí preskočí — nebuďte jedným z nich:

# Pokus o čítanie /etc/shadow z kontajnera
docker exec nginx-secure cat /etc/shadow
# cat: /etc/shadow: Permission denied

# Pokus o mount operáciu
docker exec nginx-secure mount -t tmpfs tmpfs /mnt
# mount: permission denied

# Pokus o zápis do /proc/sys
docker exec nginx-secure sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
# sh: /proc/sys/net/ipv4/ip_forward: Permission denied

# Kontrola logov na potvrdenie blokovaných operácií
sudo dmesg | tail -20 | grep apparmor

AppArmor a Kubernetes

Od Kubernetes verzie 1.31 je podpora AppArmor profilov stabilná a predvolene povolená. Profily sa špecifikujú priamo v Pod špecifikácii:

apiVersion: v1
kind: Pod
metadata:
  name: secure-nginx
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: docker-nginx
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Pre správne fungovanie musí byť profil docker-nginx načítaný na každom uzle klastra, kde by mohol Pod bežať. Na to nezabudnite — je to častý zdroj problémov pri nasadzovaní.

AppArmor verzus SELinux: Kedy čo použiť

Otázka „AppArmor alebo SELinux?" sa objavuje pravidelne v každej diskusii o zabezpečení Linuxu. Tak si to poďme rozobrať.

Kedy zvoliť AppArmor

  • Používate Ubuntu, Debian alebo SUSE distribúcie
  • Preferujete jednoduchšiu syntax a rýchlejšie nasadenie
  • Nepotrebujete Multi-Level Security (MLS) ani Multi-Category Security (MCS)
  • Chcete MAC systém, ktorý váš tím skutočne bude používať a nie vypne z frustrácie
  • Prevádzkujete cloudové workloady na Ubuntu (60 %+ verejných cloudových inštancií)

Kedy zvoliť SELinux

  • Používate RHEL, Fedora alebo CentOS distribúcie
  • Požiadavky na zhodu (compliance) vyžadujú MLS/MCS — typicky vládne a obranné prostredia
  • Potrebujete fine-grained type enforcement a Role-Based Access Control (RBAC)
  • Prevádzkujete Azure Kubernetes Service (AKS) — Azure Linux 3.0 odporúča SELinux

Štatistiky z praxe (2025)

Zaujímavé dáta o adopcii MAC systémov:

  • Vynucovanie SELinux a AppArmor dosiahlo 55,6 % naprieč enterprise Linux prostrediami
  • Rozdelenie: približne 43 % SELinux (rodina RHEL) a 50 % AppArmor (Ubuntu a Debian)
  • Správa CNCF z roku 2024 zistila 3-násobný pokles pokusov o eskaláciu privilégií pri použití SELinux type enforcement v kontajneroch
  • Canonical odhaduje 70 % a viac zníženie rizika exploitácie pri použití MAC vynucovania na úrovni jadra

Záver je jednoznačný: používajte MAC systém natívny pre vašu distribúciu. Úprimne, nepoužívať žiadny MAC systém nie je v roku 2026 akceptovateľná možnosť.

Praktické scenáre zabezpečenia

Dosť bolo teórie. Pozrime sa na niekoľko reálnych scenárov, kde AppArmor chráni pred konkrétnymi útokmi.

Scenár 1: Ochrana webového servera pred RCE

Predstavme si, že útočník exploituje zraniteľnosť Remote Code Execution (RCE) vo webovej aplikácii. Bez AppArmoru má prístup ku všetkému, k čomu má prístup používateľ, pod ktorým beží webový server. S AppArmor profilom je situácia úplne iná:

/usr/sbin/apache2 {
    #include <abstractions/base>
    #include <abstractions/apache2-common>

    # Webový obsah (iba čítanie)
    /var/www/html/** r,

    # Zápis iba do logov a upload adresára
    /var/log/apache2/** w,
    /var/www/html/uploads/** rw,

    # Zakázanie prístupu k citlivým súborom
    deny /etc/shadow r,
    deny /etc/gshadow r,
    deny /home/** rwx,
    deny /root/** rwx,

    # Zakázanie spúšťania shellov
    deny /bin/sh x,
    deny /bin/bash x,
    deny /bin/dash x,
    deny /usr/bin/python* x,
    deny /usr/bin/perl x,

    # Zakázanie sieťových nástrojov
    deny /usr/bin/wget x,
    deny /usr/bin/curl x,
    deny /usr/bin/nc x,
    deny /usr/bin/ncat x,

    # Povolenie iba potrebných sieťových operácií
    network inet stream,
    network inet6 stream,
}

S týmto profilom útočník nemôže spustiť shell, stiahnuť ďalšie nástroje, pristúpiť k citlivým súborom ani sa laterálne pohybovať po sieti. RCE zraniteľnosť sa stáva výrazne menej nebezpečnou.

Scenár 2: Izolácia databázového servera

/usr/sbin/mysqld {
    #include <abstractions/base>
    #include <abstractions/mysql>
    #include <abstractions/nameservice>

    # Dátové súbory
    /var/lib/mysql/ r,
    /var/lib/mysql/** rwk,

    # Konfigurácia
    /etc/mysql/** r,

    # Logy
    /var/log/mysql/** w,

    # Socket a PID
    /var/run/mysqld/ rw,
    /var/run/mysqld/** rw,

    # Dočasné súbory
    /tmp/** rw,

    # Sieť (iba MySQL port)
    network inet stream,

    # Zakázanie nebezpečných operácií
    deny /etc/shadow r,
    deny /home/** rwx,
    deny mount,

    # Schopnosti
    capability dac_override,
    capability setuid,
    capability setgid,
    capability sys_resource,
}

Scenár 3: Bezpečnostný audit s aa-status

Pravidelný audit AppArmor profilov by mal byť súčasťou vášho bezpečnostného procesu. Tu je skript na automatizované kontroly, ktorý si môžete pridať do cronu:

#!/bin/bash
# /opt/scripts/apparmor-audit.sh
# Pravidelný audit AppArmor profilov

echo "=== AppArmor Bezpečnostný Audit ==="
echo "Dátum: $(date -u +'%Y-%m-%dT%H:%M:%SZ')"
echo ""

# 1. Kontrola, že AppArmor je aktívny
if ! aa-enabled 2>/dev/null; then
    echo "[KRITICKÉ] AppArmor nie je povolený!"
    exit 1
fi
echo "[OK] AppArmor je aktívny"

# 2. Počet profilov v jednotlivých režimoch
ENFORCED=$(aa-status 2>/dev/null | grep "profiles are in enforce" | awk '{print $1}')
COMPLAIN=$(aa-status 2>/dev/null | grep "profiles are in complain" | awk '{print $1}')
UNCONFINED=$(aa-status 2>/dev/null | grep "processes are unconfined" | awk '{print $1}')

echo "[INFO] Profily v enforce režime: $ENFORCED"
echo "[INFO] Profily v complain režime: $COMPLAIN"

if [ "$COMPLAIN" -gt 0 ] 2>/dev/null; then
    echo "[VAROVANIE] $COMPLAIN profilov je v complain režime!"
    echo "  Tieto profily iba logujú, neblokujú:"
    aa-status 2>/dev/null | grep "(complain)"
fi

if [ "$UNCONFINED" -gt 0 ] 2>/dev/null; then
    echo "[VAROVANIE] $UNCONFINED procesov beží bez obmedzenia!"
fi

# 3. Kontrola nedávnych porušení
DENIALS=$(dmesg | grep -c "apparmor=\"DENIED\"" 2>/dev/null)
echo "[INFO] Počet zablokovaných operácií od bootu: $DENIALS"

# 4. Kontrola obmedzenia menných priestorov
USERNS=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns 2>/dev/null)
if [ "$USERNS" = "1" ]; then
    echo "[OK] Obmedzenie neprivilegovaných menných priestorov: povolené"
else
    echo "[VAROVANIE] Obmedzenie menných priestorov nie je povolené!"
fi

echo ""
echo "=== Koniec auditu ==="

Integrácia AppArmor s existujúcou bezpečnostnou infraštruktúrou

AppArmor nefunguje izolovane — a ani by nemal. Jeho skutočná hodnota sa prejaví pri integrácii s ostatnými bezpečnostnými nástrojmi.

Integrácia s Wazuh

Ak ste nasadili Wazuh (podľa nášho predchádzajúceho článku), AppArmor deny logy sa automaticky zbierajú agentom a analyzujú na serveri. Wazuh obsahuje predpripravené pravidlá na detekciu AppArmor udalostí a ich mapovanie na MITRE ATT&CK framework. Môžete si vytvoriť aj vlastné pravidlá na upozornenie pri špecifických porušeniach:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="apparmor,">
  <rule id="100200" level="10">
    <decoded_as>apparmor</decoded_as>
    <match>DENIED</match>
    <match>/etc/shadow</match>
    <description>AppArmor: pokus o čítanie /etc/shadow</description>
    <mitre>
      <id>T1003</id>
    </mitre>
  </rule>

  <rule id="100201" level="12">
    <decoded_as>apparmor</decoded_as>
    <match>DENIED</match>
    <match>/bin/bash</match>
    <description>AppArmor: pokus o spustenie shellu z obmedzeného procesu</description>
    <mitre>
      <id>T1059.004</id>
    </mitre>
  </rule>
</group>

Integrácia s nftables

AppArmor a nftables sú komplementárne vrstvy ochrany. Kým nftables kontroluje sieťovú komunikáciu na úrovni paketov, AppArmor kontroluje, ktoré procesy môžu vôbec pristupovať k sieti. Kombináciou oboch dosiahnete skutočný defense-in-depth:

  • nftables: „Iba porty 80 a 443 sú otvorené zvonku"
  • AppArmor: „Iba nginx môže počúvať na portoch 80 a 443"

Táto kombinácia znamená, že aj keby útočník nejako obišiel firewall, stále nemôže spustiť vlastný listener na sieťovom porte.

Kombinácia s OpenSCAP

CIS benchmarky overované pomocou OpenSCAP obsahujú kontroly súvisiace s AppArmor. Automatizovaný audit OpenSCAP overí, že AppArmor je povolený, profily sú v enforce režime a kritické služby majú definované profily. Toto prepojenie poskytuje kompletnú auditovateľnú stopu pre compliance.

Riešenie problémov a ladenie

Pri práci s AppArmor (a to hovorím z vlastnej skúsenosti) narazíte na situácie, keď profil blokuje legitímne operácie. Nebojte sa, tu je systematický prístup k ladeniu.

Diagnostický postup

# Krok 1: Overte, že problém súvisí s AppArmor
# Dočasne prepnite profil do complain režimu
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Ak aplikácia začne fungovať, problém je v profile

# Krok 2: Analyzujte logy
sudo journalctl -k | grep "apparmor.*DENIED"

# Krok 3: Identifikujte chýbajúce pravidlá
# Príklad výstupu:
# apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
# name="/var/cache/nginx/proxy_temp/1/00/0000000001"
# requested_mask="w" denied_mask="w"

# Krok 4: Pridajte chýbajúce pravidlo do profilu
# /var/cache/nginx/proxy_temp/** rw,

# Krok 5: Načítajte upravený profil
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# Krok 6: Prepnite späť do enforce režimu
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Kontrola podporovaných pravidiel jadrom

Nie všetky pravidlá sú podporované každou verziou jadra. Parser apparmor_parser štandardne ticho ignoruje nepodporované pravidlá, čo môže byť dosť zákerné. Pre diagnostiku použite:

# Zobrazenie varovaní o nepodporovaných pravidlách
sudo apparmor_parser --warn=rules-not-enforced \
    --warn=rule-downgraded \
    /etc/apparmor.d/usr.sbin.nginx

Odporúčania pre produkčné nasadenie

Na záver zhrniem najdôležitejšie odporúčania pre efektívne nasadenie AppArmor v produkcii:

  1. Nikdy nevypínajte AppArmor. Ak profil spôsobuje problémy, prepnite ho do complain režimu, diagnostikujte a opravte. Vypnutie celého AppArmoru nie je riešenie — nikdy.
  2. Postupný rollout. Začnite s complain režimom, dôkladne otestujte a až potom prepnite do enforce režimu. Tento cyklus opakujte pri každej zmene.
  3. Profilujte všetky sieťové služby. Každá služba prístupná z internetu by mala mať enforced AppArmor profil. Prioritizujte webové servery, databázy a API endpointy.
  4. Nainštalujte rozšírené profily. Balíčky apparmor-profiles a apparmor-profiles-extra obsahujú hotové profily pre desiatky bežných služieb.
  5. Integrujte s monitoringom. AppArmor deny logy by mali byť centrálne zbierané a analyzované — ideálne cez Wazuh alebo iný SIEM systém.
  6. Pravidelne auditujte. Minimálne raz mesačne skontrolujte aa-status a overte, že všetky kritické služby majú profily v enforce režime.
  7. Povoľte obmedzenie menných priestorov. Na Ubuntu 24.04 aktivujte kernel.apparmor_restrict_unprivileged_unconfined=1 pre dodatočnú ochranu.
  8. Verzujte profily. Uchovávajte AppArmor profily v git repozitári a nasadzujte ich pomocou automatizácie (Ansible, Puppet, Chef). Každá zmena profilu by mala byť review-ovaná.

Záver

AppArmor je jednou z najdôležitejších bezpečnostných vrstiev, ktoré máte na Linuxe k dispozícii. Oproti tradičným DAC oprávneniam poskytuje zásadne vyššiu úroveň ochrany — a oproti SELinux ponúka výrazne jednoduchšiu správu. S AppArmor 4.0 v Ubuntu 24.04 LTS máte k dispozícii detailné sieťové politiky, obmedzenie neprivilegovaných menných priestorov a ďalšie pokročilé funkcie.

V kontexte celkovej bezpečnostnej architektúry AppArmor dopĺňa firewall (nftables), centralizovaný monitoring (Wazuh), hardening kontajnerov (Seccomp, rootless Podman) a automatizovaný audit (OpenSCAP). Spoločne tvoria viacvrstvový bezpečnostný systém, ktorý výrazne znižuje riziko úspešného útoku.

Tak začnite ešte dnes — skontrolujte aa-status na vašich serveroch, nainštalujte rozšírené profily a začnite vytvárať vlastné profily pre vaše kritické aplikácie. Bezpečnosť nie je produkt, je to proces. A AppArmor by mal byť jeho neoddeliteľnou súčasťou.

O Autorovi Editorial Team

Our team of expert writers and editors.

Súvisiace Články