SELinux, RSBAC, Grsecurity, AppArmor körmérkőzés

Az egész ott kezdődött, hogy egy SLES11 SP1 szerveren olyan formán szerettem volna üzemeltetni a cron démont, hogy a közönséges felhasználók időzített feladatai erősen korlátozott jogokkal fussanak, a rendszerfeladatok viszont nagyjából korlátoktól mentesen. Arra gondoltam, hogy ezt a célt egy mandatory access control (a továbbiakban MAC) rendszer használatával érem el. Használhatnám ugyan a kiterjesztett attribútumokra épülő POSIX ACL-eket is, amelyeket ha kiegészítünk az utóbbi időben egyre inkább használhatóvá váló Linux capability-kkel, akkor egész elfogadható védelmi rendszert kaphatunk (már ha eltekintünk az ACL-k néhány eléggé idegesítő gyengeségétől), de egy MAC rendszer használata mégiscsak kézenfekvőbbnek tűnik.

Tulajdonképpen mi is egy MAC rendszer? A Wikipédia definíciója, és a hozzáférésvezérlésben elfoglalt helye szerint kizárólagosan rendszergazdai irányítás alatt álló, a többi felhasználó belátására (discretion) nem alapozó, centralizál hozzáférésvezérlési rendszer, és mint ilyen, a Discretionary Access Control (DAC), vagyis a hagyományos (pl. Windows/UNIX), elosztott felelősségvállaláson alapuló fájlrenszerjogosultsági rendszer ellentétpárja. Már a Wikipédia is felhívja azonban a figyelmet arra, hogy a MAC név történelmi okokból szorosan egybeforrt a fenti definíció szerinti rendszerek egy konkrét típusával, nevezetesen a Multilevel Security (MLS, újabban MLS/MCS) rendszerekével, mégpedig oly mértékben, hogy több - általam MAC megoldásnak tartott - rendszer (pl. RSBAC, AppArmor) dokumenteciója kizárólagosan ez utóbbi értelemben használja a MAC kifejezést. Az első definíció szerinti MAC rendszerek nem mindegyike nyújt azonban MLS/MCS szolgáltatást, sőt ez a háttérbe szorul, és inkább a Type Enforcement(TE)+Role Based Access Control(RBAC) alapú megoldások dominálnak.

A fenti szócikkek átböngészése után az már nyilvánvaló volt számomra, hogy MAC megoldás címszó alatt nagyjából olyan rendszerre számíthatok, ami a Linux kernelben azokon a pontokon, ahol az egyébként is hozzáférési döntést hoz a DAC és capability rendszer révén, további hozzáférésvezérlési döntéseket hoz valamilyen központi, csak a rendszergazda (de nem a sima root account, hanem további jogosítványokkal rendelkező adminisztrátor(ok)) által módosítható adatbázis alapján. Az ilyen rendszerek közös jellemzője egyébként, hogy amit a szabványos DAC rendszer megtilt, azt nem bírálják felül, hanem csak annak a tiltását mérlegelik, amit a DAC egyébként engedélyezne. Más szóval a DAC szabályrendszerén enyhíteni nem lehet, csak szigorítani. Az RSBAC-ban azért találtam ezzel szembemenő kivételt a CAP modul esetében. De persze lehet, hogy van más is. A MAC rendszerek ideális esetben lehetővé teszik, hogy a lehető legegyszerűbb adatbázis segítségével olyan korlátozásokat vezethessünk be a Linux kernel hozzáférésvezérlési rendszerében, amelyeket a DAC-ban csak bonyolult, átláthatatlan (rengeteg fájl jogosultságainak módosításával, sok POSIX ACL-lel, a felhasználók részére kiegészítő csoportok megadásával, filesystem capability-kkel, stb.) és megbízhatatlan módon (egy-egy frissítés után elkerülhetetlen újbóli jogosultságállítgatásokkal), vagy sehogy sem tehetnénk meg.
A MAC rendszerek alapvetően arról hoznak döntéseket, hogy mely subjectek (processzek) mely objecteken (fájlok, IPC csatornák, hálózati objeltumok, capability-k, resource-ok, más processzek, egyéb kernelszolgáltatások, stb.) milyen műveleteket végezhetnek el. A szabályrendszer átláthatóvá tétele érdekében(?), vagy más filozófiai meggondolásból (;-) néhány MAC rendszer korlátozásokat leíró adatbázisában a subjectek és és az objectek nem valamilyen természetes, a Linux kernelben egyébként is meglevő jellemzőjük alapján (pl. elérési út, UID, GID, szülőprocessz, stb.) szerepelnek, hanem absztrakt osztályokba sorolva, amely osztályokat valamilyen címke formájában külön össze kell rendelni az adott subjectekkel vagy objectekkel (mint pl. a SELinux egész fájlrendszert beterítő security.selinux nevű kiterjesztett fájlattribútumai esetében). Az RBAC rendszereknél az ilyen absztrakt osztályok neve subjectek esetében általában domain, role vagy type, objectek esetében többnyire type.

