Security speci

IBM nagygépek és a RACF, 2003. május 6.

Tartalomjegyzék


A DoD kategóriái

Mi is az a DoD: az Egyesült Államok Védelmi Minisztériuma (Department of Defense).

A DoD különböző kategóriákba sorolta a számítógépes rendszereit security szempontjából, és ezt használják a beszállítói is.

Ezek a kategóriák, a megbízhatóság növekedő sorrendjében: D, C1, C2, B1, B2, B3, A1, A1+

D

A semminél több, de a C1-nél kevesebb (pl.: PC-DOS, BIOS jelszóval :-))

C

Ez már érdekesebb. Ennek ellenére legfontosabb jellemzője (az én szememben) mindkét C kategóriának, hogy arról szól, mennyire megbízhatóra tervezték a rendszert. Az, hogy itt-ott van benne egy kis buffer-overflow, az már implementációs részletkérdés.

C1

Milyenre kell tervezni egy ilyen rendszert:

C2

Ez egy fokkal erősebb követelményeket támaszt. Ezek is viszonylag széles körűen kielégíthetőek (VMS, egyes UNIX-ok által), de csökkenti a hatékonyságot ezekben a rendszerekben, ezért gyakran nem használják ki. A nagygépeken ez a minimális szint (egyetemi környezetben ennél magasabb szint felesleges).

B

Véleményem szerint a legnagyobb különbség a komoly tesztelés. Míg a C kategóriákban elég volt a saját teszt, addig itt már független szakértők tesztelik a rendszert (természetesen olyanok, akik átlátják mind a koncepciókat, mind a megoldást, és rendelkezésükre áll a teljes source code is). Ha megbukik a teszten, azonnal visszavonják a B minősítést, és (javítás után) kezdhetik előlről a tesztelést.

Rendkívül kevés rendszer képes ezeket az igényeket kielégíteni, de a konstruktív munkát mindenképpen gátolja. Egy átlag cégnél (pl. bank) ez elfogadható, egyes helyeken (pl. egyetemen, kutatóintézetben) nem.

Egy ilyen rendszert rendkívül jól meg kell tervezni ahhoz, hogy a mindennapos munkát ne gátolja. Jó tempóban dolgoznak annál a cégnél, ahol egyetlen év alatt be lehet vezetni. Jellemzően a cég teljes átvilágításával kezdik (ezt külső szakértők készítik el), melynek folyamán megállapítják a pontos hierarchiát. Ezt a security adminisztrátor formális nyelven leírja.

B1

B2

B3

A

Az A minősítés fókuszában a bizonyított helyeség áll.

A1

Funkcionálisan megegyezik a B3-mal, azonban formálisan bizonyított a tervezés helyesége.

A1+

"Beyond A1": a teljes rendszer bizonyítottan jó: a source szintig formálisan bizonyított a helyessége, és a compilerek, linkerek helyessége is bizonyított.

A közeljövőben nem várható ilyen rendszer.

Biztonsági cimkék

Nézzük meg kicsit részletesebben a B biztonsági szintnél emlitett cimkéket.

Egy cimkének akkor felel meg valaki, ha mindkét összetevôjének megfelel. Ez is csak szükséges, de nem elégsés feltétel, mivel a C szintnél megismert ellenörzés csak ez után következik. Tehát a cimkék egy olyan plusz biztonságot jelentenek, amit nagyon egyszerû átlátni, és megkerülhetetlen.

Security level

A security label hierarchikus részét lehet szintnek is nevezni. Mivel hierarchikus, ezért egy adott szintre vonatkozó jog automatikusan magában foglalja a hierarchiában alatta található szintekre vonatkozó jogokat is.

Egy konkrét példa (az 1998. évi LXXX. törvény az államtitokról és a szolgálati titokról szóló 1995. évi LXV. törvény módosításáról5/B. § (2)):

Ekkor pl. egy NATO CONFIDENTAL minôsítésû infohoz hozzáférhet az is, aki NATO SECRET minôsítéssel rendelkezik.

Security category

A security label nem hierarchikus részét lehet kategóriának is nevezni. Mivel nincsen kapcsolat a kategóriák között, azért csak akkor férhetünk hozzá egy infohoz, ha minden szükséges category-val rendelkezünk.

