Security speci

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

modositva: 2008.

Tartalomjegyzék

• a DoD kategóriái,
• biztonsági cimkék
• a DoD uj kategóriái
• a minimális security nagygépeken (VM önmagában),
• RACF - a profi security nagygépeken,
• irodalomjegyzék.

A DoD kategóriái

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

C

C1

• DAC: Discretionary Access Control: a felhasználók objektumokhoz (pl. file, program) való hozzáférését szabályozza, és lehetővé teszi a felhasználók számára, hogy egyének vagy csoportok számára megosszák saját objektumaikat. Ezen kívűl alkalmanként mások (pl. privilégizált adminisztrátorok) is adhatnak jogot.
• ID: azonosíthatóak és ellenőrizhetőek legyenek a felhasználók, mielőtt bármit is megtehetnének.
• Jól dokumentált legyen.
• És még van néhány kevésbé fontos kritérium (pl. gyártó által tesztelt).

C2

• C1 security
• Audit: a biztonsággal kapcsolatos események naplózása. Képes legyen a userek aktivitását (pl. programindítás, állománymegnyitás) naplózni, és security szempontból érzékeny személyek (adminisztrátorok) tevékenységét kiemelt figyelemmel kisérni. Természetesen minden betörési kisérletet is. A napló számos információt (pl.: időpont, hely, userid, esemény kategóriája stb.) tartalmaz. Az adminisztrátor beállíthatja a kivánt naplózási részletességet.
• Object Reuse: semmilyen módon sem lehet újrahasznosítani az objektumokat. Amikor erőforrást igényel egy subject (user), akkor az ne tartalmazzon információt.

B

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

• C2 security
• Címkék: minden subject (felhasználó) és objektum rendelkezik egy ún. security label-lel. Ennek van hierarchikus része, és nem hierarchikus része. Ez elválaszthatatlan az objektumoktól (kivétel az egyszintű eszközök), és pl. nyomtatásnál is a lap alján/tetején meg kell hogy jelenjen. Csak megfelelő cimkéjű subject férhet hozzá az objektumokhoz
• MAC - Mandatory Access Control: a hozzáférés vezérlése kötelező. Egy subject csak akkor olvashat objektumot, ha legalább akkora jogai vannak (a hierarchikus minősítése legalább akkora, és minden nem hierarchikus minősítéssel rendelkezik, amivel az objektum). Ez még eléggé logikusan hangzik, hiszen ezáltal elkerülhető a "reading up" (alacsony minősítésű subject magas minősítésű objektumot olvas). Viszont a párja, a "writing down" is tilos, vagyis nem írhat a subject nála kisebb jogú objektumot.

B2

• B1 security
• Trusted Path: megbízható kommunikációs csatorna a user és a gép között.
• Device Label: minden eszköz is rendelkezik címkével, amely megadja, hogy mennyire érzékeny adatok tárolhatóak rajta fizikai szempontból.
• Structured Protection: jól definiált formális modell alapján épül fel a rendszer, melynek minden subject és objektum a része.

B3

• B2 security
• A biztonsággal kapcsolatos kód rövid és áttekinthető. Jól elválasztható az operációs rendszer egyéb részeitől.
• Security adminisztrátor alkalmazása

A

A1

A1+

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

Biztonsági cimkék

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

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)):

• "COSMIC TOP SECRET" - "KIEMELTEN SZIGORÚAN TITKOS";
• "NATO SECRET" - "NATO TITKOS";
• "NATO CONFIDENTIAL" - "NATO BIZALMAS";
• "NATO RESTRICTED" - "NATO KORLÁTOZOTT TERJESZTÉSŰ".
• "UNCLASSIFIED" - NEM MINÔSÍTET; (en nem szerepel a fent említett törvényben, de logikailag mindenképpen ide tartozik.)

Security category

Egy példa:

• atom robbanófej
• robotrepülôgép
• harckocsi

A DoD uj kategoriai - Common Criteria 2.x

