Oprávnenia v Linuxe odpovedajú na otázku „kto smie prečítať tento súbor“. AppArmor kladie inú: „čo tento program vôbec smie robiť“. Rozdiel sa prejaví pri prieniku. Webshell sa spúšťa s oprávneniami používateľa webového servera a dedí všetky jeho práva — teda čítanie dobrej polovice systému. Profil AppArmoru obmedzuje proces na zoznam toho, čo potrebuje na prácu, a pokus prečítať /etc/shadow alebo spustiť /bin/bash skončí odmietnutím bez ohľadu na oprávnenia používateľa.
Čo je už zapnuté
sudo aa-status
Výstup odpovedá na tri otázky: koľko profilov je načítaných, koľko z nich beží v režime enforce a complain a ktoré procesy bežia úplne bez profilu. V typickom Ubuntu ich bude niekoľko desiatok, ale takmer všetky pre pomocné programy typu man a tcpdump. Kľúčové služby — nginx, Apache, PHP-FPM — v zozname obmedzených obvykle chýbajú.
Tri režimy, ktoré treba rozlišovať:
- enforce — pravidlá platia, všetko zbytočné je zakázané;
- complain — porušenia sa len zaznamenávajú, nič sa neblokuje. Režim na ladenie;
- unconfined — profil neexistuje, program beží bez obmedzení.
Najužitočnejšou časťou výstupu aa-status je tá posledná: procesy počúvajúce v sieti a ničím neobmedzené. To je zoznam, ktorým je vhodné začať.
Nástroje
sudo apt install apparmor-utils
Bez tohto balíka príkazy aa-complain, aa-enforce a aa-logprof v systéme nie sú, hoci samotný AppArmor funguje.
Ako zapnúť profil a nezastaviť službu
Na poradí zásadne záleží. Profil zapnutý rovno v režime enforce s vysokou pravdepodobnosťou zakáže službe niečo potrebné a tá prestane fungovať — obvykle nie hneď, ale pri zriedkavej operácii, ako je odoslanie súboru alebo pošty.
Správne poradie:
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
Týždeň práce v tomto režime vrátane všetkých netypických scenárov: zálohovanie, aktualizácia, odosielanie veľkých súborov. Potom prehľad toho, čo sa nazbieralo:
sudo aa-logprof
Príkaz prejde zaznamenané porušenia a pri každom sa opýta, či ich povoliť. Tu je potrebná pozornosť: povoľovať treba to, čo skutočne patrí k práci služby, nie všetko po rade — inak vznikne profil dovoľujúci všetko a zmysel zmizne.
A až potom:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
Kde hľadať odmietnutia
Všetky porušenia putujú do logu jadra:
sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log
Druhý súbor existuje, ak je nainštalovaný auditd — a potom sú záznamy podstatne bohatšie. V zázname odmietnutia je vidieť názov profilu, požadovanú operáciu a cestu, na ktorú sa siahalo; to stačí na rozhodnutie, či profil upraviť, alebo sa radovať, že zafungoval.
Zvlášť si zapamätajte príznak: služba sa správa čudne — nečíta konfiguráciu, nezapisuje do adresára, neotvára soket — a vo vlastných logoch má chybu „prístup odmietnutý“ pri úplne správnych oprávneniach. To je takmer vždy AppArmor a prvou vecou je nazrieť do logu jadra.
Praktické opatrenie, nie teoretické
Profil pre PHP-FPM alebo nginx sa vypláca konkrétnym spôsobom. Pri obmedzenom procese nemôže webshell, ktorý sa dostal na web, ani prečítať systémové súbory, ani spustiť shell, ani zapísať čokoľvek mimo povolených adresárov. Prienik na web zostane prienikom na web namiesto toho, aby sa zmenil na prístup k celému stroju — a práve tento prechod tvorí podstatnú časť škody.
Rozumné poradie nasadenia: najprv profil pre to, čo hľadí do internetu (webový server, PHP-FPM), potom pre databázy, ďalej podľa potreby. Všetko naraz zapínať netreba a univerzálna hotová sada neexistuje: profil závisí od toho, kde ležia vaše súbory.
Čo kontrolovať pravidelne
Profily sa vracajú do neobmedzeného režimu častejšie, než by sa zdalo: aktualizácia balíka môže vymeniť súbor profilu, ručné ladenie nechá službu v režime complain a nová služba príde úplne bez profilu. Užitočné sú dve čísla: koľko profilov je v režime enforce a koľko sieťových procesov beží bez obmedzení. Zmena ktoréhokoľvek z nich stojí za pozornosť. Ako to vyzerá zhromaždené na jednej stránke, ukazuje ukážka nižšie.