Úgy döntöttem tehát, hogy megvizsgálok néhány MAC rendszert, és kiválasztom, melyik lesz számomra a legmegfelelőbb. Első körben hármat tartottam további vizsgálatra érdemesnek, a SELinux-ot, az RSBAC-t és az AppArmort, végül azonban egy műtét miatt megszaporodott a szabadidőm, és a Grsecurity-t is beiktattam.

1.: SELinux

Először az eredetileg az NSA által fejlesztett SELinuxra kerítettem sort. A következő doksikból tájékozódtam:
- http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/4/html/SELin…
- http://selinuxproject.org/page/Main_Page(Főleg az Advanced Users rész, azon belül is a Policy Language)
- OpenSUSE SELinux doksi csomag
- http://flylib.com/books/en/2.803.1.34/1/
- http://fedoraproject.org/wiki/SELinux/Configs
- http://www.nsa.gov/research/selinux/list-archive/0609/16930.shtml
- http://www.nsa.gov/research/selinux/list-archive/0605/thread_body8.shtml
- http://selinux-mac.blogspot.com/2009/06/multi-category-security.html
Miután/miközben ezeket elolvastam, átnéztem még a CentOS 6.0-hoz csomagolt man oldalakat, kipróbáltam ezt-azt (pl. semanage, audit2allow, seaudit, stb.), kielemeztem az alapértelmezett "targeted" policy-t az apol nevű eszközzel, és úgy éreztem, nagyjából sikerült megértenem, miről szól, és hogy működik a SELinux.

A SELinux policy-ja elég sok fájlban oszlik szét. Ezek közül a tulajdonképpeni bináris policy, ami a kernelbe töltődik, a /etc/selinux/POLICYNÉV/policy/policy.VERZIÓ fájlban található, de vannak itt adatok a fájlrendszer megcímkézésére vonatkozóan (amit mindenképpen el kell végezni, hogy használatba vehessük a SELinuxot), a UNIX felhasználók SELinux tulajdonságaira vonatkozóan, stb. A bináris policyn kívüli policy-összetevők menedzselését többnyire a semanage paranccsal végezhetjük.

A SELinux policyjának felépítése rendkívül elegáns. Minden subject és object egységes módon van osztályozva, az ún. security contexttel. A context négy összetevője közül csak a type és a range értékek számítanak a szűkebb értelemben vett hozzáférésvezérlésben, de ezek közül is a range-ben szereplő level egyik összetevője, a sensitivity sohasem bírt igazán gyakorlati jelentőséggel.

A SELinux kernelbeli része nem biztosít közvetlen összefüggést a UNIX UID/GID értékek és a processzek security contextje között, de mivel nyilvánvaló, hogy az UID/GID váltásnak sok esetben contextváltással kell járnia (pl. login, SSH, felhasználói crontabok), ezt úgy oldották meg, hogy néhány userland-beli programnak jogot adnak az explicit contextváltásra, amelyet a libselinux könyvtár segítségével a /proc/PID/attr API-n keresztül tehetnek meg. Ehhez hasonló módon userland támogatásra van szükség olyan esetekben, ahol a type_transition szabályok korlátai miatt a SELinux kernel-beli komponense nem tudja biztosítani, hogy bizonyos rendszeresen újragenerált fájlok (pl. /etc/passw, /etc/shadow, /etc/group, logrotate) megfelelő security contexttel legyenek felcímkézve. Mindezek miatt elég sok userland-beli programcsomagból módosított verzióra van szükség ahhoz, hogy használatba vehessük a SELinux-ot.

