Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

Hitelesítés és engedélyezés

dr. Micskei Zoltán

Operációs rendszerek (vimia219)

2

Számítógépes rendszerek biztonsága Fontos ez?

Mindenkinek fontos?

Mikor fontos?

Mikor fontos a számítógépes biztonság?tervezés

implementáció

üzemeltetés

Szoftverfejlesztésben minden szinten foglalkozni kell a biztonsággal

„Ha egy rendszert nem terveztek biztonságosra, akkor később lehetetlen azzá tenni.”

A rendszer biztonsága a leggyengébb láncszem biztonságával azonos.„Az operációs rendszer nem csodaszer, rosszul megírt alkalmazás ellen nem véd.”

Sértetlenség

(Integrity)

Rendelkezésre állás(Availabilit

y)

Bizalmasság

(Confidentiality)

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

Egy technológia magában kevés

A biztonság mindigcsak a célkitűzés függvényében értelmezhető

Biztonságot biztosító eszközök (példák) Kriptográfia

o Kommunikáció sértetlenségéhez, bizalmasságához kell

Hálózati behatoláselleni védelem

Redundancia,újrakonfiguráláso Rendelkezésre állás

Platform szintű behatolás elleni védelemo Rendszeren futó alkalmazások

sértetlensége Hitelesítés, engedélyezés

Sértetlenség

(Integrity)

Rendelkezésre állás

(Availability)

Bizalmasság(Confidentia

lity)

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?

7

Tartalom Számítógépes biztonság bevezető Felhasználók kezelése, hitelesítés

o UNIX, Linux alatto Windows alatt

Engedélyezéso 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 alatto Engedélyezés Windows alatt

• Biztonsági alrendszer alapok• Központosított hozzáférés-vezérlés

Ezekről majd a következő előadáson

részletesen

8

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 üloMi a helyzet a gép-gép közötti szolgáltatásokkal?

9

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ötto Gép és gép között valamilyen hálózaton át

Hitelesítési protokollok kelleneko Gépen belül ill. gépek között csak az „amit tud” sémao Használható bonyolult kriptográfiai számítás

(embernél fejben nyilván nem)

10

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…

11

Miből áll egy felhasználói fiók Linux alatt

User

+ UID+ name+ password+ shell+ home directory+ comment+ expiry date

Fiókot azonosítja UNIX/Linux esetén: UID (integer) (root 0, többiek

általában 1000-…)

12

Miből áll egy felhasználói fiók Linux alatt

User Group

+ GID+ name(+ password)

Initial group

+ UID+ name+ password+ shell+ home directory+ comment+ expiry date

members

1

* *

*

DEMO

Segítség: man parancso man 5 passwd

Felhasználó és csoportok tárolása fájlokban:o /etc/passwdo /etc/shadowo /etc/group

Létrehozás, módosítás, törléso useradd, usermod, userdelo groupadd, groupmod, groupdelo passwd

Felhasználói fiókok Linux alatt

14

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órao adott felhasználó jelszavát kério su – Login shellt indít (környezeti változók miatt fontos)

sudoo parancs végrehajtása más nevébeno saját jelszót kéri + jog kell hozzá (ld. /etc/sudoers)

DEMO

Ki vagyok én?o id

Hogyan állapíthatjuk meg egy futó folyamatról, hogy ki a tulajdonosao ps aux, pstree, /proc/$PID/status

Folyamat futása közben effektív user és group váltásao su, sudo parancsok

Futó folyamatok

16

Hitelesítési mechanizmusok Linuxon Pluggable Authentication Modules (PAM)

o Hitelesítési mechanizmusoknak keretrendszero Cél: alkalmazástól leválasztani a mechanizmusokatoMechanizmusok dinamikus betöltéseoMechanizmusok: /lib/security/

Kerberoso Hálózati hitelesítési protokollo Lásd RFC 4120

17

Tartalom Számítógépes biztonság bevezető Felhasználók kezelése, hitelesítés

o UNIX, Linux alatto Windows alatt

Engedélyezéso 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 alatto Engedélyezés Windows alatt

• Biztonsági alrendszer alapok• Központosított hozzáférés-vezérlés

18

Engedélyezés általános sémái

Szereplő(Actor, Subject)

Szereplőt leíróadatszerkezet

Adatok

Erőforrások

???

Biztonságiszabályzat(policy)

A rendszerben a szereplőt egy adatszerkezet reprezentálja

A jogosultság egy reláció a szereplők és a védett objektumok

között

Védett objektumok(protected objects)

19

Hozzáférés végrehajtása

Adat1

Olvas(Adat1)

Adat2

Jogosultság végrehajtó

(enforcement point)

elvégezhető

Jogosultsági döntő (decision

point)

Erőforrás3

Művelet kontexusa

Művelet

20

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ükoManuálisan (de még automatizáltan is) kezelhetetlen

méretű adathalmaz

21

Teljes hozzáférési mátrix példa

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

Objektum1 Adat2 Erőforrás3 …

Felhasználó1 Olvas

