Krasznay Endre, a Hacktivity informatikai biztonsági konferencia szervezője megkérdezte a Red Hat-et Magyarországon képviselő ULX egyik szakértőjét, Béres Lászlót, hogy hogyan lehet egy Linux-alapú informatikai megoldásnál a szükséges biztonsági szinteket megvalósítani. Az interjút itt most közzé is tesszük:
Hacktivity: A Red Hat Enterprise Linux volt az első kereskedelmi disztribúció, amelyik teljes támogatást tartalmazott az SELinuxhoz. Milyen fontosabb állomásai voltak az integrációnak?
A Red Hat mindig szorosan együtműködött az SELinux, illetve annak szabályrendszerei (policy) fejlesztését koordináló Tresys-szel. Ennek köszönhetően az SELinux kiegészítés már a Red Hat korai termékeiben nagyon jól felépített, kritikus környezetekben is jól használható biztonsági komponenssé vált. Elsőként a Red Hat által támogatott, közösségi disztribúcióban, a Fedoraban jelent meg, majd alapos tesztelés és továbbfejlesztés után a Red Hat Enterprise Linux 4 lett az első vállalati disztribúció, amelyben az SELinux teljesen támogatott elemként szerepelt.
Természetesen mind a Red Hat, mind a nyílt forrású fejlesztő közösség szeretett volna még többet kihozni az SELinux lehetőségeiből, ezért a munka nem állt meg. A későbbi Fedora Core rendszerekben és a Red Hat Enterprise Linux 5-ben is rengeteg új szabály és menedzsment eszköz vált elérhetővé, utóbbiban forradalmi újdonság lett a strict policy, amely teljes védelmet jelent a rendszerüzemeltetők számára. Nem véletlen tehát, hogy az SELinux egy ideje már nem kiegészítése, hanem szerves része a mainstream kernelnek. A virtualizációs technológiák iránti robbanásszerű igény a Red Hat-hez is elért. A RHEL 5 teljes Xen virtualizációt kínál a felhasználóknak, az SELinux pedig ebben is segítséget nyújt: az egyes virtuális környezeteket teljesen elkülöníthetjük egymástól, így egy jól felépített rendszerben az adatszivárgás vagy illetéktelen hozzáférés elképzelhetetlen.
Hacktivity: Melyek a legfontosabb elemei a SELinuxnak?
Az SELinux egy több faktorból álló, komplex rendszer, amely többféle biztonsági mechanizmust (type enforcement, role based access control, multi level security) használ működése során. Az SELinux magja egy kernelkomponens, amely a hozzá tartozó szabályrendszer alapján döntéseket hoz az egyes rendszerfolyamatok és erőforrások között. A klasszikus Unix rendszerek hozzáférés-szabályozása sajnos nem teszi lehetővé, hogy ezeket olyan finoman szabályozzuk, ahogy azt egyes speciális rendszerüzemeltetési körülmények igényelnék, egy ilyen policy-ben azonban akár minden egyes folyamat minden lépéséhez készíthetünk szabályokat. A szabályok létrehozását, menedzselését, valamint a működés során keletkező üzenetek feldolgozását különféle alkalmazásokkal igen egyszerűen elvégezhetjük, ezekből számos áll rendelkezésre a Red Hat Enterprise Linux különféle változataiban.
Hacktivity: Kritikák is érték a SELinuxot: például hogy nehezen menedzselhető. Hogyan lehet ezen a téren továbblépni? Milyen újdonságokra lehet még számítani?
Tény, hogy maguk a policy állományok első pillantásra ijesztően bonyolultak, dehát ez végül is nem rossz, legalább elvesszük a kedvét a támadónak 🙂 A viccet félretéve: az SELinux menedzseléséhez rengeteg alkalmazást találhatunk, amelyek nem csak a szabályok szerkesztését, hanem a naplóállományokban keletkezett bejegyzések interpretálását is segítik. Sőt, egyik komoly újdonság az audit2allow nevű script, amelyik képes a logok alapján policy-k generálására, megkönnyítve ezzel a rendszeradminisztrátor és a security manager dolgát. Az SELinux legújabb változataiban már moduláris policy-t találunk, ez lehetővé teszi, hogy a szabályokat akár menet közben, dinamikusan cserélhessük, módosítsuk. Ez korábban nem volt lehetséges, emiatt valóban nehézkesnek tűnt a szabályok implementálása.
Hacktivity: A Fedora Core 2 megjelenésekor nagy felháborodási hullám indult amiatt, hogy az FC2 csak egyféle policyt tartalmazott. Ebben a szabályrendszerben minden tiltva volt, amire nem készült külön szabály, így azon felhasználók, akik mindenféle, nem certifikált alkalmazásokat szerettek volna futtatni, megdöbbenve tapasztalták, hogy bekapcsolt SELinux módban ez lehetetlen. Ezen aztán gyorsan változtattak is…
Valóban, a felhasználók megdöbbentek, amikor kedvenc alkalmazásaik egyszerűen nem működtek bekapcsolt SELinux mellett. Ekkor még egy korai strict (teljes zárlat) policy létezett, emiatt sokan bírálták a fejlesztőket. Nyilván ez az állapot nem volt sokáig tartható, ezért a Red Hat és Fedora fejlesztők megvalósították a „jöttem is, meg nem is, hoztam is ajándékot, meg nem is” elvet. Készült egy olyan policy („targeted” névvel), amely csak bizonyos rendszerszolgáltatások működését biztosítja (tipikusan olyan hálózati szolgáltatások, amelyek jelentős támadásnak vannak kitéve, pl. Apache, Bind), a szabályok azonban lehetővé teszik, hogy a védelemmel nem rendelkező alkalmazások mindenhez szabadon hozzáférjenek. Érdemes azonban végiggondolni, hogy ezekért a helyzetekért csak az SELinux a felelős? Nem lehetséges, hogy az egyes programok olyan erőforrásokhoz próbálnak meg hozzáférni, amelyekre valójában semmi szükségük sem lenne?
Az SELinux kapcsán mindig felmerül a security manager fogalma. Komoly biztonságú rendszerekben a biztonsági házirend létrehozása, megvalósítása és betartatása a rendszergazdától független dolog. Ezt a szerepet a security manager látja el. Ő az, aki képes a policy megtekintésére, módosítására, egyedi jogosultságok létrehozására akár anélkül is, hogy tényleges rendszeradminisztrátori eszközökkel rendelkezne. Ez talán sokak szemében furcsának tűnhet, de szakítanunk kell azzal a ténnyel, hogy a rootnak mindent szabad.
Hacktivity: Az RHEL 5-ben már egy valamirevaló biztonsági minősítés, a CC (Common Criteria) EAL4+ elérése volt a cél. Az IBM termékeivel párban már túl is vannak ezen az akadályon. Ez a munka megmarad a két vállalat együttműködési keretein belül, vagy kinyílik a paletta más hardvergyártók felé is? Hogyan tovább?Hacktivity: Az RHEL 5-ben már egy valamirevaló biztonsági minősítés, a CC (Common Criteria) EAL4+ elérése volt a cél. Az IBM termékeivel párban már túl is vannak ezen az akadályon. Ez a munka megmarad a két vállalat együttműködési keretein belül, vagy kinyílik a paletta más hardvergyártók felé is? Hogyan tovább?
A Red Hat és az IBM régi szövetségesek, ezért is volt gördülékeny az a munka, amelynek nemrégiben beérett a gyümölcse. Az EAL4+ minősítés megszerzése valóban nagy elégedettséggel töltött el bennünket, de ahogy a mondás is tartja, a biztonság nem állapot, hanem egy folyamat. Hiába ajánlunk az ügyfelek számára komplett szoftver- és hardvermegoldásokat, a rajtuk futó alkalmazások jelentik továbbra is a leggyengébb pontot a rendszerben.
A Red Hat ezért a support mellett az oktatást is fontosnak tartja. Már Magyarországon is elérhetőek azok a tanfolyamok, ahol a Red Hat Enterprise Linux rendszerek üzemeltetése mellett azok biztonságossá tételével is foglalkozunk, sőt, speciális SELinux workshop keretén belül valódi rendszereken tanulhátják meg az érdeklődők a szabályok írását, módosítását, implementálását – tehát a rendszerük teljes védelméhez vezető lépéseket.