A SELinux kernel-beli része az LSM technológiára épül, ezért élvezi a vanilla kernel fejlesztőinek támogatását, sőt része a mainstream kernelnek. Így, ha SELinuxot akarunk telepíteni egy azzal még nem rendelkező disztribúcióra, akkor módosított kernelre nem, de a SELinux userland eszközeire és a fent említett módosított programcsomagokra szükségünk lesz. Ezen felül kell még legalább egy policy. Kiindulási alapnak jó lehet a Tresys-féle referencia-házirend, amit ugyan nem próbáltam, de sejtéseim szerint az adott disztribúciónak az FHS-től (vagy más referenciától) való eltérésének függvényében módosításra, testreszabásra szorulhat. És itt jön a bökkenő: A SELinuxban még az ilyen "egyszerű", a sima DAC-hoz képest nem sok szigorítást tartalmazó házirendek is több százezer szabályból állnak, így a testreszabásuk nem annyira rendszergazdáknak, mint inkább disztribútoroknak való feladat.

A SELinux előnye (az alább ismertetett RSBAC-hoz hasonlóan), hogy rendkívül finomfelbontású a biztonsági modellje, és a fájlok felcímkézésével (amelynek ötletét talán nem is annyira a UNIX inode-onkénti fajljogosultságaiból, hanem több évtizedes USA kormányzati MLS/MCS hagyományokból merítették) olyan jellegű jogosultságelkülönítést tudnak megvalósítani, amit az elérési út-alapú MAC megoldások (AppArmor, Grsecurity) nem. Véleményem szerint van néhány hátránya, amelyek talán az eleganciára való túlzott törekvésből adódnak: Az egyik az, hogy rendkívül bonyolult a karbantartása, embert próbáló feladat a konkrét rendszerhez való illesztése. A Red Hat pl. kétféle policyt szállít az oprendszereivel:

-Az alapértelmezett "targeted" nevűt, amelynél a rendszer nagy része korlátozások nélkül fut, és csak néhány kiválasztott program/démon jogkörét szűkíti a SELinux, de már ez a policy is több százezer szabályból áll.

-Van egy "strict" nevű policy is, amely jóval teljesebb körű korlátozást, így nagyobb biztonságot nyújt, de ennek használata a bonyolultsága okán "unsupported", és mivel előregyártott policyról van szó, nyilván testreszabást igényel egy-egy konkrét rendszer esetében.

A másik fő hátránya szerintem az, hogy amint feljebb már említettem, a kernel szemszögéből a processzek security contextje teljesen független az UID és GID értékektől, ezért tipikus esetben a felhasználókat csak a Linux DAC tudja megkülönböztetni egymástól jogosultság tekintetében, és kiterjedt módosításra szorul a userland (amint szintén említettem már fentebb).

2.: RSBAC

A SELinux után az Amon Ott által szinte egyszemélyes projektként futtatott RSBAC rendszerrel kezdtem foglalkozni. Az RSBAC moduláris felépítésű. A kötelező AUTH és az ajánlott RC modulok együtt a SELinux TE/RBAC megoldásához rendkívül hasonló filozófiát képviselnek. A legtöbb időt ennek a két modulnak (főleg az utóbbinak) a megismerésével töltöttem, míg végül rájöttem, hogy a legjobban úgy lehet megérteni a működésüket, ha megfelelő SELinuxos ismeretek birtokában a (nem éppen részletes) RSBAC doksik és a man oldalak átolvasása után az rsbac_menu programmal böngészve turkálom a rendszert, miközben fél szememet az RSBAC kézikönyv megfelelő fejezetein tartom. Az rsbac_menu a Linux kernel ncurses alapú `make menuconfig` rendszeréhez hasonló külalakú konfiguráló program, és rendkívül szemléletes képet ad az RSBAC policy felépítéséről. Az opcionális MAC modul a SELinux MLS/MCS rendszeréhez hasonlít, de ennek nem igazán szenteltem figyelmet, mint ahogy a még elvontabb/elborultabb PM modulnak sem. A praktikusabb, rendszerközelibb ACL, CAP és RES modulok viszont egyszerűnek de hasznosnak tűnnek számomra.

