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

 ( nice | 2011. október 28., péntek - 20:37 )

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/SELinux_Guide/index.html
- 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-based-access-control/ 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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Izé... ez most akkor egy blog, csak véletlenül a fórum szekcióban, vagy lesz valami kérdés is?
Vagy mi ennek most voltaképp a célja?

Gabut ismerve mar az is kerdes, hogy van-e egyaltalan celja. De inkabb hagyd, ez meglepoen jo cikknek igerkezik, engem erdekel a vege.
Hosszabb ideig dolgoztam SELinux-szal es RSBAC-cal is, na nem mint jogalkoto, hanem mint rendor, vagyis a jogok betartatoja. Nekem talan a SELinux szimpatikusabb, jobban hasonlit a normal POSIX jogokhoz, am ugyanakkor megeroszakolja a rendszert, ez viszont kevesbe tetszik. Sok jot hallottam a GRsec-rol is, most mar erdekelnek az arnyoldalai is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem vagyok Gabucion, de az mondjuk jogos, hogy inkább a blog szekcióba kellett volna írnom, viszont mivel nem használtam még, nem jutott az eszembe. Bocs.

Egyébként a POSIX ACL-ekkel a Gabu által leírtaknál sokkal nagyobb gondok vannak a GNU/Linux rendszereken. Elsősorban az a baj, hogy az alap userland (pl. GNU tar) nem igazán támogatja, és sok alkalmazás összezavarodik tőlük, aztán meg összezavarja őket. Egy időben kiterjedten haználtam a POSIX ACL-eket, de aztán a problémák miatt visszaszorítottam őket.

Megkovetlek. Mentsegemre szolgaljon, hogy a fent nevezett nickvaltasait mar nem tudom kovetni szemmel.

Igen, de a backupolashoz lehet olyan eszkozoket hasznalni, melyek tamogatjak ezeket az attributumokat, bar teny es valo, nem duskalunk bennuk.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én a star-t találtam meg, de nem tetszett, mert nem tud(ott?) inkrementális mentéseket csinálni. Meg hát a GNU tar noatime opciójáról sem akartam lemondani.

Viszont a mentéshez találtam egy jó dolgot, amit a gyakorlatban még nem próbáltam ki: http://linuxgazette.net/114/kapil.html

Device Mapper alapú snapshot LVM nélkül! Majdnem olyan jó, mint a Microsoft Volume Shadow Copy.

Érdekes a cikk, köszi.

Hopp, elírtam. Természetesen nem noatime, hanem az --atime-preserve=system opcióra gondoltam:

http://nice.nyme.hu/mentes.pdf

Lehet én rontottam el valamit, de nálam ezek az acl jogok jól működnek. Igaz nem bsd-n hanem linux-on és nem 2007 van hanem 2011 :)
A tar-t még nem néztem meg, de mindjárt arra is teszek egy próbát, hogy mi lehet amibe belezavarodik.

mire gondolsz hogy megerőszakolja a rendszert? én is SELinux-al dolgozom de nekem nem tűnik annak.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix_art.webmuvek.hu/
https://sites.google.com/site/jupiter2005ster/

> Vagy mi ennek most voltaképp a célja?
A kérdés jogos, engem is érdekel. De a lényeg, ha mázlink van, kapunk valami jól összefogott infomációt :-)

Hát, őőőő... Nem tudom, mázlitok lesz-e. Ahhoz jobb szakembernek kellene lennem, vagy még többet kellett volna foglalkoznom a témával. Mindenesetre elkészült.

Szerintem ez pont jobb a fórum-ban, mivel érdekes és értékes anyag, és legalább nem súvad el hamar a blog-ban ha van új hozzászólás.

sub

+1

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

subscribe

+1

+1

+1

+1

+1

+1

+1

+1
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.37 | 2.6.39.3-janos

+1

++

+1

+1

+1

Folyamatos szerkesztés alatt...
Kellene changelog is.
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

Már nincs szerkesztés alatt. És remélem, soha többé nem is lesz ;-)

(Másvalaki még beleszerkeszthet ugyan, de nekem elegem lett.)

Ezt érdemes lenne kitenni a HupWiki-be, ha kész lesz.

Joshua-val egyébként egyszer próbáltam beszélni IRC-n, de egyoldalú volt az információk áramlása és nem jött létre kétirányú kommunikáció. Mindenre visszakérdez, hogy mi a biztonsági modelled? És szerinte minden biztonsági modellre az SELinux a válasz. Ha mégsem, akkor rossz a biztonsági modell. Zseniális!

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ja, ő volt az, akit a másil szálban említettél? Végül is biztos igaza van sok szempontból. Mi is elfogultak vagyunk, ugyebár.

Miattam felkerülhet a HUPWikire, de előbb átnézhetné valaki, aki ért hozzá.

Szerk: erre gondoltam: http://hup.hu/szavazasok/20080811/milyen_opcionalis_biztonsagi_megoldast_alkalmazol_a_linux-hoz

nice.

Számomra nagyon jól összeszedett írás, fárasztó lehetett. Köszi szépen a munkát és hogy megosztottad.

Én egy dolgot szűrök le: ezek a megoldások soha nem lesznek nagy mértékben felhasználva éppen a bonyolultságuk miatt. Ráadásul ilyen komplexitási foknál (ahogy írtad, a RHEL-ben a targeted policy is több százezer szabály) az esély a policy helyességének igazolására egyre kisebb. Most akkor gondoljunk bele egy admin esetében. Bocs hogy ismétlem magam, de azt gondolom, hogy hiába tud sokat, ha "senki" nem fogja használni. Márpedig a közös cél az kellene legyen, hogy minél nagyobb körben minél szélesebb rétegeknek lehessen / kelljen biztosítani alapból, hogy a rendszerük minél jobb biztonsági fokkal rendelkezzen, és így globálisan a nagy egészet védje ez együtt (úgy hogy nem válnak zombikká ők sem).

