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…