Az RSBAC a SELinuxhoz hasonlóan inode-onként címkézi fel a fájlokat, de attól eltérően nem magában az inode-ban tárolja a metaadatokat kiterjeszett attribútum formájában, hanem - a fájlrendszerkvóták adatbázisához hasonló módon - minden fájlrendszer gyökérkönyvtárában létrehoz egy /rsbac.dat könyvtárat, és ezekben különféle bináris adatbázisfájlokban tárolja el a teljes policyt minden modulra vonatkozóan. A fájlokra inode-szám alapján hivatkozik, és mivel Linux (de legalábbis ext3 fájlrendszer) alatt könnyen előfordulhat, hogy egy fájl törlése után ugyanabban a könyvtárban egy frissen létrehozott fájl megkapja a törölt fájl inode-számát, megjelentek olyan aggódó hangok, miszerint az RSBAC alatt a törölt fájlok jogait megörökölhetik más, egész más célokat szolgáló később létrehozott fájlok, azonban ez a félelem alaptalan mindaddig, amíg nem mountoljuk fel a fájlrendszereinket nem RSBAC-képes kernellel, mert az RSBAC minden fájl törlésekor minden - az adott fájlra vonatkozó - adatot azonnal töröl az adatbázisából. Az RSBAC egyébként a számos biztonsági modul révén sokkal több metaadatot rendel a fájlokhoz, mint a SELinux, ezért kényelmetlen is lenne azokat xattr formájában tárolni. A SELinux esetében módosított init binárisra van szükség a policyt betöltéséhez, az RSBAC esetében azonban maga a kernel végzi el ezt a munkát, és semmilyen userland programnak nem engedi meg, hogy hozzáférjen a /rsbac.dat könyvtárakban tárolt adatbázisokhoz. Ha nem tévedek, az userland és a kernel RSBAC kódja között az API egyetlen "security" nevű rendszerhívásból áll (legalábbis bizonyos architektúrákon). A SELinux és az RSBAC esetében egyébként azért kell a policyt a bootolási folyamat rendkívül korai szakaszában és speciális módon betölteni a kernelbe, mert amint már említettem, ezek a rendszerek a subjecteket (processzek) és az objecteket (fájlok, IPC csatornák, stb.) speciális metainformációkkal (pl. security context) ruházzák fel, és ezeknek a MAC-specifikus címkéknek - egyebek mellett - a rendszer állapottároló mivoltából kifolyólag a kezdetek kezdetétől fogva jelen kell lenniük a kernel adatstruktúráiban.

Az RSBAC TE/RBAC rendszerében a SELinux sokösszetevős security contextje helyett a subjectek egy egyszerű "role" paraméter alapján vannak osztályozva, az objectek pedig "type" alapján. A processzek, mivel a subject mellett object szerepet is betöltenek, rendelkeznek külön role és type értékkel is. Ennek a TE/RBAC rendszernek a működése leginkább abban tér el a SELinuxétól, hogy itt a kernel egy rendkívül elmés ötlet, nevezetesen a fájlok rc_initial_role és rc_force_role attribútumai segítségével megoldja - mégpedig igen hatékony módon - azt, hogy a processzek UID váltása role-váltást idézzen elő. Mivel tehát a SELinux-szal ellentétben az RSBAC kernel nem csak bizonyos binárisok végrehajtásakor (a SELinuxnál ezt hívját type transition-nek), hanem (R)UID váltáskor is lehetóvé teszi a processzek role-váltását, és amint feljebb írtam, a policyt sem egy módosított init, hanem maga a kernel tölti be, így az RSBAC jóval kevesebb támogatást igényel az userlandtól, mint a SELinux. Ez azt jelenti, hogy az userland-et a pam_rsbac.so modul bevezetésén kívül egyáltalán nem kell RSBAC specifikus módon megváltoztatni. Az SELinuxéhoz hasonló filozófia miatt itt is fennáll a fent említett címkézési probléma az /etc/passw, /etc/shadow, /etc/group, és logfájl jellegű fájlok újragenerálásakor, de a felhasználói adatbázis esetében ezt megoldották egy huszárvágással, nevezetesen a szokásos shadow fájlok helyett a kernelben (illetve a gyökérfájlrendszer /rsbac.dat könyvtárának egyik adatbázisában) tárolt UNIX felhasználói adatbázissal (ennek az eléréséhez szükséges az említett pam_rsbac.so modul), a logrotate vonatkozásában viszont nincs tudomásom hasonlóan egyszerű megoldásról, itt talán a különböző típusú logfájlok elkülönített alkönyvtárakban való tárolása segítene.