Szerintem a konfigurálhatóság mértékét növelni és ezzel túlbonyolítani egy megoldást nem annyira nehéz, mint ellenben úgy növelni egy szoftver vagy megoldás tudását, hogy közben megteremtjük a lehetőségét az egyszerű módú felhasználásának.

Nekem a path alapú MAC megoldásokban az tetszik, hogy egyrészt nem jelentkezik az általad feljebb vázolt probléma, amikor egy új fájl vagy meglévő már context beállítással rendelkező fájl módosításra vagy létrehozásra kerül - hanem mivel csak a teljes elérési út a meghatározó a policy-ban, ezért nagyon egyszerű, átlátható is és könnyebben kezelhető (ahogy te is írtad a grsecurity-s résznél) - másrészt pedig a userland módosítása nélkül transzparens módon tud működni (de szó se róla, a fejlesztők által is elismert és dokumentációban megtalálható, hogy nem közelítik meg a SELinux biztonságát). Viszont Tomoyo-hoz pl. most fejlesztik az IPC támogatást. Azzal már azért elég jó alternatíva lehet szerintem. A lényeg úgyis a megvalósításon lesz, vagyis nyilván ha a kernel oldalt rendesen implementálják, akkor azért nagy lyukat foltoz a rendszeren (megint csak szerintem). Nyilván nem mindegy, hogy a labdát a hátam mögé dobva egy kukába vagy egy pohárba kell beletalálni.

Apropó: Tomoyo-nál nincs semmi féle öröklés (mint amit AppArmor esetében említettél). Egyszerűen úgy van megoldva, hogy egy process által meghívott másik process a szülő process domain-je alá lesz rendelve, és erre külön policy-nek kell vonatkoznia. Másképp fogalmazva: minden le van fektetve a policy-ben. Azt hiszem ennél előrelátóbb és egyszerűbb nem is lehetne. Megint csak had ajánljam, hogy ha már az általad választott Grsecurity is path alapú, nézz rá Tomoyo-ra (ha lenne hozzá kedved és energiád). Annyira faék, hogy szerintem 10 perc alatt átlátnád a teljes működését.

Két kérdésem van:

A fenti kutatásod alapján elképzelhetőnek tartod, hogy ilyen komplexitású rendszert kezeljél folyamatosan visszatérően hatékony módon a hatalmas policy manuális állítgatásával? Egyáltalán kezelhetőnek tartod a gyakorlatban? Lehet egy ilyen rendszerhez visszatérni hónapok után mondjuk anélkül, hogy sok időt töltene az ember a policy és a kialakított struktúra újratanulásával? És sok különböző rendszer esetében? Nem ütközünk itt már bele az emberi korlátainkba?

Másik: Miért nem olyan irányba folynak az ilyen nagyobb komplexitással rendelkező megoldások fejlesztése, ahol a használhatóságot tartják főbb szempontnak? (Pl.: policy létrehozást segítő egyszerű és _használható_ profi megoldások). Talán a használhatóság az egyszerűséggel együttvéve lehetne a megbízhatóság és minél nagyobb hiba mentesség alapja.

"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."

Erre azt tudom mondani, hogy nézd meg Tomoyo-t. Path alapú, de a nem path-os objektumokhoz más értéket rendel (pl. umask, vagy az értékek az allow_ioctl szabályokban).

"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."

Itt már megkérdőjelezem a túlbonyolítás értelmét a kezelhetőség terhére. Ráadásul ha akarom, akkor lemásolom a binárist másik néven és ahhoz tudok csinálni külön policy-t.

"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..."

Szerintem ez így nem igaz.

"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."

Ezt ki fogom próbálni Tomoyo-val. De ahogy láttam, Tomoyo visszaold mindent az eredeti path-ra (értelem szerűen), symlinkeket, és titkosított partíciónál is az absztrakt path-okat. Mindenesetre érdekes és megnézem majd.

A tanuló módhoz meg csak annyit, hogy használd, aztán írd meg majd a véleményedet :) Már írtam itt, hogy szerintem az ugyanúgy szívás, mert minden rendszer update-nél vagy egyéb használatból eredő rendszer és környezet változások miatt lehet újra csinálni az egészet.

A Grsecurity-s rész utolsó bekezdéséhez gratula, tényleg belemásztál :)

Hát, azért kutatásnak nem nevezném, amit csináltam. Hogy egy klasszikust idézzek: "r=1 vagyok, de ugatok."

A grsecurity fejlesztők szerintem soha nem nyilatkozták azt, hogy a rendszerük biztonsága kisebb lenne a SELinuxénál: http://lists.immunitysec.com/pipermail/dailydave/2007-March/004133.html (szerk: rájöttem, hogy az AppArmorra gondoltál. Jogos.)

Csak a SELinuxot (és talán az RSBAC-ot, de abba nem mentem annyira bele) tartom elfogadhatatlanul bonyolult megoldásnak a fentiek közül, de emberileg simán lehetségesnek tartom, hogy valaki hatékonyan használja, de ahhoz már komoly szakembernek kell lenni. Még azt is el tudom képzelni, hogy bizonyos szituációkban jól jönnek az ilyen bonyolult rendszerek. Az AppArmor és a Grsecurity RBAC rendszere azért tényleg elég durva szemcsézettségű.

Ránéztem pár mondat erejéig a Tomoyo-ra. Lehet valami abban, hogy a Tomoyo "visszaold mindent eredeti pathra", mert a dentry+vfsmount értékekből számolja vissza path-ot. Nem tudom pontosan, mit jelent ez, de az apparmor is ezt csinálja. A grsecurity nem tudom, hogy oldja meg ezt. A Tomoyonál valami olyasmit láttam, hogy "hierarchikus" a policy-je, és a hierarchia annyadik szinten jár, ahányadik processzgenerációt vizsgáljuk a kernelhez képest. Szép, elegáns megoldás, de a grsecurity és az rsbac uid/gid-et is figyelembe vevő biztonsági modelljét nem felesleges bonyolításnak gondolom, hanem a gordiuszi csomó átvágásának, ami éppen hogy leegyszerűsíti a rendszert, és nem értem, miért nem gondoltak rá a többiek.

