PV157 ­ Autentizace a řízení přístupu
Řízení přístupu

ˇ Funkce pro řízení, který subjekt (uživatel, proces ...) má jaký
přístup k určitému objektu (souboru, databázi, tiskárně ...).
ˇ Implementovaná bezpečnostním mechanismem řízení přístupu.
Hierarchie
Hardware
Operační systém
Middleware (např. databázový systém)
Aplikace (např. informační systém)
Předpoklad implementace
je bezpečně implementovaná funkce ,,Identifikace & autentizace"
ˇ Kategorie mechanismů řízení přístupu
fyzické typicky ochrana off-line uložených archivních kopií
logické typicky ochrana on-line uchovávaných dat
Řízení přístupu

Pojmy
ˇ vlastník dat (owner)
subjekt, statutární autorita odpovědná subject
za daný typ dat,
za konkrétní data daného typu,
za datový objekt object
ˇ správce (dat, objektu) (custodian)
subjekt, autorita pověřená odpovědností
za bezpečnost konkrétních dat,
za bezpečnost konkrétního objektu
ˇ uživatel (user)
také autorizovaný uživatel,
oprávněný uživatel
subjekt, mající právo přístupu
ke konkrétním datům, ke konkrétnímu objektu

Typy omezení přístupu k objektu
ˇ R, Read Only
ano: kopírování, prohlížení, tisk, ...
ne: rušení, vytváření, modifikace, ...
ˇ RW, Read/Write
ano: kopírování, prohlížení, tisk, ... , rušení, vytváření, modifikace
ˇ X, Execute
ano: řízení běhu procesu
ne: kopírování, prohlížení, tisk, ... , rušení, vytváření, modifikace
ˇ daný omezením
časem pouze v danou dobu
místem pouze z ...
obsahem interval hodnot (bankovní automat)
typem služby e-mail ano, telnet ne

Správa řízení přístupu ­ modely
ˇ centralizovaná správa řízení přístupu
1 správce všech objektů (IS, Informačního systému)
mnoho vlastníků, mnoho uživatelů
klad: přísné řízení, konzistentnost
zápor: vysoká (časová) režie v (distribuovaných) IS
ˇ decentralizovaná správa řízení přístupu
objekt spravuje jeho vlastník ­ správce,
mnoho vlastníků ­ správců, mnoho uživatelů
klad: snadno dosažitelná vysoká odpovědnost
zápory:
obtížnost udržení konzistence komunikace mezi správci
není dostupný okamžitý celkový přehled stavu
hůře se prosazuje bezpečnostní politika IS

hesloheslo
Heslo
ˇ heslo, šifrovací klíč
všeobecné
samostatné pro
čtení, modifikaci, rušení, ...
ˇ každý objekt má přiděleno (a) jeho vlastníkem heslo (hesla)
ˇ právo přístupu má subjekt znající heslo
ˇ použito například ke sdílení disků/adresářů v některých verzích
MS Windows
ˇ negativa:
nelze zjistit kdo všechno má právo přístupu
heslo musí být uloženo v programu

Matice přístupových práv
ˇ Matice udávající přístupová práva subjektů k objektům
objektA objektB objektC
subjekt1
subjekt2
rw
rwx
rx
rwx rwx
­

Matice přístupových práv
ˇ Může být i trojrozměrná
ˇ 3. rozměrem je program
ˇ Máme trojice (subjekt, program, objekt) a jim odpovídající
přístupová práva
(Alice, účetní program, účetní data) má práva {r,w}
(Alice, editor, účetní data) má práva {}
(Alice, editor, /etc/passwd) má práva {}
(Alice, passwd, /etc/passwd) má práva {r,w}
ˇ Dvourozměrná i třírozměrná matice je v praxi tak velká, že je
problém s ní efektivně pracovat (ukládat ji, vyhledávat v ní)
Tisíce až miliony objektů (souborů)
Tisíce až miliony subjektů (uživatelů)
ˇ Matici můžeme ukládat po řádcích či po sloupcích

