Az RBAC (Role-Based Access Control; ~”szerepkör-alapú jogosultság-ellenőrzés”) a nagyvállalati informatikai környezetekben gyakorta jelenlévő filozófia, úgy is, mint többek közt az adminisztratív tevékenységek – rendszerbiztonsági követelményeknek megfelelő – kijelölt, ellenőrzött személyek közötti elosztásának bevált gyakorlata. Megfeleltethető mindez a rendszerfelügyeleti terhek könnyítését célzó törekvéseknek éppúgy, mint az ún. „szükséges és elégséges jogosultság” („least-privilege„) biztonsági alapelvének a munka elvégzéséhez feltétlenül szükséges, de annál nem magasabb biztonsági jogosultsági szint időszakos, a munkavégzés időtartamára szóló, naplózott kiosztásával. Jelen vizsgálódásom tárgyát ezúttal a terület csupán ezen korlátozott aspektusa képezi.
A módszer bevezetése megkímél minket a legfelsőbb szintű rendszerfelügyeleti felhasználói fiók („root„) jelszava kiadásának szükségétől, ugyanakkor alapesetben – a jelszóval nem ellátott szerepkörök kivételével – a felhasználó saját jelszavának ismeretében sem veszélyezteti az emelt biztonsági szintű szerepkört, annak jogosultjait. A ténylegesen elérni kívánt cél bizonyos rendszer-erőforrások elérhetővé tétele egyes kiemelt felhasználók számára ellenőrzött körülmények közt, az ún. „super-user” (root) jogkör egyértelmű, folyamatos megtagadása mellett. Szerepkörökkel való felruházásuk lehetővé teszi ezen felhasználók számára a hozzájuk rendelt biztonsági jogkörök teljes kihasználását meghatalmazások és végrehajtási profilok használata által akár parancs-szinten is. A szerepkör-használat minden esetben naplózásra kerül. Míg ugyanez többé-kevésbé a sudo használatával is kivitelezhető, fontosnak tartom megjegyezni minden környezetben a gyártó saját megoldásai használata jelentőségének fontosságát, azok célszerű, külső gyártók termékeivel szembeni előnyben részesítése jelentőségét – a sudo nem része a Solaris 10-es kiadásának, használatát a gyártó nem bátorítja, nem támogatja.
A natív, támogatott megoldás a rendszerbe mélyen integrált RBAC metódus használata, még ha megértése, bevezetése komolyabb kihívást jelent, erőforrás-igényesebb is. A Solaris Auditing – korábban BSM (Basic Security Module; ~”alapvető biztonsági modul”) – nevet viselő, logikailag kapcsolódó, szintén gyárilag integrált és rendelkezésre álló kiegészítő termék párhuzamos bevezetésével tovább fokozhatjuk az ellenőrzést rendszerünk felett a rendszerfelügyeleti tevékenység részletes nyomon követése által.
Dióhéjban: a jogosultság-ellenőrzést ún. meghatalmazásokon keresztül valósítjuk meg, melyekből a rendszer minden felhasználója rendelkezik bizonyos típusúakkal. A rendszer mechanizmusaiba ágyazva ezekből bizonyos készletek vannak jelen. Ezen meghatalmazások felhasználókhoz rendelésével – pontosabban a felhasználók végrehajtási profilokhoz kötött, (meghatalmazáshoz vagy adott parancshoz kötve) meghatalmazott szerepkörökhöz rendelésével – lehetővé tehetjük felhasználóink számára kiszabott feladataik ellenőrzött körülmények közötti biztonságos és maradéktalan végrehajtását – azonban nem többet! Minden felhasználó csak a ráruházott szerepkörrel élhet, és annak kiosztása nélkül egyetlen felhasználó sem alkalmazhat egy szerepkört. Bár a mindezt megvalósító rendszer mélyén a szerepkörök ún. profilokhoz vannak kötve, technikailag egy felhasználó kötődhet akár szerepkörhöz, akár közvetlenül profilhoz anélkül, hogy bármelyik hozzárendelés a másikból következne. Szerepkör a su paranccsal vehető használatba; egy profil az ellenében történő, ún. „profile shell„-ben futtatott parancs-végrehajtás során érvényesít meghatalmazásokat. Ez utóbbi esetben azonban a rendszer nem naplózza a végrehajtást, sem jelszó-hitelesítést nem kér előzetesen. Ezen profilok a szaknyelvben „jogosultsági-” vagy „végrehajtási/futtatási” profil néven egyaránt ismeretesek („rights-/execution profile„). Létezik továbbá az RBAC hierarchiájában még a „jogosultság” (privilege) és azok csoportjainak (~ set) fogalma; ezek előre meghatározott formában vannak jelen a rendszerben, és hellyel-közzel a meghatalmazások folyamatokra értelmezett megfelelőinek tekinthetők. (Ezeket a Solaris 10 kiadás a korábbi Trusted Solaris verziókból örökölte, s ahogy az RBAC képesség vagy az auditálási funkció, a mindezt aktívan kihasználó Solaris Trusted Extensions lehetőségeinek részét képezik.)
Lekérdezhetőek bizonyos parancsok használatával, és például profilok ellenében történő végrehajtás során meg is hivatkozhatóak, a profil által biztosított jogosultságok ténylegesen felhasznált körét szűkítendő – a szükségesség elvének tiszteletben tartásával.
Fiókot a rendszer kétfélét tart nyilván: felhasználói, (user) avagy normál típusút; valamint szerepkör (role) típust – utóbbiak bejelentkezésre alkalmatlan, az RBAC részeként élő bejegyzések. Ezekhez közvetlenül is rendelhetőek meghatalmazások vagy jogosultságok; ezen utóbbiak a fiókhoz kötődő, abból származtatott rendszerfolyamatokra értelmeződnek.
Az RBAC konfigurációs adatbázisa az egyszerű (flat) adatmodellt követi és a következő 5 darab szöveges konfigurációs file-ból áll:
• /etc/user_attr (kiterjesztett felhasználói tulajdonságok)
• /etc/security/prof_attr (profil-definíciók)
• /etc/security/exec_attr (profil-hozzárendelések)
• /etc/security/auth_attr (meghatalmazás-definíciók)
• /etc/security/policy_conf (biztonsági házirend)
A soron következő leírás az RBAC fentebb taglalt képességeinek egy egyszerű példájaként áll itt a teljesség mindennemű igénye nélkül, olvasmányos, szemléltető betekintést nyújtó célzattal! Elkészítése során sokkal inkább a könnyű érthetőség, semmint a szakmai tökéletesség lebegett a szerző szeme előtt. No de térjünk is a tárgyra!
A demonstrációm céljait szolgáló felhasználói fiók létrehozásával kezdem:
Lássuk, mi is van itt:
Figyeljük meg az alapértelmezésben társított profilokat és a szerepkörök hiányát!
Először is bemutatom, hogyan működik a profil-hozzárendelés:
(Megjegyezném, hogy a sikeres utasítás-végrehajtás UNIX-okra jellemző csendes természete okán kiadtam a profiles parancsot is a hozzárendelés sikerét ellenőrzendő)
Szemlátomást a felhasználó valóban kötődik a „Primary Administrator” profilhoz.
Nézzük, miként viselkedik egy kiemelt parancs:
Lássuk, van-e bármi feljegyzésünk a történtekről?
Láthatóan semmi sem került rögzítésre a /var/adm/messages állományba és bizony a /var/adm/sulog sem tartalmaz mást, csak a demo-felhasználónk előbbi használatba vételét… Fordított irányban, a root fiókkal kapcsolatban semmit.
Egyelőre nem látjuk több hasznát ennek a profilnak, vonjuk hát vissza:
(Megjegyzem, hogy ismételten a profiles utasítást hívtam segítségül ellenőrzésképpen.)
Utolsó kiemelt parancsunk kiadását követően vajon valóban halandóvá váltunk-e ismét?
Határozottan és bizonyosan. (Észrevételezzük a megvonás azonnali hatályba lépését!)
A beépített „Primary Administrator” profil – a pfexec segítségével – megteheti majdhogynem mindazt, amire a root felhasználó képes. Egyelőre azonban mindez megfelelne egy natív, jelszó nélkül konfigurált sudo jogosultságnak, ám naplózás nélkül – mely természetesen működne bár, de nem segítene sokat, s kiváltani sem tudná amazt.
(A Solaris 10-et alapértelmezetten 46 efféle profillal szállítják, melyek közül a Primary Administrator nevet viselő felel meg kiosztva a legkevésbé a tényleges használatra, bár bemutatónk céljára megfelelt – tiszteljük a szükséges legalacsonyabb jogosultság elvét…!)
Mindenesetre még csak a felszínt karcolgatjuk… Folytassuk a felfedezést!
Készítsünk egy új, saját profilt:
Ezzel létrehoztunk egy „Formatting” nevű profilt, amelyhez a /usr/sbin/format parancsot és a 0-ás, végrehajtáskor hatályos UID-t rendeltük.
Következő lépésként létrehozunk és kiosztunk egy szerepkört:
Vessünk egy pillantást a fentiek hatására bekövetkezett konfigurációs változásokra:
Szemlátomást a szerepkör bejegyzése is bekerült az /etc/passwd állományba – figyeljük meg azonban az alapértelmezett parancsértelmezőjét: nem más, mint egy profile shell!
(Értelemszerűleg az /etc/shadow állományban is képviseltetve lesz)
Figyeljük meg a szerepkör bejegyzését az /etc/exec_attr állományon belül: láthatóan a „formatter” egy szerepkör-típusú fiók, s mint ilyen, bejelentkezni a rendszerbe nem tud. Hozzá van azonban rendelve az rbac_demo felhasználói fiókhoz, és maga pedig szemlátomást kötődik a „Formatting” nevű profilhoz.
Lássuk, mit is csináltunk idáig:
Láthatóan a demo-felhasználónk nem bír hozzárendelt profillal, magáénak vallja azonban a „formatter” szerepkört. Próbáljuk ki!
Mivel nem láttuk el jelszóval az új fiókot, fel kell oldanunk a zárolását:
Feloldva és jelszó nélkül jó is lesz ránézésre; lássuk, mit tud:
Úgy tűnik, egyszerű felhasználóként esélytelen futtatnia a format eszközt; a „formatter” szerepkörben próbálva azonban egészen más a helyzet – továbbá ezúttal naplóbejegyzés is keletkezett a szerepkör felvételéről.
Erősítsük meg teszt-fiókjainkat jelszavakkal:
És most, a változatosság kedvéért:
A szerepkör profile shell-jébe be is lehet lépni a fent látható módon „felvéve” azt. (Figyeljük meg az időközben beállított jelszó bekérését!)
Hagytunk ezúttal vajon nyomot magunk után? Igen:
(Megjegyzem, a sulog olvashatósága érdekében előzetesen – a su használata helyett – tényleges bejelentkezést hajtottam végre a teszt-felhasználóval ezen próbát megelőzően)
Mennyire biztonságos mindez? Lássuk:
Látható, hogy felruházás hiányában a jelszó esetleges ismeretében sem vehető használatba a szerepkör. Tekintve, hogy van alapértelmezetten hozzárendelt profil, a pfexec sem jelez hibát – ámbátor annak jogosultságai elégtelenek a parancs futtatásához szükséges erőforrások eléréséhez.
Adott azonban a másik lehetőség:
Látványosan bizonyítottuk az eddig elhangzottakat. Ami pedig a történtek hátterét illeti:
Szemlátomást normál fióktípusokhoz is társítható végrehajtási profil. A pfexec minden, a társított profilokhoz kötött meghatalmazást érvényesít, sorban ellenőrizve azokat, az első megfelelő szintűt felhasználva – ha meg nem adunk -P kapcsolóval jogosultság-csoportot argumentumként. A megfelelő végrehajtási profil hozzárendelésével a szerepkörrel való felruházás nélkül is képessé tettük a felhasználót az adott bináris 0-ás UID-del történő futtatására – mindezt jelszó bekérését és naplóbejegyzés rögzítését mellőzve! Legalábbis a BSM auditálási funkciójának használata nélkül…
