RSBAC kritika
Kedves HUP közösség!
A múltkori SELinux-os fórum után szeretnék veletek néhány szót az RSBAC-ról is váltani. Tulajdonképpen onnan indult ki az egész, hogy "SLES11 SP1-ben szeretnék két cron példányt futtatni. Egyet a rendszerfeladatoknak, és egyet a felhasználóknak. Az előbbi férjen hozzá minden erőforráshoz, amihez eddig, kivéve a felhasználói crontabokat, az utóbbi pedig csak a felhasználói crontabokhoz, és még néhány, erősen behatárolt körbe eső objektumhoz, pl wget /dev/null, hálózat, stb. Úgy gondoltam, valamilyen MAC megoldást veszek igénybe, és úgy döntöttem, hármat vizsgálok meg részletesebben: SELinux, AppArmor, RSBAC."
Az RSBAC-on még mindig nem rágtam át magam teljesen, főleg azért, mert nem találtam átfogó felhasználói doksit. Aki RSBAC-ot használ, az hol tanulta meg?
Az RSBAC-cal kapcsolatban a következő érdekességeket találtam: Míg az AppArmor a fájlok elérési útja alapján korlátoz, a SELinux pedig (a UNIX DAC mintájára) minden fájl saját inode-jába, security: típusú extended attribute-ba menti el a SELinux-specifikus biztonsági attribútumokat, addig az RSBAC egy harmadik utat választ: A teljes policyt (a fájlok RSBAC-specifikus biztonsági attribútumait beleértve) az AppArmorhoz hasonlóan külön adatbázisban tárolja, de attól jelentősen eltérő módon, ugyanis:
-Minden fájlrendszer gyökérkönyvtárában külön adatbázisa van egy /rsbac.dat nevű könyvtárban. (Míg az AppArmornál az egész policy az egyetlen közös /etc/apparmor.d könyvtárban van.)
-Az RSBAC-nál a policy adatbázisok nem szöveges, hanem bináris fájlokból állnak, és nem userland programok, hanem maga a kernel kezeli őket (az aquota.user és aquota.group fájlokhoz hasonlóan).
-Annak ellenére, hogy a fájlok RSBAC-specifikus attribútumai nem az inode-okban tárolódnak, mégis inode szám alapján hivatkoznak a fájlokra (nem pedig név alapján, mint az AppArmornál).
A legutóbbi pontban felvázolt RSBAC-AppArmor eltérés sok vitára ad okot. Sokan helytelennek tartják az AppArmor hozzáállását, mivel a UNIX-okban a fájlok biztonsági attribútumai az inode-okban tárolódnak, semmi közük sincs az elérési útjukhoz (pl. öröklés sincs, mint a Windowsban), akárhol hozunk létre akármilyen típusú rájuk mutató linket, mindig az "eredeti" fájl indode-jában tárolt érték lesz a mérvadó. Ez igaz, de utánanéztem (nem vagyok programozó), és úgy találtam, hogy inode szám alapján nem lehet hivatkozni egy fájlra, csak elérés út vagy file descriptor alapján. A file descriptor pedig szintén elérési útból keletkezik, kivéve, ha egy socketen keresztül kapjuk. Ezt figyelembe véve talán mégis megfelelőnek tűnik az AppArmor megoldása, kivéve, ha arra gondolunk, hogy a korlátozandó programfájlról létrehozunk egy hard linket, és voila, az új programot máris nem korlátozza az AppArmor, az RSBAC (és a SELinux) viszont igen, hiszen a hard link inode-ja és inode száma megegyezik az eredeti fájléval. Ráadásul hard linket elég könnyű létrehozni, elég ha rx jogunk van az eredeti fájl szülőkönyvtárához, és rwx jogunk a célkönyvtárhoz. Itt tehát úgy tűnik, hogy elfogadhatatlanul gyenge az AppArmor, viszont mi van, ha hard link helyett másolatot készítünk a szóbanforgó programfájlról? Az már nem fogja korlátozni az RSBAC sem, és másolatot sem sokkal nehezebb készíteni mint hard linket. Csak annyival több jogra van hozzás szükség, hogy olvasni is tudnunk kell a forrásfájlt. Akkor megérte hát az inode-os izmozás?
A másolás és a linkelés (valamint sok más probléma) ellen védelmet nyújthat, ha minden - a felhasználók által - írható könyvtárat noexec módon mountolt partícióra rakunk. Így a hard link már el sem készülhet, már más fájlrendszeren lenne, a másolat pedig nem lesz végrehajtható. Ha szoft linket készítünk, az ugyan végrehajtható lesz, de a szoftlinkeket az AppArmor sem magának a linknak, hanem a célpontjának az elérési útja alapján ellenőrzi. Hunger rávilágított, hogy a noexec egy komoly támadóval szemben nem jelent védelmet, de én úgy érzem az általa leírt Linuxos noexec "sebezhetőség" nem a jelenti noexec teljes haszontalanságát. Vagy van más megkerülési mód is?
Nem vagyok egyedül azzal a meglátásommal, miszerint az AppArmor elérési út alapú védelme sok előnyt hordoz magában az RSBAC inode szám (és nem inode) alapú védelmével szemben. RSBAC-nál pl. ha frissítünk egy programot, tehát letöröljük a régi verziót, majd létrehozzuk az újat, akkor az új programfájlt inode száma minden valószínűség szerint el fog térni a régiétől, így nem fogja védeni az RSBAC. Sőt, mi történik, hogy az letörölt eredeti fájl felszabadult inode számát megkapja egy új, teljesen más célt szolgáló fájl? Akkor - teljesen értelmetlen módon - azt fogja lekorlátozni az RSBAC! Sőt, mivel /rsbac.dat könytárakban tárolt policy tényleg csak az inode számokra hivatkozik, a fájlneveket pedig semmilyen módon nem tárolja, ezért ha letörlünk egy általa hivatkozott védett fájlt, akkor nem fogjuk tudni kinyerni a policyből, hogy mit is kell védenünk. Le kell tárolnunk a policyt olyan formában (szöveges, fájlnevekkel operáló), hogy újra alkalmazni tudjuk a rendszerfrissítések után. Az újraalkalmazás legjobb módja pedig néhány RSBAC szekértő szerint az, ha újraindítjuk a rendszer egy "maintenance kernellel", alkalmazzuk a policyt, és megint bebootolunk a sima RSBAC kernellel. Két újraindítás minden szoftverfrissítéshez?!
Tudom, hogy a MAC-en felül sok kiváló szolgáltatást biztosít az RSBAC, ezért is keltette fel az érdeklődésemet. Tetszik pl. a PaX integrációja, de sajnos Xen alatt nem sikerült még beindítanom semmilyen PaX-os kernelt. (Sikerült viszont a 3.0.3-as kernel elindítanom PaX nélküli RSBAC-cal. Nem is rossz eredmény.) Annak ellenére, hogy az RSBAC nagyon jónak tűnik, a fenti "visszásságai" kicsit megdöbbentettek. Van valaki, aki szerint mégis érdemes továbbra is foglalkoznom vele? Mennyire elterjedt egyáltalán?
- Tovább (RSBAC kritika)
- 4210 megtekintés