Egy példa:

Ilyen esetben csak az jogosult infohoz egy atom robbanófejû robotrepülôgéppel kapcsolatban, aki mindkét categoryra minôsített.

A minimális security nagygépeken (VM önmagában)

Mi az a nagygép?

A nagygép 3 szempontból "nagy": Az IBM nagygépek mindhárom kategóriában világelsők, ebből persze most csak az utolsó a fontos.

Milyen oprendszerek találhatóak rajta:

CP

A VM alatt az ún. CP (Control Program) segítségével befolyásolhatjuk a virtuális gépeket. Alapvető szerepe van a gép securityjében, hiszen ha (jogosultság nélkül) módosítani tudunk egy másik virtuális gépet, akkor már gyakorlatilag bármit megtehetünk.

Egy lehetséges megoldás, ha a felhasználók nagy részének azt engedélyezzük, hogy a saját virtuális gépükre vonatkozó paramétereket módosíthassák; néhánynak pedig azt, hogy mások virtuális gépeit, illetve a fizikai gépet módosíthassák (pl. shutdown). Ez egy 2 szintű modell lett volna, hasonlóan a Unix filozófiájához.

Azonban az IBM-nél nem ezt az utat követték, hanem classokat vezettek be, és a CP utasítások/diagnose-ok (kb. API-k) ezek alapján használhatóak. Maximum 32 class lehetséges, ebből 8-nak van alapértelmezése (a korábbi munkahelyemen pl. 12-t használtunk). Ezek nem épülnek egymásra, hanem függetlenek, ezáltal 4 milliárd szint különböztethető meg elméletben. Így elkerülhető volt a Unixok legnagyobb hibája, hogy a suid bites programot megtörve túl sok jogot kapunk.

Ezek a classok egy-egy betűvel (illetve számjeggyel) azonosíthatóak, és az alábbi az alapértelmezés:

A user szintű használathoz a G jog szükséges, segítségével adhatunk ki a virtuális gépünkre vonatkozó parancsokat (pl. újraindítás, trace-elés, memória és processzor módosítása az engedélyezett határokon belül). A más virtuális gépére, illetve az egész gépre vonatkozó parancsokat szokás az ettől eltérő classokba rakni.

Néhány parancsra példa:

DIRMAINT

A DIRMAINT virtuális gép segítségével tároljuk a felhasználók adatait. Ezek közé tartozik az azonosítójuk, accountjuk, jelszavuk, jogaik (ld. előző pont), speciális jogok (pl. LNKNO, ld. később), általuk használt minidiszkek stb.

Ez szintén kényes pont, hiszen a DIRMAINT adatait módosítva megtörhető lenne a teljes rendszer. Ezért ennek a "belső" securityje is igen átgondolt, és a rendszer egészéhez hasonlóan classokra vannak osztva a különböző jogok (régebben ez nem így volt, hanem 6 - egymással nem keverhető - jogosultság volt benne csupán). Ezek a classok:

Természetesen ezek is módosíthatóak menet közben.

SFS

Régen (kb. 1986-ig) egy igen egyszerű file-rendszer volt VM alatt. Minidiszkeken (hasonlóak a PC-s partíciókhoz) voltak a file-ok, és (RACF nélkül) egész minidiszkre lehetett jogot adni, amelyeket háromféle módon lehetett elérni:
  1. DIRMAINT segítségével: ekkor a security biztosított, viszont kicsit nehézkes, mivel a user nem adhat jogot a saját minidiszkjére sem.
  2. Jelszóval: jelszó segítségével a megadott módon (pl. írás, olvasás, multi-írás) elérhető. Természetesen az alapértelmezés, hogy így nem érhető el, de akár publikussá is tehető.
  3. LNKNO jog esetén jelszó nélkül
Jelenleg ezt a módszert ritkán használjuk felhasználói adatok tárolására, helyette egy "igazi" file rendszert, az SFS-t (Shared File System). Ez a virtuális gépek "között" van (hasonlóan az NFS-hez).

SFS file-ok lehetséges jogai: Read, Write. Ezek egyes felhasználóknak adhatóak (vagy publikussá tehetőek). A write magában foglalja a read-et.