• EAL 1: funkcionalisan tesztelt a biztonsagot nem veszik komolyan, de a leirasnak azert van koze a termek mukodesehez, gyakorlatilag ilyen alacsony minositest szinte senki sem ker a termekere.
• EAL 2: sturturalisan tesztelt alapszintu biztonsag a gyarto minimalis kozremukodesevel attekintve, milyenre terveztek a rendszert. Ritkan kert minosites, mert tul alacsony.
• EAL 3: modszeresen tesztelt es ellenorzott a tervek alapos attekintese biztonsagi szempontbol, es a FEJLESZTO tamadhatosagi tesztjeinek leellenorzese (nagyjabol onmagaban megfelel a C1-nek), nagyszamu rendszer megfelel neki (pl. szamos Linux disztribucio is)
• EAL 3+CAPP Felügyelt hozzáférés-védelmi profil lehetove teszi a biztonsagi beallitasok pontos megadasat es a biztonsagi esemenyek naplozasat (a korabbi C2-nek felel meg)
• EAL 4: modszeresen tesztelt, ellenorzott es atnezett a tervek es a MEGVALOSITAS attekintese biztonsagi szempontbol. A korabbiaknal joval magasabb koltsegu az ellenorzes, es a legmagasabb minosites ami elerheto egy nem kifejezetten az EAL-hoz tervezett rendszer eseten. Nagyszamu rendszer megfelel neki.
• EAL4+LSPP: Címkézett biztonságvédelmi profil cimkek hasznalatat is eloirja (a korabbi B1-nek felel meg). A rovid leirasokban gyakran nem emelik ki, hogy az EAL4-en felul meg az LSPP-nek is megfelel a rendszer, pedig joval ritkabb, pl. a z/OS, illetve a z/OS-en futo DB2 megfelel ennek a szintnek.
• EAL5: felformalisan tervezett es tesztelt egyetlen igazi operacios rendszer sem felel ennek a kriteriumnak, csak a mainframe-ek logikai particionalasat vegzo PR/SM (de ez messze nem egy igazi operacios rendszer) es a XTS-400/STOP6.1.E
• EAL6: felformalisan ellenorzott,tervezett es tesztelt
• EAL7: formalisan ellenorzott,tervezett es tesztelt annyira magas szint, hogy osszetett rendszer (operacios rendszer, adatbaziskezelo, ...) varhatoan a jovoben sem fogja elerni ezt a szintet.

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

Mi az a nagygép?

• nagy a megbízhatósága,
• nagy az adatfeldolgozó képessége,
• nagy a security benne.

Milyen oprendszerek találhatóak rajta:

• VM - Virtual Machine: Teljes értékű virtuális gépeket nyújt 1971-től.
• MVS, OS/390, zOS - A világ leghibatűrőbb operációs rendszere, a nagygépek fő oprendszere 1964-től, egyben az egyik leggyorsabban fejlődő oprendszer. Az MVS továbbfejlesztése (? :-)) az OS/390, ami az egyik első Unix95 szabványú oprendszer, zOS ugyanennek a 64 bites verzioja.
• VSE - 1962-ben ideiglenesen összedobta pár ember az IBM-nél, amíg kész lesz az OS, de azóta sem sikerült kidobniuk.

CP

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 - Fő operátor
• B - Erőforráskezelő operátor
• C - Rendszerprogramozó
• D - Spoolkezelő operátor
• E - Rendszeranalizáló
• F - Rendszermérnök (hardveres)
• G - Közönséges felhasználó
• H - IBM használatára fenntartott

Néhány parancsra példa:

• A - FORCE, SHUTDOWN, XAUTOLOG: automatikusan beléptet egy virtuális gépet jelszó nélkül
• B - XAUTOLOG, ATTACH: nem megosztható eszköz (pl. mágnesszalag) hozzárendelése egy virtuális géphez
• C - STORE H : fizikai memória módosítása
• D - TRANSFER : más felhasználó spool állományának áthelyezése
• E - MONITOR EVENT : CP események naplózása
• F - SYNCMDRS : fizikai eszközök hibaüzeneteinek beolvasása
• G - QUERY VIRTUAL : a saját virtuális gépre vonatkozó információk kiírása
• H -
•     - LOGOFF

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:

• A - Adminisztráció, non-DASD (DASD: vinyó más néven)
• D - DASD management
• G - Közönséges felhasználó
• H - Felhasználói tanácsadó
• M - Password monitor
• O - System operator
• P - DASD management program, (pl. DFSMS/VM, amely többszintű tárolást biztosít)
• S - Support programmer
• Z - Internal communication

