SELinux

A 90-es években az Amerikai Nemzetbiztonsági Hivatal (NSA) indított egy projektet, melynek célja egy igazán biztonságos platform kialakítása volt. A fejlesztők – a nyílt fejlesztési modellje miatt – a Linux kernelét választották kísérleti alanynak, innen pedig már egyenes út vezetett ahhoz, hogy mindenki számára elérhetővé váljon az eredmény: a Security Enhanced Linux, röviden SELinux. A Hacktivity informatikai biztonsági konferencián Béres László, a Red Hatet Magyarországon képviselő ULX Kft. vezető szakértője fogja bemutatni, hogyan lehet egy Linux-alapú informatikai megoldásnál a szükséges biztonsági szinteket megvalósítani. Vele beszélgettünk a rendszerről.

A Red Hat Enterprise Linux volt az első kereskedelmi disztribúció, amelyik teljesen támogatta az SELinuxot. Milyen fontosabb állomásai voltak az integrációnak?

A Red Hat mindig szorosan együttműködött az SELinux, illetve annak szabályrendszerei (policy) fejlesztését koordináló Tresysszel. 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 Fedorában 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 menedzsmenteszkö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 Hathez 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.

Melyek a legfontosabb elemei az 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 policyben 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.

Kritikák is érték az 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, de há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 nemcsak 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 policyk 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 policyt 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.

A Fedora Core 2 megjelenésekor nagy felháborodást keltett, hogy a kiadás 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, például 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: 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.

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 tanulhatjá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.

***

Következzen a rendezvény kapcsán tartott nyereményjátékunk második feladványa:

A Red Hat Enterprise Linux 4 gyári SELinux targeted policyje 15 rendszerszolgáltatást védett. A Red Hat Enterprise Linux 5-ben található szabályrendszer alapértelmezetten hány rendszerfolyamatot véd?

a) 15
b) 50
c) 200
d) 2000