SFS könyvtárak lehetséges jogai: Read, Write, Newread, Newwrite. Az utóbbiak a könyvtárba később bekerülő file-okra vonatkoznak. Ha a könyvtárra nincs olvasási jog, de a benne lévő file-ra igen, akkor aliast (kb. "ln -s" Unixon) lehet rá készíteni.

Háromféle felhasználó lehetséges SFS-en belül:

RACF - a profi security nagygépeken

B1 A RACF (Resource Access Control Facility) segítségével lehet B securityt elérni nagygépeken. Lehet C2-re is konfigurálni, és tekintettel arra, hogy a kreatív munkát mennyire akadályozza a B szint (különösen a Mandatory Access Control) általában a hivatalos B1 szintet nem érik el. Mivel az OS/390 megfelel a Unixos specifikációknak is, ezért nem éri el a hivatalos B1 szintet (csak az MVS). Ha kivesszük belőle az OS/390 UNIX támogatást, akkor ismét C2 helyett B1-szerû lesz. Bizonyos jellemzôi már a B3 felé kacsintgatnak, de a hivatalos B3 szintet sohasem érte el.

Az MVS-t, OS/390-et a legtöbb helyen RACF-el használják. Valószínűleg azért, mert akinek van pénze arra, hogy OS/390-et vegyen, annak már fontosak annyira az adatai, hogy a RACF-fel járó kényelmetlenségeket is vállalja.

Fő előnyök:

RACF és az oprendszer

A RACF az operációs rendszerhez képest egy önálló réteget képez, ami miatt gyakran ESM-nek (External Security Manager) nevezik.

Működésére egy példa, hogy egy már bejelentkezett felhasználó módosítani akar egy létező RACF objectumot:

  1. A felhasználó hozzáférést kér az objektumhoz (pl. editorral megnyitja) a resource managertől.
  2. A resource manager a RACF-hez fordul a kéréssel.
  3. A RACF az adatbázisa alapján ...
  4. ... ellenőrzi, hogy van-e megfelelő joga a felhasználónak...
  5. ... a profile-ja alapján.
  6. A RACF visszaadja a státuszt a resource managernek.
  7. A resource manager teljesíti (vagy sem) a kérést.

Belépés

  1. RACF számára definiálva van-e a user
  2. megfelelő jelszót (PassTicket-et, UIDCARD-ot, digitális aláírást) adott-e a user
  3. OS/390 UNIX esetén az UID és a GID érvényes-e
  4. REVOKE (letiltott) státuszú-e a user
  5. az adott napon és időpontban beléphet-e a user
  6. használhatja-e az adott terminált (az adott időben)
  7. használhatja-e az alkalmazást

Profile

2 fő fajtája van a profile-oknak:

1. resource:

2. user:

Special, auditor

Nagyon fontos, hogy a RACFben markánsan külön van választva a jogokkal dolgozó és az azzal rendelkezô személy. Vagyis a SPECIAL joggal rendelkezô bármihez jogot adhat és megvonhat, azonban automatikusan semmilyen jogot sem kap. Az AUDITOR joggal rendelkezô személy csak és kizárólag a naplózási paramétereket tudja módosítani, és a RACF információkat lekérdezni (de a RACF által védett infokhoz nem férhet hozzá). Ezektôl nagyon különbözô atributum az OPERATIONS, aki minden "file"-hoz hozzáférhet (ami nincs külön tiltva számára), de a jogokhoz semmi köze.

Erőforráshozzáférés ellenőrzése

  1. Security level ellenőrzése (read: user >= object, read-write: user = object, terminál: ha kisebb, akkor ideiglenesen csökkenti a user security leveljét)
  2. Security category ellenőrzése (ha van olyan security category, amivel a user nem rendelkezik, de az erőforrás igen, akkor a RACF megtagadja a hozzáférést)
  3. az alábbiak közül legalább egy teljesül:

Naplózás

Egyrészt statisztikai adatokat gyűjt a RACF (ki mikor, hányszor lépett be, mit hányszor használt), másrészt naplózza az alábbiakat: Természetesen számos eszközzel rendelkezik, amivel a logokat elemezni lehet.

 

Irodalomjegyzék

 

Készítette: Bel