Seznamy přístupových práv
ˇ Ukládáme matici přístupových práv
po objektech
ˇ Matice je často řídká, proto ukládáme
jen neprázdné prvky
ˇ Seznam přístupových práv objektu ­ ACL (Access Control List)
ˇ Element přístupových práv ­ ACE (Access Control Element)
prvek ACL
přidělení práv přístupu jednotlivému subjektu, skupině subjektů, ...
ˇ Výhoda seznamu přístupových práv
modifikaci/zpřístupnění lze omezit na jednotlivce ve skupině
ˇ Nevýhoda seznamu přístupových práv
obtížná správa, neefektivní kontrola přístupových práv při přístupu k objektu
nesnadné zjistit k jakým objektům má určitý uživatel přístup (například při změně
pracovního zařazení)
objekt
Bezpečnostní
deskriptor
objektu
ACL
ACE
ACE
. . .
ACE

rwx rwx rwxrwx rwx rwx
Vlastník
správce
skupina ostatní
110 100 000originál
110 100 000kopie člena skupiny
110 100 100zrádný člen skupiny upraví
Implementace ACL ­ UNIX
ˇ Nelze zamítnout
přístup jednotlivci
ze skupiny vlastníka
ˇ Ve starších verzích UNIXu
mohl uživatel patřit do pouze
jedné skupiny
ˇ Nutnost vytvářet nové skupiny
uživatelů (může jen root)
ˇ Nelze zajistit důvěrnost:
soubor

SUID/SGID programy
ˇ Matice přístupových práv jen dvourozměrná.
ˇ Povolení práv pro určité programy je třeba řešit pomocí
SUID/SGID bitů.
ˇ Vlastník programu může nastavit, že program po spuštění bude
běžet s právy uživatele/skupiny vlastníka.
ˇ Například program pro změnu hesla potřebuje přístup zápisu do
souboru /etc/passwd resp. /etc/shadow. Běžný uživatel však nemá
k těmto souborům přístup pro zápis. Proto je program passwd
nastaven jako SUID na uživatele root, který do těchto souborů
zapisovat může.
ˇ Přístup SUID/SGID není příliš intuitivní. Leniví programátoři píší
hromadu programů, které musí běžet SUID root. SUID programy
musí být napsány bezpečně, jejich vstupy (parametry, stdin,
proměnné prostředí) nejsou důvěryhodné.

Implementace ACL ­ moderní UNIX
ˇ Administrátor (root, resp. uživatel s UID 0) má neomezený
přístup ke všem objektům, může měnit libovolné soubory,
upravovat logy apod.
ˇ Nejen skutečný administrátor, ale i hacker apod.
ˇ Snaha o omezení možností administrátora
Nové vlastnosti souborového sytému UNIXových verzí odvozených od
Berkeley větve
Možnost nastavit dodatečné ,,flagy" pro soubory
o Append-only: lze pouze přidávat data ­ vhodné pro logy
o Immutable: soubor není možné modifikovat ­ vhodné pro systémové soubory
o Undeleteable ­ nesmazatelné
Možnost nastavit pro uživatele i skupiny
Nastavuje se při bootu, potom ani root nemůže provádět změny
Je i v Linuxu: chattr pro ext2/ext3 (lze však měnit kdykoliv)

Implemetace ACL ­ moderní UNIX
ˇ Jen trojice rwx pro vlastníka, skupinu a ostatní není dostatečně
jemné
ˇ Moderní UNIXové systémy se snaží tyto trojice doplnit
skutečnými ACE
Tyto ACE obsahují výjimky ke standardním přístupovým právům (výše
uvedené trojici)
Můžeme tak odebrat právo jednotlivci ve skupině případně přidat právo
jinému uživateli
ˇ Tento přístup implementují mnohé komerční UNIXové systémy
(např. VAX, ...)
ˇ ACL pro ext2/ext3 existuje již nějakou dobu ve formě nepříliš
rozšířených patchů jádra
ˇ ACL pro ext2/ext3 se stalo standardní součástí jádra Linuxu >2.5