Mindegy milyen értelemben vesszük a kutatást.

Igazad van, nem írtam hogy AppArmor-ra és Tomoyo-ra gondoltam.

"A Tomoyonál valami olyasmit láttam, hogy "hierarchikus" a policy-je, és a hierarchia annyadik szinten jár, ahányadik processzgenerációt vizsgáljuk a kernelhez képest. Szép, elegáns megoldás, de a grsecurity és az rsbac uid/gid-et is figyelembe vevő biztonsági modelljét nem felesleges bonyolításnak gondolom, hanem a gordiuszi csomó átvágásának, ami éppen hogy leegyszerűsíti a rendszert, és nem értem, miért nem gondoltak rá a többiek."

Elmondom miért egyszerű és jobb ez szerintem.

Tényleg hierarchikus, viszont megteheted, hogy egy adott binárisra mindig ugyanaz a policy vonatkozzon. Ehhez csak az exception_policy.conf-ba be kell tenni a binárishoz pl. ezt:

initialize_domain /usr/bin/ssh

Ez azt jelenti, hogy bármilyen domain-ből kerül meghívásra ez az ssh bináris, mindig azokat a szabályokat fogja használni, amelyek a domain_policy.conf-ban ez alatt vannak definiálva:

kernel /usr/bin/ssh

(Egyébként nagyon sok domain transzformációs mód beállítható az exception policy-ben, keress rá pl. az aggregator-ra is.)

Viszont sok esetben ezt nem szeretnénk, mert pl. a shell binárist sok más folyamat is meghívja, és nyilván a leg nem megengedőbb szabályrendszert szeretnénk, és ez akkor lesz csak, ha minden egyes meghívott shell-nél csak annyit engedünk neki, amely ebben az aldomain-ben vonatkozott rá.

Nálam az ssh domain hívás így néz ki:

kernel --> ssh
kernel --> ssh --> dash
kernel --> ssh --> dash --> xauth

Itt van a tomld-mmel átszabott ssh-ra vonatkozó megtanult policy. Itt az látható, hogy habár ssh meghívja a shell-t, annak mégis csak annyi van megengedve, hogy a szükséges lib-ek felolvasásán kívül csak az xauth binárist indíthassa el. (A use_profile értke csak annyit tesz, hogy kikapcsolva (0), tanuló (1), engedő (2), vagy kikényszerítő (3) módban van-e jelenleg a domain, tehát ez a teljes policy).

Egyébként az UID / GID-el tudsz kombinálni Tomoyo esetében is ha akarsz (szintén exception policy-ből ha jól rémlik), most már nem keresek link-et, de ha kell máskor megteszem.

A grsecurity visszaköveti a symlinkeket. Bár erről szerintem te már többet tudsz... :-)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem a symlinkekről volt itt szó, hanem arról, hogy Joshua szerint a path alapú rendszerek döntése nem lehet egyértelmű, mert hard linkek, bind mountolások, chrootok és külön névterek miatt ugyanannak a fájlnak több elérési útja is lehet. A hard linkekkel tényleg nem lehet mit kezdeni, a chroot-okat viszont "lebontja" a Grsecurity. A bind mountolások esetében viszont nem törekszik az "eredeti" útvonal visszafejtésére, a névtereket pedig nem próbáltam.

Megnéztem, Tomoyo esetében is ugyanaz a helyzet: hardlink-et és bind-ot nem bontja vissza az eredeti path-ra, chroot-ot viszont igen.

Na de hiába a hardlink, annyiból akkor már le is másolhatnám az eredeti binárist. Más path-ra már más policy fog vonatkozni. Ha nem szerepel a domain szabályai között egy "allow_execute" ahhoz az új path-hoz, nem tudja futtatni. A régi binárist pedig nem lehet felülírni hardlink-kel (amely egy új path-ra mutat), mert eleve nincs is a saját binárisához olvasási vagy írási engedély, maximum "allow_execute"-ok vannak futtatható binárisokhoz.

Egyedül a bind-ot érzem gáznak, mert ott létező mappát is felül mount-olhatunk úgy, hogy ugyanaz-on a path-on már más tartalom látszik. De épp a fenti miatt a bind-ot sem lehet mount-olni, ha nincs hozzáférése a bin mappákhoz - még ha root joggal is fut az adott process.

Később letesztelem még a bind-ot C-ből.

Mindenesetre érdekes lenne egy olyan tanulmány (ha létezik), amely bemutatna egy ilyen egyszerű kikerülési módot a path alapú MAC rendszerekhez - ha egyáltalán tényleg megoldható - amit természetesen úgy értek, hogy minden esetben. Ha megengedem a domain-nek hogy felmount-olja az általa futtatott binárisainak mappáját bind-dal, akkor ne csodálkozzunk.

> hardlink-et és bind-ot nem bontja vissza az eredeti path-ra

Mit ertesz hard link eseten eredeti path-on?

udv,
tompos

Ugye itt nincs is eredeti path, mert FS szinten van implementálva, csupán így fogalmaztam.

Tehát ha van egy /tmp/d1/f1 fájlom és azt hard-linkelem a /tmp/d2 mappába f2 néven, akkor ennek a fájlnak az olvasása után a domain szabályai közt tanuló módban az alábbi szabály jön létre:

allow_read /tmp/d2/f2

Itt Tomoyo nem a /tmp/d1/f1 path-t jegyzi be, és nem is erre old vissza. Persze ez érthető, mert a hardlink az teljesen külön fájl (inode), csak a tartalom egyezik meg.

Tehát ha eredetileg is létezne egy hardlink a szabályok közt meglévő "allow_execute" path-hoz, és ehhez a másik path-hoz lenne a domain-nek írási joga, akkor megváltoztathatná a futtatandó binárist tetszés szerint. Ez persze azért sok feltétel önmagában imho.

