AppArmor
A számítógépes világban a biztonság kédése igen szerteágazó probléma. Egy érdekes szeletére próbál megoldást találni az itt bemutatásra kerülő eljárás, melynek konkrét fizikai (logikai?) valóját AppArmor-nak nevezték el.
A modern operációs rendszerek többfelhasználósak, ezen megkülönböztetett személyek alapértelmezésben nem láthatják egymás fájljait és főként nem avatkozhatnak be a rendszert alkotó állományok tartalmába. Az általuk futtatott alkalmazások process-ei (normál esetben) az ő jogaikat öröklik, így azok tevékenysége azonos veszélyességi szintűnek tekinthető a felhasználójukéval. (Jelen szócikkben az alkalmazás kifejezés a "futtatható állomány" szinonímájaként értelmezendő, azaz nem különböző programok összességéből álló alkalmazást jelent).
A rendszer felépítéséből adódóan azonban vannak olyan (rendszerint a háttérben futó) process-ek, melyek kevésbé korlátozott, legtöbb esetben egyenesen root jogokkal működnek.
Bárhogyis, elméletben egy program mindent megtehet, amit az őt (bárhogyan is) indító user. Kellemetlen, de a rendszer szempontjából veszélytelen, ha egy felhasználói alkalmazás, netán a felhasználó által éppen fejlesztett program letörli az illető Home könyvtárát, de az már súlyosabb, ha valami ugyanezt a rendszer bármely mappájával meg tudja tenni, esetleg módosítani tudja azokat. A cél az ilyen nem várt, nem kívánt viselkedés hatástalanítása, bármilyen okból jöjjön is az létre.
Az AppArmor ezt a védelmet hivatott megvalósítani, úgy, hogy a programok számára ne legyen látható, azok ne tudják megkerülni és a rendszert ne érje jelentős plusz terhelés. Az első időkben kernel-patch formájában létezett, majd a 2.6-os Linux sorozathoz egy bizonyos Immunix Inc. (akiket később felvásárolt a Novell) kifejlesztett egy "Linux Security Modules Interface" (LSM) nevű szolgáltatást. Ez biztosít egy kernel API-t, amin keresztül megvalósítható a hatékony hozzáférés-vezérlés. Ennek köszönhetően már nincs szükség a kernel patchelésére, a megoldás különböző megvalósításai betölthető modulokként működhetnek.
A megkerülhetetlenség kérdésköre miatt kell a megoldást mélyen a kernelbe ágyazni. Ha nem így lenne, egy támadható alkalmazás esetén, külső kód futtatásával "kikapcsolhatóvá" válna az ekkor csak "hozzákapcsolt"-nak minősülő védelem (végülis logikus, hogy egy külső alkalmazás külső kóddal kerülhető meg).
Beágyazott esetben az LSM modul betesz egy kaput a hozzférés-kérelem útjába, melynél a kérésnek addig kell várnia, mígnem a modul a benne meghatározott szabályok alapján eldönti, endegélyezi vagy nem a műveletet. A döntés minden esetben az alkalmazáshoz rendelt "policy" alapján történik. Ebben meghatározásra kerül, hogy a POSIX.1e-ben maghatározott, vagy a Linux specifikus "képességek" (capabilities) közül melyekkel élhet, továbbá hogy mely fájlokhoz milyen jelleggel férhet hozzá. A fájlokra való hivatkozás az abszolút elérési útvonaluk alapján történik, ezért az Apparmor használata esetén körültekintőbben kell élni a hardlinkek használatával és a nem fix helyen lévő programok áttelepítésével, de egyáltalán bármilyen útvonalmódosítással. Azonban a megoldás immunis a fájlok felülírással történő módosításával szemben (ezt a SELinux-xal kapcsolatban említi az irodalom, annak kapcsán, hogy ott a hozzárendelés az inode-okkal van kapcsolatban).
A policy kézzel is megszerkeszthető, de az AppArmor fejlesztőinek egyik célja az egyszerűség. Ennek szellemében létezik az un. "learning mode", mely az alkalmazás viselkedésének megfigyelését és naplózását takarja, beleértve azt is, indított-e az bármilyen új alkalmazást (amennyiben egy megfigyelt program indít egy másikat, 3 féle lehetőség adódik: a) örökli a szülő profile-ját; b) saját profile-lal indul útnak; c) nem kerül be az AppArmor felügyelete alá). A csomag része egy naplófeldolgozó program, ez valósítja meg a felhasználóval történő kommunikációt a figyelt alkalmazások tevékenységeire vonatkozó engedélyező/elutasító kérdések feltételével, melyek alapján a profile generálása automatikusan történik.
Fő célunk a rendszer védelme. Ezt leggyakrabban rajtunk kívül álók veszélyeztetik. Ha a belső támadókat most nem vesszük fugyelembe, maradnak a hálózat felől érkezők, ezért alapvetően a hálózattal kapcsolatban lévő alkalmazásokat, szolgáltatásokat érdemes ily módon szabályozni. (Az AppArmor unconfined néven tartalmaz egy rendszerelemzőt, mely felderíti a nyitott portokat, az azokon "lógó" alkalmazásokat, és hogy ezekhez tartozik-e profile.) Érdemes megfontoli a hálózat irányából érkező adatokat azonnali hatállyal feldolgozó alkalmazások figyelését is, mert ez a viselkedés is network-inputtá minősíti a kapcsolódó inputot - ez a megközelítés szükség esetén értelmezhető bármilyen forrásirányra.
A http://en.opensuse.org/AppArmor_Geeks oldalon megtalálható az Apparmor telepítésének és aktiválásának menete. Fontos kiemelni, hogy mellette nem lehet más LSM modul is aktív, tehát pl. a SELinux-xal párhuzamosan nem használható.
A profile-ok listája általában a /sys/kernel/security/apparmor/profiles útvonal alatt található, mely azt is megadja, learning vagy enforcement módban vannak-e (utóbbi az élesített állapotot jelenti). Maguk a profile-ok a /etc/apparmor.d/ alá kerülnek.
Aktiválásuk, újraolvasásuk az un. Policy Parserrel történik:
cat usr.bin.skype | apparmor_parser
vagy
cat usr.bin.skype | apparmor_parser --replace
(A parser működésének feltétele, hogy a "mount securityfs -t securityfs /sys/kernel/security" paranccsal csatoljuk a rendszerhez a securityfs-t.)
Az usr.bin.skype egy fájl az /etc/apparmor.d/ alatt, mely a /usr/bin/skype alkalmazás profile-ját tartalmazza. Ennek egy lehetséges felépítése:
/usr/bin/skype flags=(complain) {
#include <abstractions/base> //előre definiált inlcude fájlok - az AppArmor csomag tartalmazza őket
#include <abstractions/consoles>
capability net_bind_service,
capability sys_time,
capability sys_chroot,
capability setuid,
/eleresi_utvonal/fajlnev r,
/eleresi_utvonal/ w,
...
}
Alapértelmezetten a syslog-ban keletkeznek az AppArmor logbejegyzései. Complain módban innen tudhatjuk meg, milyen fájlokhoz nyúlt hozzá, milyen jelleggel - azonban mindez csak akkor lesz olvasható számunkra is, ha telepítjük és --with-apparmor opcióval configuráljuk az Auditd-t. Ennek hiányában a "milyen program, milyen fájlt és milyen módon inzultált" információk helyett a log csak mindenféle integer számokat fog tartalmazni. Az Auditd telepítésétől kezdve az AppArmor logok a /var/log/audit/audit.log fájlban keletkeznek.
Elsőként egy üres profile került aktiválásra, hogy lássuk, mit is kellene engedélyeznünk.
/usr/bin/skype flags=(complain) {
}
Elvileg a complain módot érdemes használni egy program viselkedésének feltérképezéséhez. Azonban, mint az a közismert Skype monitorozása közben kiderült, az alkalmazás ekkor is csak a neki engedélyezett fájlokhoz férhet hozzá, a megadott módon. Ebből kiindulva a tesztrendszeren (naprakész Ubuntu Linux (7.10), előtelepített és élesített AppArmorral) vagy nem működik a complain mód, vagy valami más beállítási lehetőség is meghúzódik a háttérben, melyről az irodalomjegyzék írásai nem szólnak. A következmény: mindent látunk a logban, de a Skype nem tud kapcsolódni a szerveréhez.
A http://en.opensuse.org/AppArmor_Geeks oldalon található, Firefox-ra vonatkozó, a fokozatos bővítés első lépéseként bemutatott profile-ból pár sort átvéve:
/usr/bin/skype flags=(complain) {
/lib/ld-2.5.so rmix,
/etc/ld.so.cache rm,
/lib/lib*.so* rm,
/usr/lib/lib*.so* rm
}
Így már felépíti a kapcsolatot, működik a login, látjuk a kontaktjainkat. Lévén a minden lib*.so* elérését engedélyeztük, nem fogunk már utalást látni a "/usr/lib/libaudio.so.2.4" fájl elérhetetlenségére sem, mely nevéből gondolhatóan az audio rész működéséhez járul hozzá. Amenniyben a program által nyújtott valamely szolgáltatás így még nem lenne elérhető, fokozatosan kiterjeszthetjük az engedélyek körét, adhatunk jogosultségot bizonyos capability-kre is.
Felvetődött, hogy a Skype (a 2007. dec. 13-án letölthető verzió) az idításakor megpróbálja olvasásra megnyitni a /etc/passwd fájlt. Ez így is van:
type=UNKNOWN[1502] msg=audit(1197555237.399:924): type=1502 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/passwd" pid=9920 profile="/usr/bin/skype"
Ennek AppArmor általi megtagadása azonban látszólag nincs végzetes hatással a működésére, enélkül is hajlandó üzemképes állapotba kerülni. A témávalkapcsolatban forum-topic található az alábbi link alatt: http://forum.skype.com/index.php?showtopic=95261 - itt többek közt kitérnek a Firefox felé elkövetett kíváncsiságára is.
Különböző elérési-út megadási módok:
/home/ - a /home könyvtárra /home/fájlnév - a /home/fálnév fájlra /home/* - minden, a /home-ban lévő fájlra érvényes /home/*/ - minden, a /home-ban lévő könyvtárra /home/** - minden, a /home alatt lévő fájlra és könyvtárra /home/**/ - minden, a /home alatt lévő könyvtárra
A különböző kapcsolók hozzájuk:
r - olvashatja w - írhatja ux - unconstrained execute - az általa indított alkalmazás nem megfigyelt Ux - unconstrained execute -- scrub the environment - ugyanaz, kitisztított környezettel px - discrete profile execute - az általa indított alkalmazás saját profile-lal rendelkezik Px - discrete profile execute -- scrub the environment - ugyanaz, mint az előbb ix - inherit execute - az általa indított alkalmazás orökli szülője profile-ját m - allow PROT_EXEC with mmap(2) calls - futtathatóság l - link - a pl. /elérési_utvonal/fajlnev l,r -re hardlinkelhető egy másik fájl, ha a program két fájlra azonos jogokkal bír, kivéve az l opciót.
A http://en.opensuse.org/AppArmor_Geeks oldalon található egy rövid leírás, hogyan készíthető manuálisan egyszerű, átlátható profile egy alkalmazáshoz, ha erre adnánk a fejünket.
A http://kerneltrap.org/Linux/AppArmors_Security_Goals lap alján felsorolnak néhány olyan esetet, amire az AppArmor egyelőre nem megoldás. Meglepő, de érdekes, hogy az írás szerzője szerint többek közt a világbéke megteremtésére sem alkalmas.
Irodalomjegyzék:
http://en.wikipedia.org/wiki/AppArmor http://en.opensuse.org/Apparmor http://en.opensuse.org/AppArmor_Geeks http://kerneltrap.org/Linux/AppArmors_Security_Goals https://help.ubuntu.com/community/AppArmor http://www.securityfocus.com/infocus/1400 //a capabilities mibenlétének meghatározásához
