Opercis rendszerek vimia 219 Hitelests s engedlyezs dr

Operációs rendszerek (vimia 219) Hitelesítés és engedélyezés dr. Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Számítógépes rendszerek biztonsága § Fontos ez? § Mindenkinek fontos? § Mikor fontos? 2

Mikor fontos a számítógépes biztonság? § Szoftverfejlesztésben minden szinten foglalkozni kell a biztonsággal tervezés § „Ha egy rendszert nem terveztek biztonságosra, akkor később lehetetlen azzá tenni. ” implementáció § A rendszer biztonsága a leggyengébb láncszem biztonságával azonos. üzemeltetés „Az operációs rendszer nem csodaszer, rosszul megírt alkalmazás ellen nem véd. ”

Miből áll a „biztonság” fogalma § Három kölcsönösen egymásra épülő alapfogalom § Cél: o garantálni, hogy a rendszer mindig az elvárt módon viselkedjen Sértetlenség (Integrity) § Egy technológia magában kevés Bizalmasság (Confidentiality) § A biztonság mindig csak a célkitűzés függvényében értelmezhető Rendelkezésre állás (Availability)

Biztonságot biztosító eszközök (példák) Sértetlenség § Kriptográfia o Kommunikáció sértetlenségéhez, bizalmasságához kell § Hálózati behatolás elleni védelem § Redundancia, újrakonfigurálás o Rendelkezésre állás (Integrity) Bizalmasság Rendelkezésre állás (Confidentiality) (Availability) § Platform szintű behatolás elleni védelem o Rendszeren futó alkalmazások sértetlensége § Hitelesítés, engedélyezés

Ki az „illetékes”? Hitelesítés (Authentication) • Ki vagyok? • Az vagyok-e akinek mondom magam? Engedélyezés (Authorization) • Mihez férhetek hozzá? • Mit csinálhatok vele?

Tartalom § Számítógépes biztonság bevezető § Felhasználók kezelése, hitelesítés o UNIX, Linux alatt o Windows alatt § Engedélyezés o Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférési jogosultság listák o Engedélyezés UNIX, Linux alatt o Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés 7 Ezekről majd a következő előadáson részletesen

Hitelesítés § Mi alapján dönthető el, hogy ki kicsoda? o …amit tud (pl. : jelszó) o …amije van (pl. : kulcs, belépőkártya) o …ami ő (pl. : ujjlenyomat, arckép) § Ezek (akár egy kombinációja) alapján egy gép el tudja dönteni, hogy ki a személy, aki előtte ül o Mi a helyzet a gép-gép közötti szolgáltatásokkal? 8

Hitelesítés § Hitelesítés három szinten kerülhet elő: o Ember és gép közötti interakció o Gépen belül futó alkalmazások valamint az OS között o Gép és gép között valamilyen hálózaton át § Hitelesítési protokollok kellenek o Gépen belül ill. gépek között csak az „amit tud” séma o Használható bonyolult kriptográfiai számítás (embernél fejben nyilván nem) 9

Miből áll egy felhasználói fiók? User + ID + Name + Real Name + Personal data… + Shared Secret (Password, etc. ) + Private Datastore path A rendszer számára a felhasználó egy objektum… 10

Miből áll egy felhasználói fiók Linux alatt Fiókot azonosítja UNIX/Linux esetén: § UID (integer) § (root 0, többiek általában 1000 -…) User + UID + name + password + shell + home directory + comment + expiry date 11

Miből áll egy felhasználói fiók Linux alatt User Initial group + UID + name + password + shell + home directory + comment + expiry date * 1 members * 12 * Group + GID + name (+ password)

DEMO Felhasználói fiókok Linux alatt § Segítség: man parancs o man 5 passwd § Felhasználó és csoportok tárolása fájlokban: o /etc/passwd o /etc/shadow o /etc/group § Létrehozás, módosítás, törlés o useradd, usermod, userdel o groupadd, groupmod, groupdel o passwd

Identitás váltása § Folyamat identitása menet közben változhat o Real UID vs. Effective UID § id o Ki vagyok én? § su o váltás egy adott felhasználóra o adott felhasználó jelszavát kéri o su – Login shellt indít (környezeti változók miatt fontos) § sudo o parancs végrehajtása más nevében o saját jelszót kéri + jog kell hozzá (ld. /etc/sudoers) 14

DEMO Futó folyamatok § Ki vagyok én? o id § Hogyan állapíthatjuk meg egy futó folyamatról, hogy ki a tulajdonosa o ps aux, pstree, /proc/$PID/status § Folyamat futása közben effektív user és group váltása o su, sudo parancsok