> Persze ez érthető, mert a hardlink az teljesen külön fájl (inode), csak a tartalom
> egyezik meg.

Hogy mivan?:)

> Tehát ha eredetileg is létezne egy hardlink a szabályok közt meglévő "allow_execute" > path-hoz, és ehhez a másik path-hoz lenne a domain-nek írási joga, akkor
> megváltoztathatná a futtatandó binárist tetszés szerint. Ez persze azért sok
> feltétel önmagában imho.

Itt csak sejtem, h mit akarsz irni, de ehhez nem is ertek:O)
Ha jol gondolom, nem is relevans.

t

Valóban, a hardlink ugyanaz az inode, de külön directory bejegyzés (az FS szemszögéből rosszul fogalmaztam).
http://en.wikipedia.org/wiki/Hard_link

A lényeg nem változik: ugyanarra az adatra mutat az FS-en belül.

Egyébként miért gondolnád hogy nem releváns?

Felteteleztem, h jot irsz, csak szarul fogalmaztad meg az elotte levot.

t

Nyilván ismered a hardlink-et, de jobb hogy kijavítottál, így nem fog fals itt állni.

A hardlink ugye arrol szol, hogy ket fajlod van, de azoknak ugyanott kezdodik a tartalmanak a terulete, azonban a ketto valojaban ket teljesen kulonallo fajl. A hardlinkeket onnet lehet felismerni, hogy a referenciaszamlalo (vagy mi a rak) novelesre kerul mellettuk, ezt az ls parancs szokta mutogatni. Mivel a tartalmuk ugyanazon a szektoron kezdodik, felulirhatjak egymas adatait - mas szoval, ha megvaltoztatod az egyiknek a tartalmat, a masike is megvaltozik.

Ami itt ugye fontos, az az, hogy sehol se legyen write szint engedve a fajlhoz az unprivileged csoportnak, se a hardlink eredeti fajljan (marmint, na azon a fajlon, ami elobb jott letre), se a linken (azon a fajlon, amelyik kesobbi).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

> A hardlink ugye arrol szol, hogy ket fajlod van, de azoknak ugyanott kezdodik a tartalmanak a terulete, azonban a ketto valojaban ket teljesen kulonallo fajl.

No ez így finoman szólva nagyon nem korrekt megfogalmazás (persze nem írtál oprendszert). Szóval *X oprendszerek esetén van egy fájl, ami egyrészt jelenti az adatokat "valahol a diszken" (engem ezek az adatok szoktak érdekelni); van neki egy i-node-ja, ami az engem amúgy nem érdeklő, de a rendszer számára fontos adminisztratív infókat tárolja; és kompromisszumképpen - azért hogy hivatkozni tudjak magára az adatra - van neki néhány neve, amelyek könyvtárbejegyzésként léteznek, és egy (ugyanarra) i-node-ra hivatkoznak.

Ha 0 db név van ami erre az i-node-ra hivatkozik, akkor valaki ezt a fájl(bejegyzés)t már törölte, de mint azt lejjebb valaki írta, néhány futó program még piszkálhatja a "fájlt". Ha 1 név van, akkor ezt törölve "elveszik" a fájl (fentiek alapján nem feltétlenül azonnal). És ha több név van, akkor azt mondjuk, hogy több hard linkje van A fájlnak.

Néha arra gondolok, hogy kár, hogy egyáltalán kitalálták a hard linket.

Nem vagy egyedül, pl. Robert N. M. Watson (FreeBSD MAC, TrustedBSD, Auditing, stb) jó pár éve pont ugyanezt írta - ha jól emlékszem - a freebsd-security listára. Hasonló megfontolásból, hogy ennyivel könnyebb az i-node alapján védeni valamit, mint a neve alapján. (Én amúgy "szeretem" a hard-linket, csak ésszel kell használni.

dillon is vert izzadt vele a hammer2 nehany alapotlete miatt :)

--
NetBSD - Simplicity is prerequisite for reliability

+1

Azért beszédes, hogy a fájltörlésre szolgáló rendszerhívás neve nem mondjuk "delete", hanem unlink. Nem a fájlok (inode) törlődnek ugyanis, hanem csak a rájuk mutató bejegyzés a könyvtárból, illetve ezzel párhuzamosan az inode-ban eggyel csökken rá mutató linkek számát jelző érték. A fájl (inode) csak akkor törlődik, a 0-ra csökkent ez az érték (azaz egy könyvtárban sincs már rá mutató bejegyzés), de 0 érték esetén is csak akkor, ha az utolsó alkalmazás is bezárta már. Sőt, a különböző pipe-okon keresztül már "törölt" fájlokra mutató deszkriptorokat is átadhatnak egymásnak a programok, az ilyen fájloknak pedig nincs is nevük. Asszem pl. erről is írt Joshua.
Ahhoz, hogy egy fájlt törölhessünk, nem is kell hozzá semmilyen jog. Csak a szülőkönyvtárhoz "w".
Egy fájl, és a róla készített hard link között tehát nincs semmi különbség. Azt sem lehet megállapítani, melyik az eredeti. Egy fájl, egy inode. Egyébként érdekes, hogy Linux alatt minden fájltípusról lehet hard linket készíteni, kivéve a könyvtárakat. Még soft linkről is :-)

A wiki ezt írja, hogy miért nem engedik a hardlink-et mappákra:

"To prevent endless recursion, most modern operating systems don't allow hard links on directories."

Viszont hiába van "w" jogod a szülő mappára, ha nincs meg a jogod a MAC-ben. MAC nélkül root joggal meg ugye úgyis mindegy.

Meg ott a referenciaszamolas is maskepp megy.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bocs, nem trollkodni akarok, de nem értem, mire gondolsz: Hol megy másképp a referenciaszámolás?

Szerk: Ezt azért kérdezem, mert nem tudok olyan MAC rendszerről, ami közreműködne a referenciaszámolásban.

