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 :)