AppArmor – Névalapú kötelező hozzáférés-vezérlés PPKE-ITK 2014. március–április
Tartalomjegyzék 1. Bevezetés 1.1. Történet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Az AppArmor célja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Az AppArmor felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 2 2
2. Az AppArmor használata 2.1. Parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Védelem létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 4 4
3. Ellenőrző kérdések
5
1
1. Bevezetés Az AppArmor a névalapú kötelező hozzáférés-vezérlés (Mandatory Access Control, MAC) megvalósítása Linux biztonsági modulként. Az AppArmor az egyes programokat felsorolt fájlok és a POSIX 1003.1e vázlat szerinti képességek halmazához köti.
1.1. Történet 2005-től 2007-ig az AppArmor-t a Novell tartotta karban. Eredetileg a linuxos biztonsági megoldások fejlesztésére szakosodott Immunix fejlesztette ki. A Novell 2005. májusában jelentette be, hogy megvásárolta az Immunix-et. 2007. szeptemberében a Novell elbocsátotta az AppArmor csapat nagy részét. Jelenleg a Canonical fejleszti, része az Ubuntu és az Ubuntura épülő disztribúcióknak.
1.2. Az AppArmor célja Az AppArmor célja, hogy megvédje a rendszert azoktól a támadásoktól, amelyek a rendszeren található alkalmazások hibáit akarják kihasználni. Az ilyen támadásokból adódó fenyegetés abban rejlik, hogy a támadó rossz esetben rá tudja venni az alkalmazást olyan viselkedésre, ami tőle váratlan és nemkívánatos. Az AppArmor úgy kezeli ezt a problémát, hogy lekorlátozza az alkalmazások erőforrásokhoz való hozzáférhetőségét és kizárólag csak azokhoz az erőforrásokhoz engedi hozzáférni őket, amelyek feltétlenül szükségesek a megfelelő futásukhoz. Tulajdonképpen a lehető legkisebb privilégiumszintű végrehajtásra szorítja az alkalmazást. A MAC lényege, hogy ezek a korlátozások a root-ra is kötelező érvényűek. Az alkalmazások számos erőforráshoz – fájlokhoz, processzek közti kommunikációhoz, hálózatkezeléshez, más alkalmazások futtatásához, stb. – férhetnek hozzá. A lehető legkisebb privilégiumszintű végrehajtás célja, hogy korlátozza a rosszindulatú támadó (vagy kód) által okozható kárt azzal, hogy megakadályozza az alkalmazás összes olyan erőforráshoz való hozzáférhetőségét, amely nem szükséges az eredetileg tervezett működéséhez. Az AppArmor megközelítésben egy alkalmazás egy vagy több olyan egymással kapcsolatban álló processzt jelent, amely azonos feladatot lát el. Ilyen például az Apache processzek csoportja, amely webkiszolgálási feladatot teljesít. Az AppArmor csak azokat a processzeket korlátozza, amelyekre az AppArmor policy rendelkezik, egyéb más processzek bármit megtehetnek, amire a DAC (Discretionary Access Control - önkényes hozzáférés-védelem) lehetőséget biztosít. Az AppArmor nem ad olyan alapértelmezett policy-t, amely minden processzre vonatkozik. Ha teljes egészében meg akarunk védeni egy hostot, akkor aprólékosan le kell korlátoznunk minden olyan processzt, amely potenciális támadásnak van kitéve.
1.3. Az AppArmor felépítése Az AppArmor a Linux kernelen belül a Linux Security alrendszer része1 . Számos utility tartozik hozzá, amelyek megkönnyítik a konfigurálását. Úgynevezett profilokat használ az alkalmazás számára engedélyezett fájlok és jogosultságok meghatározásához. Néhány csomag saját profilt telepít, de számos további profil található az apparmor-profiles csomagban. 1
Linuxon külön fájlrendszere van securityfs típussal, és a /sys/kernel/security helyre van felcsatolva
2
Fontos elemei: /etc/init.d/apparmor init szkript, a /etc/apparmor/ és a /etc/apparmor.d/ könyvtárak. Az előbbiben a utilityk konfigurációi, az utóbbiban a profilok, az azokhoz szükséges absztrakciók, a disable könyvtár, stb. találhatóak. A profil neve mindig a futtatható bináris elérési útja, a „/” helyett „.”-tal. Tehát a /bin/ping alkalmazáshoz a bin.ping nevű profil tartozik. A következőképpen néz ki: A #include-kezdetű sorok az ún. absztrakciók, melyekbe gyakran alkalmazott szabályokat gyűjtöttek össze, így ezeket az egyes profilokban újra lehet használni (pl. ha az alkalmazás szeretne névfeloldást, akkor a nameservice absztrakciót kell hozzáadni).
#include
/bin/ping { #include #include #include #include
A capabilityk a Linux által biztosított képességek (Részletek: man capabilities).
capability net_raw, capability setuid, network inet raw,
A továbbiakban lehet felsorolni a biztosítani kívánt fájlokat és mappákat, a hozzáférés módjának megadásával. Ez némiképp eltér a hagyományos linuxos jogosultságkezeléstől (kibővíti azt).
/bin/ping mrix, /etc/modules.conf r, }
A fájlokat és könyvtárakat teljes elérési úttal kell megadni, melyben reguláris kifejezések és változók is használhatóak. Egy mappán belül a * az összes fájlt, a ** az összes alkönyvtárt és fájlt jelöli. Egy fájlhoz, vagy könyvtárhoz a következő jogosultságok rendelhetőek2 : Az alkalmazás r: olvashatja a fájlt/mappát w: írhatja a fájlt/mappát a: hozzáfűzhet a fájlhoz l: hard linket hozhat létre. Alfolyamat hívása m: memory mapping joggal ix: a hívó jogosultságainak örököltetésével px: a hívott alkalmazás saját profilja szerint (kötelező profillal rendelkeznie) ux: profil betöltése (védelem) nélkül.
2. Az AppArmor használata Egy alkalmazás unconfined, ha nincs hozzá betöltve profil, azaz alkalmazás nem védett. Ha egy alkalmazás védett (confined ), további két állapota lehet: • Panaszkodás/tanulás (complain): a profilsértések engedélyezettek, és naplózásra kerülnek. Új profilok létrehozásához, teszteléséhez és fejlesztéséhez hasznos. • Kényszerített (enforce): kikényszeríti a profilházirendet, és naplózza a megsértésükre vonatkozó kísérleteket. 2
Bővebben kifejtve: http://www.novell.com/documentation/apparmor/apparmor201_sp10_admin/data/bx5bmls.html
3
2.1. Parancsok Minden parancs root jogokat igényel, így a sudo helyett célszerűbb rendszergazda-terminált használni. Az aa- kezdetű parancsok az apparmor-utils csomag részei. • aa-status Kiírja a profilok és a hozzájuk tartozó processzek állapotát állapotát. • aa-unconfined Kilistázza a hálózaton kommunikáló processzeket, és a védelmük állapotát. • service apparmor reload Újra betölti a profilokat (a szolgáltatás újraindítása nélkül). • apparmor_parser -[acrR] profil.neve Egy megadott profil betöltése enforce (a) / complain (c) módban, újratöltése (r) módosítás után, valamint kikapcsolása a következő betöltésig (R). Ez a hagyományos módszer, inkább a utils parancsokat alkalmazzuk: • aa-complain /útvonal/futtatható A megadott alkalmazáshoz tartozó profil betöltése/frissítése complain módba. • aa-enforce /útvonal/futtatható A megadott alkalmazáshoz tartozó profil betöltése/frissítése enforce módba. • aa-disable /útvonal/futtatható A megadott alkalmazáshoz tartozó profil kikapcsolása, és link létrehozása a disable könyvtárba. Ezzel előzi meg, hogy újraindításkor újra betöltődjön. Vö. apparmor_parser -R • aa-logprof Az audit szolgáltatás naplózza a házirend-sértéseket. A logprof segítségével a napló alapján lehet interaktív módon frissíteni a profilokat. Részletek: man aa-logprof! • aa-genprof /útvonal/futtatható Új profil létrehozása a megadott alkalmazáshoz, azonnali complain módba állítással. Segítségével az alkalmazás tesztelésével egyszerre lehet a szabályokat kialakítani.
2.2. Védelem létrehozása A védelem kialakítása a következő lépésekből áll: 1. Alap profil létrehozása a binárishoz. Betöltéssel, és complain módba állításával: aa-genprof /útvonal/futtatható 2. Alkalmazás tesztelése egy másik ablakban. (Közben az audit nevű szolgáltatás naplózza a futó alkalmazás által igényelt erőforrásokat.) 3. Log elemzése, profil frissítése: Miután végeztünk az alkalmazás tesztelésével, az „S” (Scan system log for AppArmor events) választásával kezdhetjük a konfigurálást. Minden esetben kiírja az igényt és több javaslatot is tesz annak kielégítésére. Részletek: man aa-logprof. 4
4. Profil mentése (S), majd kilépés (F). Célszerű ilyenkor complain módban hagyni, és az alkalmazás használata után/közben később megvizsgálni az aa-logproffal, mert semmi sem garantálja, hogy a teszt során minden erőforrásigény felmerült. Enforce módban egy nemvárt hozzáférés-kísérlet összeomláshoz vezethet, ami egy éles környezetben (pl. webv. adatbázis kiszolgáló) túl nagy kockázat. (A mérés során ez nem releváns.) 5. Enforce módba állítás: aa-enforce /útvonal/futtatható 6. Ha az alkalmazás hibásan működik, complain módba állítással és/vagy profilfrissítéssel javítható: (aa-complain /útvonal/futtatható) aa-logprof -m "útvonal.futtatható" Finomhangoláshoz egyszerűbb a profil kézi módosítása szövegszerkesztővel. Ezután újra be kell tölteni: aa-enforce /útvonal/futtatható
3. Ellenőrző kérdések 1. Mely felhasználókra kötelező az AppArmor házirendje? 2. Mi mindent tartalmazhat egy alkalmazásprofil? 3. Mit jelent a lehető legkisebb privilégiumszintű végrehajtás? 4. Hol találhatóak az alkalmazások profiljai? 5. Mi a /opt/google/chrome/chrome futtatható állomány profiljának neve? 6. Mik azok az absztrakciók? 7. Hogyan adna egy profilban hozzáfűzési és olvasási jogot a /path/to/file.log fájlhoz? 8. Hogyan engedélyezné egy profilban a /bin/echo program hívását korlátozás nélkül? 9. Mi a különbség az unconfined és a complain állapotok között? 10. Mi a különbség az enforce és a complain állapotok között? 11. Milyen információt ad meg az aa-unconfined parancs? 12. Mi a különbség az aa-disable és az apparmor_parser -R között? Miért? 13. Nem engedélyezett a névfeloldás a pingben. Hogyan adná hozzá? (/bin/ping) 14. Az apparmor-utils csomag nélkül hogyan töltene be egy profilt complain módban?
5