Az ls parancsnal biztos, a melyebbekkel annyira nem vagyok kepben. Szoval, ugye ha egy fajl hardlink, akkor az ls az inode referenciaszamot (vagyis, hogy hanyszor hivatkoznak ra a konyvtarbol) kiolvassa es megjeleniti. Mappanal ez a refenciaszam azt (is) mutatja, hogy hany almappa van a mappaban, ami hivatkozik ra, mint parent. Nalam pl. a ~/.vim mappa refcount-ja 9, van benne 7 almappa + 2 (. illetve ..).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A stat is ugyanazt az eredményt adja. Egyébként érdekes, hogy csak az almappákat. A sima fájlokat vajon miért nem?

> ha egy fajl hardlink, akkor az ls az inode referenciaszamot (vagyis, hogy hanyszor hivatkoznak ra a konyvtarbol) kiolvassa es megjeleniti. Mappanal ez a refenciaszam azt (is) mutatja, hogy hany almappa van a mappaban, ami hivatkozik ra, mint parent

"hanyszor hivatkoznak ra a konyvtarbol" helyett "hányszor hivatkoznak rá (bárhonnan)" és máris érthető, hogy könyvtárnál is pont ugyanazt a "referenciaszámlálót" kapod. (A te megfogalmazásodból ki lehet hallani azt, egy fájlhoz hardlink csak ugyanabban a könyvtárban lehet, holott a korlát ugyanaz a fájlrendszer.)
Ugyanis a közvetlen alkönyvtárakban levő .. bejegyzés az, ami a szülő könyvtárra hivatkozik. Ezért van az, hogy (kb) definíció szerint: könyvtár hard-link száma: 2 + közvetlen alkönyvtárak száma.
2: /tmp/x -nek van egy neve (könyvtárbejegyzése) /tmp-ben - az x (tehát a "/tmp/x" bejegyzés)
és van egy /tmp/x -ben - a "/tmp/x/." nevű bejegyzés.
+alkönyvtárak száma: minden közvetlen alkönyvtárban ott a .., azaz "/tmp/x/y/.." (A nem közvetlen alkönyvtárakban levő alkönyvtárak ..-ja nem számít, hiszen /tmp/x/y/z/.. = /tmp/x/y .)

2: Szuper, értem. Akkor ez mégsem kivétel! Csak az zavart meg, hogy a find -samefile nem írta ki a sok .. bejegyzést.

Igazából az ln parancsnak van egy opciója, amit ha megadunk neki, akkor mégis kísérletet fog tenni könyvtárak hard linkelésére is, de a kernel nem engedi:

linkat(AT_FDCWD, "/home", AT_FDCWD, "/burzum", 0) = -1 EXDEV (Invalid cross-device link)

Köszi az észrevételt egyébként, de én kizárólag a DAC (illetve a fájlrendszer) szemszögéből írtam ezt. A Grsecuritynél és az AppArmornál egyébként az az érdekes, hogy a DAC-cal ellentétben nem a könyvtárhoz, hanem a létrehozandó fájlhoz van szükséged jogra ahhoz, hogy létrehozhasd.

"..a DAC-cal ellentétben nem a könyvtárhoz, hanem a létrehozandó fájlhoz van szükséged jogra ahhoz, hogy létrehozhasd."

Tomoyo-nál is.

Hát, akkor így megy ez. A SELinux azért több követelmény támaszt ennél :-)

De miért kellene több követelmény? Ha van a domain szabályai közt "allow_write /path/to/file", vagy "allow_create" vagy egyéb, akkor megteheti. Ha nincs, akkor nem.

Hol hibázik a dolog? :)

Egyébként persze a DAC jog is meg kell legyen Tomoyo esetében is, csak éppen nem elég (nyilván). Tehát DAC jog + Tomoyo jog = hozzáférés (nem főkébb neked írom ezt). Tehát a fenti kijelentésből egy "is" hiányzik.

Fenti példádban a hibaüzenet (nek látszó valami a zárójelben) nekem egész másra enged következtetni - én legalábbis megpróbálnám biztosan egy FS-en belüli dolgokra. (Legalábbis ugye a /home önálló FS szokott lenni, és a franc se tudja fejből, hogy - használatban levő - mount-point esetén pontosan mi a franc is történik.)

Na, várgyá, e:

linkat(AT_FDCWD, "/bin", AT_FDCWD, "/burzum", 0) = -1 EPERM (Operation not permitted)

Igazad volt, de nekem is.

EUID? Mint itt lentebb írtam, van ahol ez root-nak (látszó tárgynak) engedélyezett. (Ja, és én az ilyesmit biztosan inkább tmp-ben tennék. Meg különben is, mindenféle MAC-nélkülire konfigurált rendszeren.)

Linuxnál nem egész konkrétan az EUID, hanem az FSUID számít, amiről sokan azt gondolják, hogy nincs szükség rá, mert vannak olyan információk, miszerint az eredeti célja az volt, hogy megvédje a processzt attól, hogy bizonyos signal-okat küldjenek neki (ezt a feladatot pedig (már?) nem tölti be). A capability-k viszont új értelmet adnak neki.

Egyébként az EUID szerintem 0 volt, és kikapcsoltam minden a MAC rendszert.

> Ahhoz, hogy egy fájlt törölhessünk, nem is kell hozzá semmilyen jog. Csak a szülőkönyvtárhoz "w".

Valamint ugyanehhez a könyvtárhoz egy X jog is, különben nem férnél hozzá a fájl i-node-jához, ami kell a referenciaszámláló (rendes nevén hard-link szám) csökkentéséhez.

$ cd /tmp
$ mkdir xxxx
$ cd xxxx
$ echo lo > lo
$ pwd
/tmp/xxxx
$ cd ..
$ chmod 222 xxxx
$ rm xxxx/lo
rm: xxxx/lo: Permission denied
$ chmod a+x xxxx
$ rm xxxx/lo
$ 

Fenti nyilván nagyon hevenyészve, de remélem a lényeg látszik belőle.