Hitelesítési mechanizmusok Linuxon § Pluggable Authentication Modules (PAM) o Hitelesítési mechanizmusoknak keretrendszer o Cél: alkalmazástól leválasztani a mechanizmusokat o Mechanizmusok dinamikus betöltése o Mechanizmusok: /lib/security/ § Kerberos o Hálózati hitelesítési protokoll o Lásd RFC 4120 16

Tartalom § Számítógépes biztonság bevezető § Felhasználók kezelése, hitelesítés o UNIX, Linux alatt o Windows alatt § Engedélyezés o Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférés-vezérlési listák o Engedélyezés UNIX, Linux alatt o Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés 17

Engedélyezés általános sémái Védett objektumok (protected objects) Biztonsági szabályzat (policy) Szereplő (Actor, Subject) A rendszerben a szereplőt egy adatszerkezet reprezentálja ? ? ? Adatok Erőforrások Szereplőt leíró adatszerkezet A jogosultság egy reláció a szereplők és a védett objektumok között 18

Művelet Hozzáférés végrehajtása Olvas(Adat 1) Jogosultság végrehajtó (enforcement point) Adat 1 elvégezhető Jogosultsági döntő (decision point) Adat 2 Erőforrás 3 Művelet kontexusa 19

Engedélyezés gyakorlati kihívásai § Sok szereplő o Rendszerek különbözőképpen azonosítják őket § Sok védett objektum o Rendszerek ezeket is különbözőképpen azonosíthatják § Jogosultsági relációk: o (Szereplők) X (Objektumok) X (Művelettípusok) o Az ilyet teljes hozzáférési mátrixnak nevezzük o Manuálisan (de még automatizáltan is) kezelhetetlen méretű adathalmaz 20

Teljes hozzáférési mátrix példa Objektum 1 Felhasználó 1 Erőforrás 3 Töröl, Olvas Lefoglal … Olvas Felhasználó 2 Felhasználó 3 Adat 2 Olvas, Ír Felhasználó 4 … § KÉRDÉS: mekkora lenne ez egy mai normál rendszeren? § CÉL: ehelyett valami jobb adatszerkezetet és ellenőrzési módszert találni 21

Engedélyezési módszerek csoportosítása Kötelező (Mandatory) Kötelezőség Belátás szerint (Discretionary) Engedélyezés csoportosítása Rendszer szintű Szint Erőforrás szintű Integritási szintek Típus Hozzáférési listák 22

Engedélyezés fajtái - kötelezőség § Klasszikus fogalmak (US Do. D szabvány) § Kötelező (mandatory) o jogosultságok osztása csak központilag o felhasználók nem módosíthatják a házirendet § Belátás szerint (discretionary) o megfelelő jogú felhasználó továbboszthatja a jogokat 23

Engedélyezés fajtái - típus § Integritás védelem o Címkék definiálása (+ teljes sorrendezés köztük) o Objektumok és szereplők címkézése o Kiértékelési szabályok definiálása: • Pl. ha kisebb az objektum címkéje, akkor olvashatom 24

Integritás védelem § Példa: o Címkék: High (H) > Medium (M) > Low (L) o Szereplők: User 1[H], User 2[L] o Objektumok: Obj 1[M], Obj 2[H], Obj 3[L] o Mi legyen a kiértékelési szabály? Bell–La. Padula modell feltételei (bizalmasság) : „No read up” – nem olvashatok magamnál magasabb szintű objektumból „No write down” – nem írhatok magamnál alacsonyabb szintű objektumba Biba modell feltételei (sértetlenség) : „No write up” – nem írhatok magamnál magasabb szintű objektumba „No read down” – nem olvashatok magamnál alacsonyabb szintű 25 objektumból

Engedélyezés fajtái - típus § Integritás védelem § Hozzáférés-vezérlési listák o objektum → (szereplő, engedélyek) • engedély: adatok írása, attribútumok olvasása… 26

Hozzáférés-vezérlési listák * Szereplő A hozzáférési maszk (access mask) tartalmazza, hogy pontosan milyen műveletekre vonatkozik az engedély 27 + mask Engedély (Permission) + OP 1() + OP 2() Védett objektum

Hozzáférés-vezérlési listák Egy védett objektumhoz engedélyek halmaza rendelhető * * Szereplő Néha sorrendezést is megkövetel 28 + mask * Engedély (Permission) Védett objektum

Szerep alapú hozzáférés-vezérlés Role-based Access Control (RBAC) * * Szereplő * * A szerep fogalom hierarchikus szereplő csoportosítási lehetőséget ad. * Szerep (Role) + mask Engedély (Permission) A szükséges engedélyek száma kezelhető szintre csökken 29 Védett objektum

Hierarchikus objektumok Ha a védett objektumok között természetszerűen hierarchia van… 1 * * Szereplő * * + mask +inherit * Szerep (Role) Engedély (Permission) …egy engedély vonatkozhat egész részfára is öröklődéssel (inheritance) 30 * Védett objektum