Felhasználó2 Töröl, Olvas Lefoglal

Felhasználó3 Olvas, Ír

Felhasználó4

…

22

Engedélyezés csoportosítása

Kötelezőség

Kötelező(Mandatory)

Belátás szerint (Discretionary)

Szint

Rendszer szintű

Erőforrás szintű

Típus

Integritási szintek

Hozzáférési listák

Engedélyezési módszerek csoportosítása

23

Engedélyezés fajtái - kötelezőség

Klasszikus fogalmak (US DoD szabvány)

Kötelező (mandatory)o jogosultságok osztása csak központilago felhasználók nem módosíthatják a házirendet

Belátás szerint (discretionary)omegfelelő jogú felhasználó továbboszthatja a jogokat

24

Engedélyezés fajtái - típus

Integritás védelemo Címkék definiálása (+ teljes sorrendezés köztük)o Objektumok és szereplők címkézéseo Kiértékelési szabályok definiálása:

• Pl. ha kisebb az objektum címkéje, akkor olvashatom

25

Integritás védelem Példa:

o Címkék: High (H) > Medium (M) > Low (L)o Szereplők: User1[H], User2[L]o Objektumok: Obj1[M], Obj2[H], Obj3[L] oMi legyen a kiértékelési szabály?

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ű objektumból

Bell–LaPadula 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

26

Engedélyezés fajtái - típus

Integritás védelem

Hozzáférés-vezérlési listáko objektum → (szereplő, engedélyek)

• engedély: adatok írása, attribútumok olvasása…

27

Hozzáférés-vezérlési listák

+ mask*

Szereplő Védett objektumEngedély(Permission)

A hozzáférési maszk (access mask)

tartalmazza, hogy pontosan milyen

műveletekre vonatkozik az

engedély

+ OP1()+ OP2()

28

Hozzáférés-vezérlési listák

+ mask* *

Szereplő Védett objektumEngedély(Permission)

Egy védett objektumhoz engedélyek

halmaza rendelhető

*

Néha sorrendezést is megkövetel

29

Role-based Access Control (RBAC)

Szerep alapú hozzáférés-vezérlés

Szereplő Védett objektumSzerep(Role)

+ mask

Engedély(Permission)

*

*

***

A szerep fogalom hierarchikus

szereplő csoportosítási

lehetőséget ad.

A szükséges engedélyek száma kezelhető szintre

csökken

30

Hierarchikus objektumok

Szereplő Védett objektumSzerep(Role)

+ mask+inherit

Engedély(Permission)

*

*

***

*1

Ha a védett objektumok között természetszerűen hierarchia van…

…egy engedély vonatkozhat egész

részfára is öröklődéssel(inheritance)

31

RBAC megvalósítása

User Group

+ Name(+ Purpose…)(+ Shared Secret)

memberOf

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…

32

Tartalom Számítógépes biztonság bevezető Felhasználók kezelése, hitelesítés

o Linux alatto Windows alatto Központosított címtárak

Engedélyezéso 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 alatto Engedélyezés Windows alatt

• Biztonsági alrendszer alapok• Központosított hozzáférés-vezérlés, csoportházirendek

33

Alapelemeko Szereplő: user (felhasználó)o Szereplő hierarchia: group (csoport)o Minden user teszőlegesen sok group tagja leheto Minden group tetszőlegesen sok usert tartalmazhato Group további groupot nem tartalmazhat

Műveleteko olvasás [read], írás [write], végrehajtás/keresés [execute/search]

Engedélyeko Kötött szerkezetű (3x3bittel 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

POSIX fájlrendszer jogosultságok

34

Fájlrendszer jogok kiértékelése-rwxrw-r-- 1 meres students 0 May 6 09:33 test.txt tulajdonos

csoporttulajdonos felhasználó

tulajdonos jogai

tulajdonos csoport jogai

egyébjogok

Folyamat effective UID-je megegyezik a fájl

tulajdonosával

tulajdonos jogok

számítanakigen

Folyamat effective UID-je tagja-e a fájl

tulajdonos csoportjának

tulajdonos csoport jogok számítanak

igen

nem

egyéb jogok számítanak

nem

DEMO

Tulajdonos manipulálása: chowno csak rootnak engedélyezett, nem delegálható

Jogosultság bitek módosítása: chmodo Csak tulajdonosnak engedélyezetto 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)

Linux fájlrendszer jogosultságok

36

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ésszelo Pl. merevlemez teljes tartalma: /dev/sd*, soros port /dev/ttyS*

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?

37

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ásto 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 hallgathatnako 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öno Legkevesebb jog elve (principle of least privileges)o POSIX Capabilities mechanizmus – globális rendszerszintű erőforrásokra

vonatkozó jogosultságok (ún. privilégiumok)

38

Kitekintés Finomabb felbontású jogosultságkezelés

végrehajtható fájlokrao 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. JavaVM)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

(AppArmor) – felfedi ha a „szokásoshoz” képest megváltozik az alkalmazás futása

39

Ö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