> Egyébként érdekes, hogy Linux alatt minden fájltípusról lehet hard linket készíteni, kivéve a könyvtárakat.

Ehhez meg csak annyit, hogy van/volt olyan *X rendszer, ahol az ln(1) parancs szintén visszautasítja, de root usernek a link(2) rendszerhívás már megengedi a könyvtárhoz hardlink-készítést.

> Valamint ugyanehhez a könyvtárhoz egy X jog is, különben nem férnél hozzá a fájl i-node-jához

Köszi a kiegészítést. Az x jogot a könyvtárakon - ha jól emlékszem - search jognak hívják, és ezen felül nem is kell más, ha csak a könyvtárban levő fájlokat akarod elérni, de nem akarod a könyvtár tartalmát kilistázni (mert ahhoz már r jog is kell:

tamas@netadmin:~> mkdir burzum
tamas@netadmin:~> echo varg > burzum/vikernes
tamas@netadmin:~> chmod 100 burzum
tamas@netadmin:~> ls -ld burzum
d--x------ 2 tamas users 4096 nov 2 11.39 burzum
tamas@netadmin:~> cat burzum/vikernes
varg
tamas@netadmin:~> ls burzum
ls: nem lehet a következő könyvtárat megnyitni: burzum: Engedély megtagadva
tamas@netadmin:~>

> de nem akarod a könyvtár tartalmát kilistázni (mert ahhoz már r jog is kell:

(vizsgára készülve kötekedős hangulatban vagyok): a könyvtár tartalmának listázásához *csak* "r" kell (szigorúan /bin/ls, max "-i" opció hozzá); mondjuk ha ls -t / ls -l akkor ezekhez szükséges az i-node-ban levő infó is (-t esetén tudnom kell a dátumot, ami szerint rendezek, -l -nél meg még ki is akarom íratni) - ezért aztán kell az "r" mellé kell az "x" (amit valóban keresési jognak hívnak). Ha hozzá akarsz férni magához a fájlhoz aminek tudod a nevét (*), akkor már elég a könyvtár "x" joga - meg persze a fájl saját joga dönti el, hogy ténylegesen megteheted-e (azt a fájl írást/olvasást/futtatást). Ezek azok, amiket rendes esetben UNIX alapismeretek legkésőbb második (OK, harmadik) napján meg kell tanulni rendesen, de persze nem szokták, mert minek).

(*) HF: hogy lehet hozzáférni egy fájlhoz ha nem tudom a nevét és egy --x jogú könyvtárban van (tehát nem tudok "ls"-t mondani, hogy megnézzem.

Ja, én is valami ilyesmire gondoltam.

> meg kell tanulni rendesen, de persze nem szokták, mert minek

Én is csak nemrég fedeztem fel :-)

Ennek meg tudnád mondani a megoldását?
(Valószínűleg hülyeség, de nem valami file descriptoros okossággal kellene hozzáfogni?)

A szokás hatalma, nem hét!!!

Azt én is nagyon preferálnám, ha valaki ezt a dolgot tisztázná.
Abban is bizonytalan vagyok, hogy a kérdés tulajdonképpen ugyanazt jelenti-e mint az,
hogy hogyan tudok egy d--x------ jogosultságú könyvtárat listázni.
Én két dolgot tudok ami biztos működik. Egyik a root-ként listázás, illetve a bruteforce.
Gondolom, ha már itt ez a kérdés, akkor ennél valami szofisztikáltabb válasz is létezik, legalábbis remélem.
(Azt is, hogy valaki megmondja, vagy legalább azt mondja, hogy ez egy hülyeség :) )

Közönséges felhasználó vagyok, nem az enyém a könyvtár, nem tudom a fájl nevét, és a rendszerben nincs olyan processz, amelyik épp nyitva tartja vagy meg tudná nyitni? (Ha lenne, gondolom külön kiemelted volna.) Szabad a gazda.

Calamari fentebb megmondta: bruteforce. Csak sokan hajlamosak elfelejtkezni róla.

Paff! Ez aztán a trükk :-)))

Még infó a Tomoyo vs. "mount --bind" dologhoz:
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#v64787b4

"any protection for namespace manipulation?

a) TOMOYO Linux checks combination of mount_device, mount_point, filesystems for mount operation. Thus, one can't do "mount --bind /etc/ /tmp/" unless the administrator explicitly give "allow_mount /etc/ /tmp/ --bind 0" permission.

b) TOMOYO Linux checks combination of old_root and new_root for pivot_root() operation (although pivot_root() is seldom used after /sbin/init starts). Thus, one can't do "pivot_root / /tmp/" unless the administrator explicitly give "allow_pivot_root / /tmp/" permission.

c) Even if each process can have different namespace, it is restricted by mount()/pivot_root() checking. Thus, one can't freely create his/her own namespace.

d) TOMOYO Linux uses absolute pathname that is not affected by chroot(). Pathnames derived by traversing upward up to the root of process's namespace are used in TOMOYO Linux. It is not a process's root directory. Thus, permissions are given using pathnames starting from outside the chroot jail."

Miközben ennek az anyagnak a megírására készültem, egy érdekes dolgot találtam a symlinkekről: Hogyan lehet egy atomi lépésben átírni egy symlink célját?

A symlinkek inode-jában tárolt metainformációkat (legalábbis a jogosultságokra vonatkozókat) nem nagyon veszi figyelembe a kernel. A hozzáférési jogok értéke mindig 777 (rwxrwxrwx), nem is lehet megváltoztatni. Ha jól veszem ki, ez azért van, hogy symlinkek viselkedése minél jobban közelítse a sima könyvtárbejegyzésekét, azaz a hard linkekét (ld. a fentebbi kommentekben, milyen jogok szükségesek fájltörléshez, fájl-inode eléréshez). A symlinkek tulajdonos felhasználóját és csoportját meg lehet ugyan változtatni, de ezeket az értékeket csak akkor veszi figyelembe a kernel, amikor el akarja dönteni, hogy egy 1-es értékű sticky bittel rendelkező könyvtárból (pl. /tmp) kinek van joga kitörölni az adott symlinket.