RBAC megvalósítása member. Of Group User A felhasználói csoporttagság valójában egy RBAC megvalósítási lehetőség További példák: DB szerverek; ASP. NET Role Service… 31 + Name (+ Purpose…) (+ Shared Secret)

Tartalom § Számítógépes biztonság bevezető § Felhasználók kezelése, hitelesítés o Linux alatt o Windows alatt o Központosított címtárak § Engedélyezés o Engedélyezés általános sémái • Szerep alapú hozzáférés-vezérlés • Hozzáférés-vezérlési listák o Engedélyezés Linux alatt o Engedélyezés Windows alatt • Biztonsági alrendszer alapok • Központosított hozzáférés-vezérlés, csoportházirendek 32

POSIX fájlrendszer jogosultságok § Alapelemek o o o Szereplő: user (felhasználó) Szereplő hierarchia: group (csoport) Minden user teszőlegesen sok group tagja lehet Minden group tetszőlegesen sok usert tartalmazhat Group további groupot nem tartalmazhat § Műveletek o olvasás [read], írás [write], végrehajtás/keresés [execute/search] § Engedélyek o Kötött szerkezetű (3 x 3 bittel megadva) • Első a tulajdonos felhasználónak • Második a tulajdonos csoportnak • Harmadik mindenkinek o (Speciális bitek) • setuid, setgid: futtatásnál átveszi a fájl tulajdonosának uid-, gid-jét, • sticky: újonnan létrejött fájlok tulajdonosát állítja o Az execute bit tiltó hatása implicit módon öröklődik a könyvtárakon, más öröklés nincs 33

Fájlrendszer jogok kiértékelése -rwxrw-r-- 1 meres students 0 May 6 09: 33 test. txt tulajdonos csoport jogai egyéb jogok tulajdonos felhasználó 34 tulajdonos csoport

DEMO Linux fájlrendszer jogosultságok § Tulajdonos manipulálása: chown o csak rootnak engedélyezett, nem delegálható § Jogosultság bitek módosítása: chmod o Csak tulajdonosnak engedélyezett o Többféle megadási mód: • Teljes felülírás 3 db oktális számmal (r: 4, w: 2, e: 1), pl. : – 644 (user: read+write, group: read, other: read) • Módosítás pl. : – u+x (user add execute), g-w (group remove write) § Listázás: ls -l illetve ls -l -n § (POSIX ACL is létezik, idő hiányában nem tárgyaljuk)

Fájlrendszeren kívüli engedélyek § Egyéb védett objektumok: o „UNIX alatt minden erőforrás fájl” – jó elv, sajnos nem igaz következetesen mindenre § Sok periféria rendelkezik fájlrendszer interfésszel o Pl. merevlemez teljes tartalma: /dev/sd*, soros port /dev/tty. S* o A kernel és teljes fizikai memória: /dev/kmem, /dev/mem § Mi van azokkal a műveletekkel, o amik nem sima olvasás vagy írás jellegűek? o Nem kapcsolhatóak egy fájlhoz? 36

Fájlrendszeren kívüli engedélyek § Speciális kiváltságok root felhasználó nevében futó folyamatoknak o Kérhetnek valós idejű ütemezési prioritást o Hozzáférhetnek közvetlenül a perifériákhoz (!) • Kell előtte memória illetve I/O tartomány allokáció o 1024 alatti TCP/UDP porton hallgathatnak o Kernel bizonyos konfigurációs beállításait megváltoztathatják, új modult tölthetnek be stb. § Miért rossz ez? o Webszerver: 80 -as porton hallgat, de nem szabadna a rendszer konfigurációját módosítania § Nem előnyös, ha ezek nem szabályozhatóak külön-külön o Legkevesebb jog elve (principle of least privileges) o POSIX Capabilities mechanizmus – globális rendszerszintű erőforrásokra vonatkozó jogosultságok (ún. privilégiumok) 37

Kitekintés § Finomabb felbontású jogosultságkezelés végrehajtható fájlokra o Platform szintű behatolás elleni védőmechanizmusok támogatására (PAX, grsecurity) o A védőmechanizmusok számos egyébként sértetlen programot tesznek működésképtelenné (pl. Java. VM) o Speciálisan kivételezni kell az ilyen alkalmazásokat fájlrendszerbe írt címkével (SELinux Security Labels) o Alkalmazásokhoz hozzárendelt rendszerhívási profilok (App. Armor) – felfedi ha a „szokásoshoz” képest megváltozik az alkalmazás futása 38

Összefoglalás § Hitelesítés és engedélyezés szétválasztása § Engedélyezés általános fogalmai § Megvalósítás UNIX/Linux környezetben 39