Oprávnění v Linuxu odpovídají na otázku „kdo smí přečíst tento soubor“. AppArmor klade jinou: „co tento program vůbec smí dělat“. Rozdíl se projeví při průniku. Webshell se spouští s oprávněními uživatele webového serveru a dědí všechna jeho práva — tedy čtení dobré poloviny systému. Profil AppArmoru omezuje proces na seznam toho, co potřebuje k práci, a pokus přečíst /etc/shadow nebo spustit /bin/bash skončí odmítnutím bez ohledu na oprávnění uživatele.

Co je už zapnuto

sudo aa-status

Výstup odpovídá na tři otázky: kolik profilů je načteno, kolik z nich běží v režimu enforce a complain a které procesy běží zcela bez profilu. V typickém Ubuntu jich bude několik desítek, ale téměř všechny pro pomocné programy typu man a tcpdump. Klíčové služby — nginx, Apache, PHP-FPM — v seznamu omezených obvykle chybí.

Tři režimy, které je třeba rozlišovat:

  • enforce — pravidla platí, vše zbytečné je zakázáno;
  • complain — porušení se jen zaznamenávají, nic se neblokuje. Režim pro ladění;
  • unconfined — profil neexistuje, program běží bez omezení.

Nejužitečnější částí výstupu aa-status je ta poslední: procesy naslouchající v síti a ničím neomezené. To je seznam, kterým je vhodné začít.

Nástroje

sudo apt install apparmor-utils

Bez tohoto balíčku příkazy aa-complain, aa-enforce a aa-logprof v systému nejsou, ačkoli samotný AppArmor funguje.

Jak zapnout profil a nezastavit službu

Na pořadí zásadně záleží. Profil zapnutý rovnou v režimu enforce s vysokou pravděpodobností zakáže službě něco potřebného a ta přestane fungovat — obvykle ne hned, ale při vzácné operaci, jako je odeslání souboru nebo pošty.

Správné pořadí:

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Týden práce v tomto režimu včetně všech netypických scénářů: zálohování, aktualizace, odesílání velkých souborů. Potom přehled toho, co se nashromáždilo:

sudo aa-logprof

Příkaz projde zaznamenaná porušení a u každého se zeptá, zda je povolit. Tady je potřeba pozornost: povolovat je třeba to, co skutečně patří k práci služby, ne všechno po řadě — jinak vznikne profil dovolující vše a smysl zmizí.

A teprve potom:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Kde hledat odmítnutí

Všechna porušení putují do logu jádra:

sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log

Druhý soubor existuje, je-li nainstalován auditd — a pak jsou záznamy podstatně bohatší. V záznamu odmítnutí je vidět název profilu, požadovaná operace a cesta, na kterou se sahalo; to stačí k rozhodnutí, zda profil upravit, nebo se radovat, že zafungoval.

Zvlášť si zapamatujte příznak: služba se chová podivně — nečte konfiguraci, nezapisuje do adresáře, neotevírá soket — a ve vlastních logách má chybu „přístup odepřen“ při naprosto správných oprávněních. To je téměř vždy AppArmor a první věcí je nahlédnout do logu jádra.

Praktické opatření, ne teoretické

Profil pro PHP-FPM nebo nginx se vyplácí konkrétním způsobem. Při omezeném procesu nemůže webshell, který se dostal na web, ani přečíst systémové soubory, ani spustit shell, ani zapsat cokoli mimo povolené adresáře. Průnik na web zůstane průnikem na web místo toho, aby se změnil v přístup k celému stroji — a právě tento přechod tvoří podstatnou část škody.

Rozumné pořadí nasazení: nejdřív profil pro to, co hledí do internetu (webový server, PHP-FPM), potom pro databáze, dál podle potřeby. Vše najednou zapínat netřeba a univerzální hotová sada neexistuje: profil závisí na tom, kde leží vaše soubory.

Co kontrolovat pravidelně

Profily se vracejí do neomezeného režimu častěji, než by se zdálo: aktualizace balíčku může vyměnit soubor profilu, ruční ladění nechá službu v režimu complain a nová služba přijde zcela bez profilu. Užitečná jsou dvě čísla: kolik profilů je v režimu enforce a kolik síťových procesů běží bez omezení. Změna kteréhokoli z nich stojí za pozornost. Jak to vypadá shromážděné na jedné stránce, ukazuje ukázka níže.