A symlinkek még inkább read-only jelleget kapnak az által, hogy az értékük (vagyis a célpontjuk elérési útja) nem módosítható. Egy symlink célpontját csakis úgy tudjuk átírni, ha letöröljük a symlinket, majd létrehozunk egy ugyanolyan nevűt más célponttal. Ezt pedig egyetlen atomi lépésben kicsit trükkös véghezvinni:

http://unix.stackexchange.com/questions/5093/how-does-one-atomically-change-a-symlink-to-a-directory-in-busybox

A megoldás a rename rendszerhívás (esetleg az mv parancson keresztül).

Tudom, ez Linux, de

"A hozzáférési jogok értéke mindig 777 (rwxrwxrwx), nem is lehet megváltoztatni."

chmod -h 123 symlink

*BSD esetén :-) (Mondjuk az is igaz hogy itt nem *mindig* 777.)

És a sima symlink dereference-nél is figyelembe veszi ezeket a jogokat?

$ cd /tmp
$ ll lo la
ls: lo: No such file or directory
ls: la: No such file or directory
$ echo lo > lo
$ ln -s lo la
$ cat la
lo
$ chmod -h 0000 la
$ cat la
lo
$ ll lo la
l---------  1 zgabor  wheel  - 2 nov 10 21:20 la@ -> lo
-rw-r--r--  1 zgabor  wheel  - 3 nov 10 21:20 lo
$ 

Mint látható, nem :-(

Vajon miért nem? Milyen BSD volt ez?

FreeBSD, és nem tudom miért, de én is azt gyanítom, amit te írtál korábban:
"Ha jól veszem ki, ez azért van, hogy symlinkek viselkedése minél jobban közelítse a sima könyvtárbejegyzésekét"

csak egy gyors megjegyzes, ha mar belebotlottam a post-odba ;). a grsec nem path based, mint az apparmor, csak a konfiguralasa az, futasidoben ugyanugy vfsmount/inode alapu, mint a selinux meg a tobbiek (az apparmor meg strcmp alapu).

Köszi a hozzászólást. A múltkor, amikor az IRC-n volt szó arról, hogy az új 3.x kerneleknél a /proc fájlrendszerben változhat a fájlok inode-száma, és ez megzavarja az RBAC-ot, akkor felmerült bennem a gyanú, hogy nem teljesen path alapú a Grsecurity, de biztos vagyok benne, hogy a működése nagyon eltér a SELinux-étól.

A SELinux-nál maga az inode hordozza a hozzáférési infót xattr-ok formájában, úgyhogy nem hiszem, hogy ott szükség lenne a vfsmount-ra is (a vsfmount-ot az AppArmor és a Tomoyo használja, de nem inode-dal, hanem dentry-vel párban). Az xattr-ok shutdown után is megőrzik az infót, a Grsecurity-nél viszont nem találtam xattr-okat a `getfattr --dump --match= FÁJLNÉV` paranccsal, úgyhogy biztos futásidőben állítja össze az inode-okat tartalmazó adatstruktúrát. Az igaz, hogy az első aktiváláskor a SELinux is fájlnevek alapján osztályozza és címkézi fel a fájlrendszert, az viszont percekig tart, a Grsecurity RBAC viszont egy másodpercen belül beröffen, tehát nem hiszem, hogy a memóriában tárolt inode-táblája ugyanúgy lefedné a teljes fájlrendszert, mint ahogy a SELinux teszi azt az xattr-okkal. Én úgy sejtem, hogy inkább on-the-fly rendel metainfókat az inode-okhoz az első hozzáféréskor. A doksiban sajnos nem találtam semmi erre vonatkozó adatot. Nem tudnád röviden összefoglalni, hogy működik pontosan?

Egyébként még tovább növekszik a SELinuxhoz viszonyított különbség az által, hogy a Grsecurity-ben ugyanarra a fájlra különböző jogok vonatkozhatnak, ha más path-on (hard link) keresztül hivatkozunk rá.

irc-n mar kb kibeszeltuk, szoval csak roviden:

1. a /proc problema nem a path kezeles miatt volt, hanem mert nehany verzioval ezelott valaki kitalalta, hogy milyen jo dolog lenne, ha /proc alatti file-okhoz dinamikusan allokalt inode-ok tartoznanak, ertve ez alatt azt, hogy egy procfs mount elettartama alatt *nem* stabilak az inode-ok, igy aztan hozzajuk rendelni metainformaciot is eleg nehezkes (nem csak a grsec kuzd meg a procfs-sel, l. SE_SBPROC meg strcmp(sb->s_type->name, "proc")).

2. az inode per-fs egyedi azonosito ill. struktura (es nem globalis), kernelben (futasidoben, memoriaban) mindig egy vfsmount ala tartozik. amiben a grsec elter a tobbi cimkezo rendszertol az az, hogy a cimkek nem kozvetlenul tarolodnak a filerendszerben a file-ok melle, hanem policy betolteskor konstrualja meg oket (igazabol a policy nem csak a letezo file-okhoz tarol metainformaciot, hanem a nem letezokhoz is). tekinthetjuk ugy is, hogy a grsec policy egy nagyon human readable tomoritett formaja annak, amit a tobbiek (sokak szerint nem kis komplexitas aran ;) a filerendszerben kenytelenek tarolni.

3. "Egyébként még tovább növekszik a SELinuxhoz viszonyított különbség az által, hogy a Grsecurity-ben ugyanarra a fájlra különböző jogok vonatkozhatnak, ha más path-on (hard link) keresztül hivatkozunk rá." - ha tudsz ra peldat konstrualni, akkor mehet a bugreport spendernek meg kerhetsz ra CVE-t, en meg vegre root leszek a grsecurity.net-en ;). amire esetleg gondolhattal az az, hogy egy file-ra (eleresi utvonalatol fuggetlenul) kulonbozo jogok vonatkozhatnak kulonbozo subject-ek szamara, de ez mas rendszerekben is igy van.