SFS

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

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:

• Adminisztrátor: joga van leállítani, kimenteni stb. a file-rendszert, és joga van minden objektumhoz, mintha a sajátja lenne. Létrehozhat/töröhet felhasználókat, módosíthatja a limitjüket.
• User: a saját állományaihoz/könyvtáraihoz joga van (a saját könyvtára a file-rendszeren belüli azonosítójával kezdődik).
• Egyéb felhasználók: a gép nem minden felhasználójának van automatikusan joga a gép összes file-rendszeréhez. Ha egy file-rendszert publikussá tettek, akkor az azon belüli publikus adatokhoz hozzáférhet a gép bármely felhasználója.

RACF - a profi security nagygépeken

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:

• Rugalmas vezérlés: helyi szabályok segítségével hozzáalakítható a konkrét elvárásokhoz.
• Széles körű illeszthetőség: nagyszámú (nagygépes) programmal együttműködik.
• Központi/osztott ellenőrzés: amennyiben túl bonyolult/nagyméretű a rendszer ahhoz, hogy egyetlen security adminisztrátor felügyelje, létre lehet hozni csoportokat. Ekkor a csoport egésze kap jogokat a fő security adminisztrátortól, és a csoporton belüli security adminisztrátor osztja ezeket tovább az egyes usereknek.
• Átlátszóság: számos felhasználó nem törődik a securityvel, a maradék is időnként nem megfelelően védi az adatait. RACF esetén nincs szükség arra, hogy aggódjunk a userek magatartása miatt, mivel nem nekik kell az adataik védelmével törődni.
• Exit rutinok: ezek segítségével 100%-osan szabadon konfigurálható a rendszer.
• Sysplex támogatás: segítségével a sysplexen belül (amelybe 32 processor complex tartozhat) a security is közös.

RACF és az oprendszer

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

1. resource:

• Resource name: a védeni kívánt erőforrás neve (a végén tartalmazhat joker karaktert)
• Profile owner: nem biztos, hogy az erőforrás tulajdonosa is
• UACC: mindenki számára engedélyezett hozáférés (mint Unixban a world 3 bitje)
• ACL: a groupok, userek listája, akik hozzáférhetnek az erőforráshoz (a móddal együtt, pl. read, alter, update)
• Classification: seclevel + seccategory (security label) (ld. B1) A seclevel a hierarchikus része a security labelnek, amelyet 0-254 közötti egész számként implementáltak, minnél magasabb, annál érzékenyebb szintet jelez. A seccategory a nem hierarchikus része a security labelnek, legfeljebb 32k különböző lehet egy rendszerben.
• Auditing/warning/notification options

2. user:

• User ID: userid és valós név
• Password
• Profile owner
• User attributes: mikor léphet be, felfüggesztett-e, definiáláskori security label, auditor/operator/special-e, card illetve digitális aláirás megkövetelt-e
• Classification: aktuális security label
• Data: egyéb adatok

Special, auditor

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:
   • az erőforrás dataset (kb. file) és a HighLevelQualifier (kb. főkönyvtár) megegyezik a useriddel
   • a userid az ACL-ben van megfelelő joggal
   • a group az ACL-ben van megfelelő joggal
   • az UACC engedélyezi a hozzáférést

Naplózás

• engedély nélküli belépési kisérletek
• érvényes és érvénytelen kisérletek RACF által védett erőforrások használatára
• érvényes és érvénytelen kisérletek RACF parancsok kiadására

Irodalomjegyzék

• Orange Book (DoD kategóriák) (Postscript formátumban),
• Orange Book (DoD kategóriák) (RTF formátumban),
• RACF and Security Redbooks Bookshelf
• RACF V1R10 for VM Bookshelf
• Certified product list
• Labeled Security Protection Profile (rovid, html)
• Labeled Security Protection Profile (reszletes, pdf)
• zOS 1.9 security target (181 oldal, pdf)
• Tenix Interactive Link Data Diode Device (pdf, az egyetlen EAL7 minositesu dolog a vilagon)

Készítette: Bel