Implementace ACL ­ Windows
ˇ Nejen read, write, execute, ale také take ownership, change
permissions, delete pro uživatele nebo skupiny uživatelů.
ˇ Atributy nejen Ano/Ne, ale i AccessDenied, AccessAllowed a
SystemAudit (zpracováváno v tomto pořadí).
ˇ Větší možnosti nastavování přístupových práv znamenají
možnost přesněji postihnout/implementovat bezpečnostní
politiku.
ˇ V praxi však často uživatel přijde, naloguje se jako administrátor
(aby mohl instalovat aplikace apod.) a jako administrátor pracuje
do ukončení své práce.

Řízení přístupu na čipových kartách
ˇ Řízení přístupu k datům na kartě je tvořeno především řízením
přístupu k souborům.
ˇ S každým souborem je svázána hlavička souboru, která určuje
přístupová práva k souboru.
ˇ Základním principem řízení přístupu je zadávání PINů a jejich
management.
ˇ Přístup k souboru může být například vázán na splnění některé
z těchto podmínek:
ALW (vždy povolen přístup)
CHV1 (nutné zadat PIN uživatele 1)
CHV2 (nutné zadat PIN uživatele 2)
NEV (přístup nepovolen)

ˇ PINy jsou ukládány v samostatných souborech (EF).
Přístupová práva k těmto souborům určují možnost
změny těchto PINů.
ˇ Při změně PINu je požadavek provázen starým a
novým PINem.
ˇ Počet neúspěšných pokusů bývá omezen. Po
překročení limitu (3 ­ 5) je PIN blokován.
ˇ Pro odblokování je třeba zadat PIN a odblokovací
PIN.
ˇ I počet neúspěšných odblokování je omezen.
Čipové karty ­ PIN management

ˇ Seznam přístupových oprávnění (capabilities)
ˇ Ukládáme matici přístupových práv po subjektech
ˇ Není žádnou novinkou
ˇ Například: model Multics, IBM AS/400
ˇ Dnes často ve formě certifikátů
ˇ Výhoda seznamu přístupových oprávnění
efektivní kontrola přístupových práv při přístupu k objektu
ˇ Nevýhoda seznamu přístupových práv
Nesnadné zjistit kdo má k určitému objektu přístup
Seznam přístupových oprávnění
vlastník
správce
skupina
ostatní
subjekt
RO
objekt
objektsubjekt
RW
X
objekt
objekt
RO
RW
X

Windows 2000
ˇ Windows 2000 implementují nejen ACL, ale i přístupová práva
ve formě přístupových oprávnění.
ˇ Tato bezpečnostní oprávnění mohou převážit nebo doplnit
přístupová práva ve formě ACL.
ˇ Bezpečnostní politika je svázána se skupinami uživatelů
[skupiny (groups) jsou definovány v aktivním adresáři (active
directory)].
ˇ ,,Skupinové politiky" ("Group policy") se vztahují na domény,
počítače, celé organizace.
ˇ Příklad: Skupinová politika obsahuje seznam aplikací, které
skupina uživatelů nemá oprávnění spouštět (např. internet
explorer, outlook express, ...). Přístupová práva programu na
disku (internet explorer) jsou nastavena na [everybody: rx].
Skupinová politika převáží přístupové práva souboru (aplikace)
 spuštění aplikace je zakázáno.

Windows 2000
ˇ Nastavení skupinové politiky

Politiky řízení přístupu
ˇ volitelný přístup (discretionary)
subjekt ­ vlastník objektu rozhoduje o tom, kdo má k objektu přístup
volitelná ... určuje subjekt­vlastník objektu
typicky politika podporovaná operačním systémem
podporuje i operace změny vlastníka objektu
ˇ povinný přístup (mandatory)
systémová politika nezávislá na vůli subjektů rozhoduje o tom, kdo má
k objektu přístup

Volitelné řízení přístupu ­ výhody
ˇ Jednoduchost, proto malá režie
ˇ Velká vyjadřovací schopnost
ˇ Někdy možné vázat udělení přístupových práv na splnění
dodatečných časových, místních apod. podmínek
ˇ Flexibilita