Bocs, hogy eddig nem tudtam válaszolni, nemrég műtöttek, nagy a család, meg minden ilyesmi. Szóval:

1. Ja, igen, slashbeast közben már felvilágosított, hogy ez a dolog a vanilla kernel szempontjából nem bug, hanem feature, de megnehezíti a grsecurity életét. Nem tudod, hogy van-e végeleges megoldás (nem workaround) rá?

2. Na, közben rájöttem, és megbeszéltem spenderrel, hogy a jogosultságok tényleg inode-onként vannak tárolva, az öröklésük viszont a vfsmount/dentry fán történik. Ez leginkább a Windows/NTFS biztonsági modelljére emlékeztet engem, bár spender egy kicsit ahhoz képest kicsit path-based irányba tolta el, mert ha pl. letörlünk egy fájlt, majd egy másikat a helyére mozgatunk, akkor az átmozgatott fájl nem hozza magával a jogosultságait, hanem megkapja a letörölt fájlét simán a név miatt. Még akkor is, ha mindkét fájl közvetlenül fel volt címkézve a policy-ben. Hát, nekem nem annyira szimpatikus ez a megoldás. Ráadásul már megint találtam egy - szerintem óriási biztonsági - hibát, miközben ezeket a dolgokat vizsgálgattam. Spender már javítja, azt mondta, holnap kész lesz. Most találtam egy másik bugot is, ezt levélben küldtem el neki, de attól tartok, azt fogja mondani rá, hogy ez feature, ha pedig így van, akkor szerintem ez egy nem igazán jó feature.

3. Ezt nem mint bugot említettem meg. Könnyű ilyet konstruálni, de ez szerintem is egy feature. Pl.:

/test1 r
/test2 rw

echo lajos > /test1/majom
ln /test1/majom /test2/majom

És a /test1/majom csak olvasható lesz, a /test2/majom pedig írható is, pedig ugyanaz a fájl.

Nem vagyok otthon GRSEC-ben (sem), de ha /test1 *csak* r jogú, atól még lehet benne fájlt létrehozni? Nem kell hozzá az a /test2-ben is meglevő w?

Ertelemszeruen a /test1 alatt valaki mas hozza letre az ominozus fajlt, akinek van ra w joga.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Fájl (és symlink) létrehozásához legalább "cw" jog kell, hardlink létrehozásához "cl". A létrehozandó fájlhoz kell a jog, az azt tartalmazó könyvtárhoz nem. Egyébként a fenti példa csak akkor érvénye, ha a linket a grsecurity beindítása előtt hozzák létre, mert az nem engedi meg, hogy olyan helyre linkelj egy fájlt, ahol több jogod van, mint az eredeti helyen. Így aztán nem nagyon tudok elképzelni olyan szituációt, ahol támadásra használható a grsecuritynek ez a tulajdonsága. Csak úgy megemlítettem. Nem bug, feature ;-)

De ez logikailag is helyes szerintem, mert a hardlink-et úgy kell elképzelni, mintha csak a fájlban lévő adat lenne közös, azon kívül semmi sem. (fixme)

Tehát nyilván a /test2 jogai fognak vonatkozni rá.

Hardlinknél az inode (az adatsruktúra, nem csak a szám!) közös. Tehát egy és ugyanaz a fájl, csak több helyen tűnik fel a könyvtárszerkezetben. A UNIX DAC-ban, ahol minden fájlnak saját jogosultsági adatai vannak (épp az inode-ban tárolva!), és nincs öröklődés, ott a két hardlinknek semmilyen tulajdonsága nem lehet különböző, csak a helye a fájlrendszerben és a neve. Az user, group, ctime, mtime, atime, jogosultság, xattr, fájltartalom, stb. mind megegyeznek. Hiszen egy fájlról van szó, nem többről.

De akkor is a szülő mappa jogai a meghatározók. Vagy nem értem a fenti felvetésed lényegét.

A grsecurity esetében az legspecifikusabb szülőtől örökölt engedély a mérvadó, UNIX DAC esetében létrehozáshoz és törléshez a szülőkönyvtárhoz való wx jog kell, az összes többi művelethez a fájl saját inode-jában tárolt engedélyek számítanak.

Úgy értem, hiába van rx joga test1-nek, attól még az alapértelmezett 0644-es joggal létrejött fájlt tudod írni. Nem kell a mappához w jog. Ugye x mindegyik esetben kell.

Érdekes lenne ennek a cikknek megcsinálni egy mai állapotra aktualizált verzióját. :) [sub]

Egyetértek - feltéve, hogy történt sok változás az elmúlt két évben.
A legtöbb e témával foglalkozó írás amit találtam, minimum 5-6 éves vagy még régebbi.

És kiegészíteni a Tomoyo-val (meg ha van más, azzal is).
VALAKI! Hívnak!

+1, és ha már kívánságműsor, akkor én szívesen látnék a grsecről egy részletesebb, "használat közbeni" útmutatót is
(meg a TrustedBSD-ről is örömmel olvasnék, de ez egy kicsit off itt)

> és ha már kívánságműsor, akkor én szívesen látnék a grsecről egy részletesebb, "használat közbeni" útmutatót is

+1

Bár csak most vettem észre, de nagyon érdekes cikk volt, köszönöm, hogy összeraktad így.

Az egészről nekem két dolog jutott eszembe:
- a Grsecurity/PaX páros az, amitől nem jön rám a hányinger :))
- évekkel ezelőtt vmi openbsd-s levlistán olvastam, hogy ők pontosan az ilyen túlbonyolított dolgokat akarják elkerülni és csak olyan security feature-öket fejleszteni, használni, ami nem avatkozik bele erőszakkal ennyire a userland "életébe" (persze ez nem is jelent olyan fajta védelmet mint egy MAC-keretrendszer).

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Egyben potencialis lyukat sem.

tompos