Az RSBAC a Grsecurity-hoz hasonlóan (de a SELinuxszal és az AppArmorral ellentétben) nem az LSM infrastruktúrára épül. Ennek oka többek között talán az, hogy az LSM integrációhoz mind az LSM-et magát, mind a szóbanforgó MAC megoldásokat erőteljesen meg kellene reformálni, és ezek az "egyszemélyes" projektek ezt nem tudják, nem is akarják felvállalni. Linus részéről úgy érzem, jogos az az elvárás, hogy az ilyen speciális területeken működő rendszerek egy keskeny, jól körülhatárolható felületen (ilyen az LSM) keresztül érintkezzenek a kernel többi részével, ne pedig több száz különböző helyen beavatkozva, főként talán azért, hogy karbantartó híján könnyen leválaszthatóak, kikapcsolhatóak legyenek, és egy-egy hibájuk miatt ne kelljen váratlan helyeken problémáktól tartani a kernel működésében és viszont. Úgy néz ki tehát, hogy ezek a "renitens" biztonsági projektek örökké a vanilla kernelfán kívül fognak fejlődni, és ez talán jól is van így.

Az RSBAC amellett, hogy teljes értékű MAC rendszer, további - a MAC szabályrendszerével egyszerűen (vagy sehogyan) le nem írható - praktikus biztonsági megoldásokkal szolgál, mint pl. a symlinkek átirányítása (pl. saját /tmp könyvtár mindenkinek és minden démonnak), egy szigorúbb - biztonsági megoldásként is használható - chroot jellegű rendszerhívás, az rsbac_jail hozzáadása, opcionális PaX integráció (ún. enhanced RSBAC kernel használata esetén), vírusvédelmi megoldások támogatása, speciális fájl flag-ek, stb.

Mindezen előnyök ellenére, bár az RSBAC tanulmányozásának korai szakaszában egyértelmű befutónak tartottam ezt a rendszert, később elvetettem a használatát a SELinuxéval összemérhető bonyolultsága okán, valamint amiatt, hogy nem találtam hozzá sem automatikus policy generáló eszközt (a másik három rendszerhez különböző képességekkel rendelkezésre állnak), sem előre gyártott jól kidolgozott policy-kat (igaz, a kernel maga generál hozzá egy nagyon egyszerű alap policyt).

szerk 2011-10-31: Úgy látom, tényleg nem igazán lehet az RSBAC esetében policy generálásról/learning mode-ról beszélni. Az AUTH és ACL modulokhoz van ugyan ilyen, de a policy (valószínűleg) legnagyobb részét kitevő RC modul sajnos nem rendelkezik ilyennel, csak tervezik: http://www.rsbac.org/todo

3.:Grsecurity

A Grsecurity-t majdnem kihagytam a kiértékelésből, mert azt gondoltam róla, hogy túlságosan egyszerű, ezért primitív eszköz, sőt kétségeim voltak afelől, hogy futtatható-e Xen alatt, és hogy elég gyorsan követi-e a vanilla kernel fejlődését. A Grsecurity az RSBAC-hoz hasonlóan csaknem egyszemélyes projekt Brad Spengler irányítása alatt. Ugyancsak az RSBAC-cal rokon módon nem LSM alapú, valamint szintén tartalmazza a zseniális PaX patchet, az RSBAC-cal ellentétben azonban nem opcionálisan, hanem kötelező módon, tehát nincs Grsecurity PaX nélkül.

A PaX a MAC rendszerekkel ellentétben nem a kernel egyébként is meglevő hozzáférésvezérlési döntéshozatalát fejleszti tovább, hanem a futó programoknak a hackerek általi "eltérítését" próbálja megakadályozni, pontosabban a programok memóriatérképének korrupcióját nehezíti meg. Kezdetben ezen cél elérése érdekében a virtuális memória bizonyos lapjainak végrehajtási tilalmával (PAGEEXEC/SEGMEXEC) és memóriatérkép véletlenszerűsítéssel (ASLR) küzdött a PaX, mára azonban több hatékony kiegészítő védelmi módszert vezetett be, pl. a PAGEEXEC/SEGMEXEC módszereknek a felhasználói processzeken túl a kernelre történő kiterjesztését (KERNEXEC), bizonyos típusú kernel exploitok (pl. null pointer dereference) elleni ötletes védelmet (UDEREF), és más szigorításokat a memóriakezelés területén. A PaX védelmi módszerei közül mára már a vanilla kernelben is meghonosodott a PAGEEXEC jellegű végrehajtási tilalom (de csak az ezt hardveresen támogató CPU-kon), és az ASLR, de a PAX megoldásai ezeken a területeken is radikálisabbak és hatékonyabbak.