Objekt X Objekt YRW- R- - - - - RW- R- - R- -
Volitelné řízení přístupu ­ nevýhody
ˇ Nedostatečná bezpečnost
použití pouze přístupových práv není dostatečné
v situacích, kdy klademe důraz na bezpečnost
ˇ Není odolné vůči "Trojským koňům"
ˇ Systém se nestará o využití jednou získaných dat
např. dám skupině právo čtení na můj důvěrný soubor, nějaký člen si ho
zkopíruje a nesprávně nastaví přístupová práva

Spouštění nedůvěryhodného kódu
ˇ Jak se chovat k nedůvěryhodnému kódu, získanému např.
z internetu?
ˇ Autentizace kódu, viz např. Authenticode
ˇ Speciální jazyk neumožňující škodlivou činnost (JavaScript)
ˇ Kontrolní programy, které před spuštěním kontrolují kód na
škodlivou činnost
Obecně nerozhodnutelné
V praxi heuristiky antivirových programů
ˇ Spuštění kódu s minimálními uživatelskými právy (např. unixový
nobody)
ˇ Omezené prostředí, ve kterém nemá kód přístup k určitým
prostředkům (,,Sandbox")
Např. interpret Javy ­ Java Virtual Machine ­ applety stažené z webu (bez
přístupu na disk, komunikace možná jen s původním serverem)

Podpora řízení přístupu v HW
ˇ Procesory
Úkolem je zamezit komunikaci/ovlivňování procesů jinak než explicitně
povoleným způsobem
Např. ,,fence address" ­ limit paměti, do nižších adres má přístup jen
operační systém
Např. ,,segmentové adresování" ­ Adresování formou segment+offset.
Segment může měnit jen operační systém (referenční monitor)
Např. dva režimy procesoru ­ autorizovaný a neautorizovaný.
V neautorizovaném režimu není možné měnit segmentové registry.
Např. ,,Rings of protection" ­ několik režimů činnosti s různými právy.
Měnit ring možné jen v režimu ringu 0 (operační systém). Volání rutin
operačního systému ­ změna ringu: GATE
Např. vojenské systémy chrání nejen data procesů, ale i metadata (jaké
procesy s jakými parametry spuštěné kterými uživateli běží v systému)

Objektové programovaní
ˇ Přístup k datům může být omezen pouze na explicitně uvedené
metody
ˇ Příklad v C++
class example {
private:
int counter;
protected:
void add_substract(int);
public:
void decrease(void);
void increase(void);
};

Řízení přístupu
ˇ Jedna z nejdůležitějších komponent bezpečnosti jakéhokoliv
systému
ˇ Bohužel ne vždy je kód řízení přístupu (referenční monitor)
bezchybný. (typicky nedostatečná kontrola nedůvěryhodného
vstupu a následný ,,buffer overflow")
ˇ Příliš mnoho kódu operačního systému je označeno za
důvěryhodný (jádro obsahuje ovladače nejrůznějších zařízení
napsaných programátory řady firem/organizací)
ˇ ,,Race condition" ­ operace ověření přístupových práv a použití
práv není atomická (zneužitelné u programů s většími právy ­
SUID/SGID programy, webové CGI aplikace)
ˇ Trojští koně

Řízení přístupu
ˇ Separace oprávnění ­ pro vykonání určité akce je potřebný
souhlas několika osob (např. velkou bankovní transakci musí
podepsat dva bankovní úředníci)
Řízení přístupu na úrovni OS (často ani middleware) toto nepodporuje
Nutná podpora přímo v aplikačním SW
ˇ Princip nejmenších privilegií ­ uživatel má právo přístupu jen
k takovým objektům, ke kterým z titulu svého pracovního
zařazení přístup potřebuje. Počátečně je množina oprávnění malá
a postupně se rozrůstá. Žádný uživatel nemá přístup k objektům,
ke kterým přístup nepotřebuje.

Otázky?
Příští přednáška 15. 12. 2004 v 18:00
matyas@fi.muni.cz
zriha@fi.muni.cz