A Grsecurity Xen alatti futtathatóságára vonatkozó aggályaimat a PaX weboldala okozta, itt ugyanis csak ősöreg verziókat találtam. Észerevettem azonban, hogy a Grsecurity letöltő oldalain található Grsecurity és PaX patch verziók gyorsabban követik a kernel fejlődését, mint ahogy azt egyáltalán elvárhatónak tartanám. Kipróbáltam hát, hogy lefordítható és futtatható-e Xen domU-ban, és azt tapasztaltam, hogy rendkívül stabilan működik. A kezdetektől használom nagy terhelésű éles rendszeren is, és soha nem történt egyetlen összeomlás vagy akár kisebb rendszerhiba, még live migration közben sem. Csak az szomorított el, hogy a KERNEXEC és UDEREF védelmek nem kompatibilisek a Xen hypervisorral, ezért nem tudom őket használni :-(

A Grsecurity a SELinuxtól és az RSBAC-tól eltérően, de az AppArmorral megegyező módon egyrészt nem absztrakt címkék (pl. security context) alapján osztályozza a subjecteket és objectetek, hanem a vanilla kernel által már egyébként is biztosított metainformációk alapján (pl. (R)UID/(R)GID, elérési út/fájlnév), másrészt nem igényli a fájlok felcímkézését sem, mert a fájlokhoz való hozzáférést nem valamilyen inode-hoz köthető (vagy azokban tárolt) metainformáció, hanem egyszerűen a fájlok elérési útja/neve alapján végzi. Ennek két fő előnye van: egyrészt a Grsecurity (és az AppArmor) policy-ja összehasonlíthatatlanul egyszerűbb és átláthatóbb, mint a SELinuxé és az RSBAC-é, másrészt ezek a MAC megoldások a bootolási folyamat tetszőleges pontján (vagy akár a rendszer aktív futása közben) aktiválhatóak deaktiválhatóak és tetszőleges mértékben átkonfigurálhatóak.

Az elérési út alapú (path based) hozzáférésvezérlés azonban nem mindenki szerint bír létjogosultsággal (bővebben ld. a fentebb már hivatkozott http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-b… posztban). Joshua Brindle cikke alapos és jól bemutatja az "inode tábor" sokszor jogos érveit, de van benne szerintem néhány csúsztatás, vagy azóta elavult információ: A path alapú MAC megoldások gyengeségéül rója fel pl., hogy nem minden Linux kernel objektum rendelkezik névvel/elérési úttal, ezért ezeket nem is lehet fájlnévvel illetni. Nos, ez igaz (mint ahogy az is, hogy a Grsecurity és az AppArmor biztonsági szűrőinek felbontása durvább szemcsézettségű a SELinux-énál és az RBAC-énál), de ezek az objektumok a vanilla Linuxban pontosan ugyanannyira nem rendelkeznek security contexttel sem, csak miután a SELinux felcímkézi őket.
A path alapú megoldások hibájául rója fel azt is, hogy azok a közös használatú könyvtárakban a Linux DAC segítségére szorulnak a különböző felhasználók fájljainak megkülönböztetése érdekében. Ez így van, de az alapértelmezett targeted policy esetében a SELinux is nagyban a DAC-ra alapoz hasonló szituációkban.
A "Binaries aren’t processes" bekezdés szerint hiba, hogy az azonos bináris végrehajtásából származó processzek a MAC szempontjából azonos jogokkal futnak a path alapú rendszerekben. Amint később látni fogjuk, ez a Grsecurity-re sohasem volt igaz (sőt, talán az összes rendszer közül a legjobban kezeli ezt a problémát), és a pam_apparmor.so modul, valamint többféle öröklési szabály megjelenése óta az AppArmor újabb változatai is a SELinuxéhoz hasonló szintű megoldással álltak elő ezen a téren.
Azzal vádolja továbbá az path alapú megoldásokat, hogy a gyengeségeiket ellensúlyozandó, az alkalmazások módosítását igénylik, holott a fentiekben kifejtettem, hogy más "hiányosságai" révén a SELinux élen jár abban, hogy csak módosított userland-del legyen képes futni (igaz, ott standard rendszerösszetevőket, nem pedig speciális alkalmazásokat kell módosítani).
A poszt kommentjeit is érdemes elolvasni, hogy képet kaphassunk mindkét oldal érveiről. Azt el kell ismerni, hogy helytálló a legerősebb érve, miszerint a GNU/Linux esetében az elérési út nem jelöl olyan egyértelműen egy fájlt, mint az inode-ja, mert hard linkek, névterek, --bind opciós mountolások révén ugyanaz a fájl több helyen is feltűnhet. Klasszikus példa ezen probléma szemléltetésére az a helyzet, amikor egy path alapú MAC megoldás megpróbálja megvédeni a /etc/shadow fájlt az illetéktelen hozzáférésektől, de ha egy támadó sikeresen létrehoz egy hard linket a shadow fájlról mondjuk a /tmp könyvtárban, akkor - mivel ez az utóbbi link path alapján nem részesül a /etc/shadow-val egyenrangú védelemben - az új elérési úton keresztül illetéktelenek is módosíthatják a felhasználói adatbázist. A path alapú megoldások hívei erre válaszul felvethetik, hogy mi van, ha a védendő fájl valamilyen okból, pl. szoftverfrissítés miatt vagy mentésből történő visszaállítás során elveszti a security contextjét hordozó címkét? Ilyen esetekben az inode alapú védelem mondana csődöt, a path alapú viszont zavartalanul biztosítaná a folyamatos védelmet.
Mindkét típusba tartozó MAC rendszerre jellemző, hogy amíg aktívak, mindent megtesznek az ellen, hogy a gyengeségeiket ki lehessen használni: Csak a megbízhatónak minősített programok szűk körének engedélyezik a mountolást, hard linkelést, névtér létrehozást, security context címke-módosítást, stb., egy szóval a lehetőségeikhez mérten közelítenek a legkisebb jogosultság elvének betartásához. És ez az, amiben a négy vizsgált rendszer közül átlagosan talán a Grsecurity teljesít a legjobban éles környezetben.

A Grsecurity MAC megoldásának, az ún. RBAC rendszernek két hatalmas előnye van: a nagyon egyszerű, ugyanakkor praktikus és erőteljes policy szintaxis, és egy rendkívül hatékony tanuló mód (learning mode). Ezen előnyöket kihasználva speciális IT biztonsági szakismeretek vagy hosszas tanulás nélkül is könnyedén készíthetünk olyan policyt, amely nem csak bizonyos szolgáltatásokat szorít szigorú keretek közé (mint a SELinux általánosan használt targeted policyja vagy az AppArmor disztribútor által szállított gyári házirendjei), hanem a SELinux strict policyjához hasonlóan (illetve a tökéletes testreszabottsága okán még szigorúbban) érvényesíti a legkisebb jogosultság elvét.

A Grsecurity RBAC rendszere a processzeket (R)UID/(R)GID alapú role-okba vagy domain-ekbe, és ezen belül (a processzekek binárisainak elérési útja alapján) subjectekbe szervezi. Ez a kétszintű hierarchia a subjectek execve híváson keresztüli átörökítését lehetővé tevő szabályokkal kiegészítve egyszerű, de rendkívül hatékony és flexibilis policy struktúrát eredményez, ráadásul olyat, aminek a generálása jól automatizálható, és ezt a Grsecurity ki is aknázza a gradm parancs segítségével. A role/subject elrendezés univerzális módon oldja meg Joshua Brindle cikkének "Binaries aren’t processes" bekezdésében felvetett problémát. A policy hatékonyságára jellemző, hogy semmiféle userland támogatást vagy nem igényel! A Grsecurity userland-je a PaX specifikus parancsokat is beleértve két-három binárisból és egyetlen konfigurációs könyvtárból áll. A policy egyetlen szöveges fájlban van, a teljes userland kb. tíz fájlt tesz ki.

A Grsecurity az RSBAC-hoz hasonlóan az előbbiekben felvázolt RBAC rendszeren felül további praktikus, a /proc/sys felületen keresztül ki- és bekapcsolható védelmi "trükkökkel" rendelkezik. Itt is teljes értékű biztonsági megoldást faraghatunk a chroot rendszerhívásból, aktiválhatjuk az erőteljes Trusted Path Execution védelmet, szigoríthatjuk a /proc fájlrendszeren keresztül elérhető adatokhoz való hozzáférést, stb., de symlink átirányítás sajnos nincs.

A Grsecurity dokumentációja jól érthető, de nem éreztem elég alaposnak (talán el kellett volna olvasnom ezt meg ezt is?), ezért az IRC-s közösség unszolására kénytelen voltam kiegészíteni. A projekt pár évvel ezelőtti "haldoklását" meghazudtolva látszólag szépen fejlődik. Nem tudom, hogy csinálják a fejlesztők, de remélem sokáig aktívak tudnak maradni. Az egyetlen, ami aggasztott a Grsecurity-vel kapcsolatban, az az, hogy egy-két hetes tanulmányozása után nem éppen elhanyagolható bugokat találtam benne. Ezeket Brad Spengler szerencsére órákon belül kijavította, sőt, a javaslataim alapján nekiállt, hogy kicsit átdolgozza a soft- és hard linkek kezelését. Ez a munka most is folyamatban van (nem tudom, milyen fazisba jutott éppen), ezért az általam írt kiegészítő doksi egy-két bekezdésének pontossága és időszerűsége kérdéses.

4.: AppArmor

Legutoljára maradt az AppArmor, amely a SELinux-hoz hasonlóan az LSM infrastruktúrára épül, és része a vanilla kernelnek (igaz, csak a 2.6.36-os verzió óta). Kezdetben az Immunix, később a Novell, jelenleg pedig az Ubuntut kiadó Canonical a fő fejlesztője. Az AppArmor a Grsecurityhez hasonlóan elérési út/fájlnév alapú biztonsági megoldás, de a MAC rendszeren felül nem tartalmaz kiegészítő védelmi mechanizmusokat.

A dokumentációjából hamar kitűnik, hogy az AppArmor policy szintaxisa is kísértetiesen hasonlít a Grsecurity-ére, de sajnos sajnos hiányzik a role/domain fogalma, bár a 2.7-es verziótól tervezték egy erre emlékeztető, de valószínűleg kevésbé erőteljes eszköz bevezetését, de úgy tűnik, nem sikerült teljesíteni a tervet, mert a 2.7-es kiadás még mindig a 2.5-ös verzió kernel kódját használja.

A grsecurityben subjectként megismert fogalom itt "profile"-ként köszön vissza. A role-ok hiánya sajnos azzal jár, hogy a SELinuxhoz hasonlóan a kernel-beli MAC kód nem tesz semmit annak érdekében, hogy a különböző UID-del/GID-del futó processzek különböző jogokat kapjanak, vagyis igazzá válik Joshua Brindle "Binaries aren’t processes" címszó alatt megfogalmazott kritikája. Ezt a gyengeségét az AppArmor a SELinux módjára az userland közreműködésével kompenzálja az aa_change_hat és aa_change_profile rendszerhívásokat(?) valamint a pam_apparmor.so modult mozgósítva.

Az AppArmor profilok a Grsecurity subjecteknél flexibilisebb módon rendelhetőek hozzá a processzekhez (ami nem meglepő, hiszen részben rájuk hárul a role-ok hiányának kompenzálása). Az objectekre megadható végrehajtási jogot (x) négyféle - az öröklést szabályozó - módosító flag-gel láthatjuk el, ráadásul a négyféle flag közül három lehetővé teszi az AT_SECURE glibc paraméter explicit átadását a vermen keresztül a környezeti változók biztonsági célokat szolgáló kigyomlálásának érdekében.

Az AppArmor általában a disztribútorok által előre gyártott, a SELinux targeted policy-jéhez hasonló módon csak bizonyos kiválasztott rendszerszolgáltatásokat korlátozó policy-vel érkezik, de ezek egyszerűen szerkeszthetőek, sőt policy-generáló segédeszköz is rendelkezésre áll. Az AppArmorban egyébként a többi MAC megoldásnál természetesebb módon valósítható meg a kiválasztott szolgáltatások korlátozása és a rendszer többi részének korlátlan jogosultságokkal történő futtatása, ugyanis a másik három rendszer szigorú "minden tilos, amit nem szabad" elvével szemben itt korlátoktól mentesen fut minden processz, amihez nem rendelünk profilt (a profilokon belül azonban már itt is érvényesül a "minden tilos, amit nem szabad elv").

Összességében az a benyomásom, hogy a biztonsági profilok processzekhez kapcsolása leginkább a SELinux hasonló funkciójával rokonítható, az objektumok osztályozása viszont a Grsecurity módszerére emlékeztet.

A fenti négy MAC rendszeren kívül további hasonló biztonsági megoldások is elérhetőek a GNU/Linux rendszerekhez, pl. a TOMOYO Linux (amelynek doksijában egy érdekes race condition-ről olvastam, ami más path alapú (de azok közül legalábbis az LSM-re épülő) megoldásokat is érinthet, pl. az AppArmort), aztán a Smack, a LIDS, stb., de ezekkel nem foglalkoztam. Az én összehasonlításom győztese toronymagasan a Grsecurity/PaX. Ezzel a témát lezártam, a betegszabadságomnak is vége. Megyek dolgozni, szevasztok.

Ja, még egy kérdés: Ti mit használtok, és miért?