bit/pB-trust.d
15. kveˇtna 2003
Rootkity ........ * rootkit je balı ´c ˇek programu ˚, ktery ´ dovoluje ´ utoc ˇnı ´kovi skry ´t sve ´ aktivity v syste ´mu, pr ˇistupovat k ne ˇmu podle potr ˇeby apod. - ve ve ˇts ˇine ˇ pr ˇı ´padu ˚ ´ utoc ˇnı ´k po napadenı ´ syste ´mu nainstaluje rootkit - obsahuje ru ˚zne ´ programy pouz ˇı ´vajı ´cı ´ jiz ˇ uvedene ´ koncepce (trojsky ´ ku ˚n ˇ, zadnı ´ vra ´tka apod.) - instaluje do adresa ´r ˇe, ktery ´ pravde ˇpodobne ˇ nebudete prohleda ´vat, napr ˇ. ”...”, ”.. ”, /usr/lib/libsof apod. * rootkity obvykle obsahujı ´: - program /bin/login se zadnı ´mi vra ´tky, ktery ´ ´ utoc ˇnı ´kovi dovolı ´ pozde ˇjs ˇı ´ pr ˇihla ´s ˇenı ´ jako root - program pro odposlech paketu ˚ a program pro zamaskova ´nı ´ odposlechu paketu ˚ - programy pro zamaskova ´nı ´ souboru ˚ a procesu ˚ ´ utoc ˇnı ´ka * program pro odposlech paketu ˚ a program pro zamaskova ´nı ´ odposlechu paketu ˚ - pr ˇi odposlechu paketu ˚ je rozhranı ´ pr ˇepnuto do promiskuitnı ´ho rez ˇimu - mu ˚ˇ zeme detekovat pomocı ´ /sbin/ifconfig (vypı ´s ˇe pr ˇı ´znak PROMISC) - proto v rootkitu fales ˇna ´ verze programu ifconfig, ktera ´ pr ˇı ´znak PROMISC nezobrazuje * v rootkitech pro UNIXove ´ syste ´my jsou nove ´ verze programu ˚ ps, ls, netstat - ps - vypisuje procesy, verze z rootkitu nevypisuje procesy ´ utoc ˇnı ´ka - ls - vypisuje obsah adresa ´r ˇe, verze z rootkitu nezobrazuje soubory rootkitu - netstat - informace o sı ´t’ove ´m rozhranı ´, skry ´va ´ aktivity ´ utoc ˇnı ´ka, tj. jeho privilegovane ´ procesy poslouchajı ´cı ´ na portu apod. * obrana: - kontrola integrity kriticky ´ch programu ˚ (login, ps, ls, du, netstat, ...) + knihoven (libc.so.6) . napr ˇ. tripwire - generuje jednosme ˇrny ´ hash spustitelny ´ch souboru ˚ . administra ´tor mu ˚z ˇe uchovat na read-only me ´diu (CD ROM, R/O disketa) a periodicky kontrolovat . pokud je detekova ´n rootkit, nejbezpec ˇne ˇjs ˇı ´ je nainstalovat OS (+ pr ˇı ´padne ´ kriticke ´ aplikace) znovu z c ˇiste ´ho zdroje * poslednı ´ vy ´voj - rootkity na ´ urovni ja ´dra - vyuz ˇı ´vajı ´ mechanismus za be ˇhu zaveditelny ´ch modulu ˚ (Linux, Solaris) => nenı ´ zapotr ˇebı ´ restart syste ´mu - nejoblı ´bene ˇjs ˇı ´ vlastnosti: . pr ˇemapova ´nı ´ poz ˇadavku ˚ na spus ˇte ˇnı ´ programu - mı ´sto poz ˇadovane ´ho programu spustı ´ program z rootkitu => nepomu ˚z ˇe kontrola integrity pu ˚ vodnı ´ho programu . skry ´va ´nı ´ souboru ˚ - ´ utoc ˇnı ´k si mu ˚z ˇe zvolit, ktery ´ soubor v syste ´mu nebude pro uz ˇivatele ja ´dra existovat . skry ´va ´nı ´ procesu ˚ - podobne ˇ jako vy ´s ˇe * obrana proti rootkitu ˚m na ´ urovni ja ´dra - c ˇa ´stec ˇna ´ obrana: na kriticky ´ch strojı ´ch zaka ´zat moduly zaveditelne ´ za be ˇhu Vs ˇeobecna ´ obrana ................ * nejdu ˚lez ˇite ˇjs ˇı ´ z popsany ´ch strategiı ´ - neprovozovat zbytec ˇne ´ syste ´my a sluz ˇby - sledovat a instalovat opravy SW od vy ´robcu ˚ * krome ˇ dr ˇı ´ve popsany ´ch konkre ´tnı ´ch strategiı ´ obrany musı ´ by ´t organizace schopna detekovat napadenı ´ svy ´ch syste ´mu ˚ a reagovat na ne ˇj * c ˇasto se pouz ˇı ´vajı ´ syste ´my pro detekci napadenı ´ (intrusion detection systems, IDS) - obsahujı ´ databa ´zi pr ˇı ´znaku ˚ napadenı ´, porovna ´vajı ´ s nı ´ provoz na sı ´ti - umoz ˇn ˇuje detekovat ´ utok v poc ˇa ´tec ˇnı ´m sta ´diu * jes ˇte ˇ du ˚lez ˇite ˇjs ˇı ´ - definovat a popsat reakci organizace na ´ utok
1
15. kveˇtna 2003
2 - pokud se - proto by sekvenci - pokud je
reaguje az ˇ ve chvı ´li krize, budou zodpove ˇdne ´ osoby de ˇlat chyby me ˇl existovat dokument popisujı ´cı ´ roli jednotlivy ´ch osob a akcı ´ (sekvence pr ˇı ´kazu ˚, pr ˇı ´padna ´ komunikace s policiı ´ apod.) bezpec ˇnost kriticka ´, doporuc ˇuje se konat pravidelna ´ cvic ˇenı ´
* penetrac ˇnı ´ testova ´nı ´ = urc ˇenı ´ schopnosti subjektu odola ´vat ´ utoku ˚m - tester pouz ˇı ´va ´ stejne ´ triky a techniky jako rea ´lny ´ ´ utoc ˇnı ´k - dovoluje najı ´t slaba ´ mı ´sta dr ˇı ´ve, nez ˇ je najde ´ utoc ˇnı ´k * obvykle ´ jsou na ´sledujı ´cı ´ typy testu ˚: - testy fyzicke ´ infrastruktury subjektu . je moz ˇne ´ se dostat nekontrolovane ˇ do budovy? (test: pokus dostat se do budovy v dobe ˇ, kdy zame ˇstnanci pr ˇicha ´zejı ´ do pra ´ce) . jsou citlive ´ c ˇa ´sti budovy uzamc ˇeny nebo majı ´ jinou fyzickou barie ´ru? . je moz ˇne ´ budovu nekontrolovane ˇ opustit? (test: pokus prone ´st laptop apod.) - testy operac ˇnı ´ch aspektu ˚ organizace . jaka ´ jsou pravidla pro zme ˇnu hesla apod., lze obsluhu pr ˇesve ˇdc ˇit bez du ˚ kazu identity, aby vytvor ˇila ´ uc ˇet, zme ˇnila heslo nebo pr ˇı ´stupova ´ pra ´va? . existujı ´ pravidla jak zacha ´zet s vyr ˇazovany ´mi datovy ´mi nosic ˇi nebo s disky v poc ˇı ´tac ˇı ´ch pr ˇeda ´vany ´ch do opravy (napr ˇ. rus ˇenı ´ dat) a jsou dodrz ˇova ´na? jake ´ citlive ´ informace lze na nich nale ´zt? - elektronicke ´ testy - pouz ˇitı ´ uz ˇ zmı ´ne ˇny ´ch na ´stroju ˚ * mnoz ˇstvı ´ lidı ´ kter ˇı ´ o testu ve ˇdı ´ by me ˇlo by ´t minimalizova ´no (du ˚lez ˇite ´ je aby test schva ´lilo vedenı ´!)
Viry a c ˇervi ============ * viry = programy, ktere ´ se reprodukujı ´ pr ˇipojenı ´m sve ´ho ko ´du k jine ´mu programu; virus je aktivova ´n spus ˇte ˇnı ´m nakaz ˇene ´ho programu * c ˇervi = programy, ktere ´ se samy replikujı ´ a s ˇı ´r ˇı ´ (tj. nepotr ˇebujı ´, aby uz ˇivatel program spustil) * oba typy mohou vykona ´vat i jinou c ˇinnost nez ˇ se jen s ˇı ´r ˇit: - nes ˇkodne ´ c ˇinnosti (vypsat zpra ´vu apod.) - pos ˇkodit uz ˇivatele . pos ˇkodit nebo zrus ˇit soubory, zaslat soubory ne ˇkam, zas ˇifrovat apod. . zpu ˚sobit nepouz ˇitelnost poc ˇı ´tac ˇe (DoS, napr ˇ. v UNIXu: while (1) fork();) . permanentne ˇ pos ˇkodit HW (napr ˇ. flash ROM) - v mnoha pr ˇı ´padech nede ˇla ´ nic pozorovatelne ´ho do urc ˇite ´ho data * autor ˇi viru ˚ i c ˇervu ˚ ve ˇts ˇinou str ˇedos ˇkola ´ci nebo vysokos ˇkola ´ci, kter ˇı ´ jejich napsa ´nı ´ povaz ˇujı ´ za ”zajı ´mavou ve ˇc, na ktere ´ se ne ˇco nauc ˇı ´” (ve ˇts ˇinou si neuve ˇdomujı ´ (nebo je nezajı ´ma ´) jake ´ tı ´m mohou v sume ˇ napa ´chat s ˇkody) Viry ---[ bylo uvedeno v refera ´tu ] MS pla ´nuje ”code signing”: - ko ´d s digita ´lnı ´m podpisem, vytvor ˇit umı ´ pouze ”certifikovane ´ entity”, ove ˇr ˇit umı ´ kdokoli - sdruz ˇenı ´ jme ´na autora (firmy) s ko ´dem, nenı ´ moz ˇna ´ zme ˇna ko ´du aniz ˇ by ”podpis” pr ˇestal platit - volba OS ”accept only signed code” Pro male ´ vy ´voja ´r ˇe a individua je vyda ´va ´nı ´ digita ´lnı ´ch certifika ´tu ˚ obtı ´z ˇne ´ a drahe ´ (nutno ove ˇr ˇit skutec ˇnou identitu) => je draz ˇs ˇı ´ nez ˇ pro velke ´ firmy => moz ˇne ´ vylouc ˇenı ´ konkurence ze hry? * ve vı ´ceuz ˇivatelsky ´ch OS jsou adresa ´r ˇe obsahujı ´cı ´ spustitelne ´ programy nepr ˇı ´stupne ´ pro za ´pis => viry obvykle nejsou proble ´m ˇervi C ----* c ˇerv = program, ktery ´ se s ˇı ´r ˇı ´ prostr ˇednictvı ´m poc ˇı ´tac ˇove ´ sı ´te ˇ neza ´visle na
bit/pB-trust.d
bit/pB-trust.d
15. kveˇtna 2003
c ˇinnosti uz ˇivatele - obvykle vyuz ˇı ´va ´ slaba ´ mı ´sta v be ˇz ˇne ´m SW, z napadene ´ho poc ˇı ´tac ˇe se s ˇı ´r ˇı ´ da ´le - ne ˇktere ´ dnes ˇnı ´ viry pouz ˇı ´vajı ´ kombinaci technik viru ˚ a c ˇervu ˚ Internet Worm ............. * asi nejzna ´me ˇjs ˇı ´ bezpec ˇnostnı ´ incident - Internet Worm (1988) * Robert Morris nas ˇel 2 chyby v BSD UNIXu, ktere ´ umoz ˇn ˇovaly neautorizovany ´ pr ˇı ´stup na stroje v Internetu - napsal samoreplikujı ´cı ´ se program, ktery ´ chyby vyuz ˇı ´val - na programu pracoval ne ˇkolik me ˇsı ´cu ˚, uvolnil 2. listopadu 1988 - be ˇhem ne ˇkolika hodin od uvolne ˇnı ´ vyr ˇadilo z provozu ve ˇts ˇinu stroju ˚ Sun a VAX pr ˇipojeny ´ch na Internet - Morrisova motivace nenı ´ zna ´ma, pravde ˇpodobne ˇ vtip ktery ´ se vymknul z rukou autora * c ˇerv se skla ´dal ze 2 programu ˚ - zavade ˇc ˇe a vlastnı ´ho c ˇerva - zavade ˇc ˇ - program l1.c (99 r ˇa ´dku ˚ v C), na napadene ´m syste ´mu se pr ˇeloz ˇil a spustil, spojil se se strojem odkud byl zasla ´n, pr ˇec ˇetl a spustil vlastnı ´ho c ˇerva - c ˇerv prohle ´dl sme ˇrovacı ´ tabulky, nas ˇel a napadl dals ˇı ´ stroj - pro napadenı ´ dals ˇı ´ch stroju ˚ 3 metody: . zkusit rsh na jiny ´ stroj . daemon fingerd pouz ˇı ´val pro c ˇtenı ´ poz ˇadavku fci gets(), poslat specia ´lne ˇ vytvor ˇeny ´ 536 bytovy ´ r ˇete ˇzec ktery ´ pr ˇepsal za ´sobnı ´k - na ´vrat do procedury v r ˇete ˇzci, ktera ´ spustila /bin/sh . chyba v pos ˇtovnı ´m programu sendmail, ktera ´ dovolovala poslat a spustit kopii zavade ˇc ˇe - v napadene ´m syste ´mu se pokusil rozlus ˇtit hesla (v /etc/passwd) - moz ˇnost pr ˇihla ´sit se vs ˇude, kde me ˇl uz ˇivatel stejne ´ heslo - pokud na dane ´m stroji c ˇerv jiz ˇ be ˇz ˇel, nova ´ kopie skonc ˇila v 6 pr ˇı ´padech ze 7, ale to zpu ˚sobilo pr ˇı ´lis ˇ mnoho be ˇz ˇı ´cı ´ch c ˇervu ˚ => DoS * Morris byl odsouzen, 10 000$ pokuty, 3 leta ´ podmı ´nka + 400 hodin ver ˇejne ´ sluz ˇby - pozitivnı ´ efekt - vytvor ˇenı ´ CERT (Computer Emergency Response Team) sbı ´ra ´ informace o proble ´mech OS a o zpu ˚sobu opravy, v pr ˇı ´pade ˇ potr ˇeby zver ˇejn ˇuje Dals ˇı ´ vy ´voj ........... * souc ˇasnı ´ c ˇervi napr ˇ. Ramen, L10n, Cheese, Code Red, Nimda * rychle se s ˇı ´r ˇı ´cı ´ c ˇervi - poslednı ´ c ˇervi byli zatı ´m pome ˇrne ˇ neefektivnı ´, protoz ˇe prostor IP adres prohleda ´valy na ´hodne ˇ - v reakci na to se objevily c ˇla ´nky popisujı ´cı ´ efektivne ˇjs ˇı ´ techniky pr ˇedprohleda ´nı ´ Internetu na napadnutelne ´ syste ´my atd. - umoz ˇnilo by do 1 hod napadnout 99% napadnutelny ´ch syste ´mu ˚ - zatı ´m nas ˇte ˇstı ´ nebylo realizova ´no * vı ´ceplatformovı ´ c ˇervi - ve ˇts ˇina c ˇervu ˚ zatı ´m napada ´ jeden typ syste ´mu, pr ˇedevs ˇı ´m Windows nebo Linux - lze oc ˇeka ´vat, z ˇe budoucı ´ c ˇervi budou napadat vı ´ce typu ˚ OS * morfujı ´cı ´ a maskujı ´cı ´ se c ˇervi - dosavadnı ´ viry bylo moz ˇno relativne ˇ snadno detekovat - lze oc ˇeka ´vat polymorfnı ´ c ˇervy, jejichz ˇ ko ´d se bude me ˇnit s kaz ˇdy ´m napadenı ´m syste ´mu * destruktivnı ´ c ˇervi - dosavadnı ´ c ˇervi nenesli destruktivnı ´ ko ´d, coz ˇ se mu ˚z ˇe zme ˇnit * obrana proti c ˇervu ˚m - vc ˇasna ´ instalace bezpec ˇnostnı ´ch oprav OS a dals ˇı ´ch programu ˚ - pokud je to moz ˇne ´, za ´sobnı ´k by neme ˇl by ´t spustitelny ´ (alespon ˇ pro aplikace, ktere ´ majı ´ fci serveru) - blokovat nepotr ˇebna ´ vy ´stupnı ´ spojenı ´ (aby se c ˇerv nemohl da ´le s ˇı ´r ˇit) - mı ´t vypracova ´n pla ´n odpove ˇdi na incident
3
15. kveˇtna 2003
4
bit/pB-trust.d
Du ˚ ve ˇryhodne ´ syste ´my =================== * ve ˇts ˇina poslednı ´ch pr ˇedna ´s ˇek popisovala, z ˇe te ´me ˇr ˇ vs ˇechny modernı ´ OS nejsou bezpec ˇne ´ (”they leak like a sieve”) * v souvislosti s tı ´m bychom se mohli pta ´t: 1. Je moz ˇne ´ vytvor ˇit bezpec ˇny ´ poc ˇı ´tac ˇovy ´ syste ´m? 2. Pokud ano, proc ˇ se to nede ˇla ´? * odpove ˇd’ na (1) je v za ´sade ˇ ano, za ´kladnı ´ za ´sady jsou dlouho zna ´my, napr ˇ. MULTICS je pr ˇı ´klad OS vytvor ˇene ´ho s cı ´lem bezpec ˇne ´ho syste ´mu, celkem se povedlo - mechanismus musı ´ by ´t nejniz ˇs ˇı ´ch vrstva ´ch OS, musı ´ by ´t dostatec ˇne ˇ jednoduchy ´ a nesmı ´ by ´t obcha ´zen * proc ˇ (2), tj. proc ˇ nejsou bezpec ˇne ´ ma ´ v za ´sade ˇ dve ˇ pr ˇı ´c ˇiny: - souc ˇasne ´ syste ´my nejsou bezpec ˇne ´, ale ve ˇts ˇine ˇ uz ˇivatelu ˚ ”stac ˇı ´” - bezpec ˇny ´ OS musı ´ by ´t jednoduchy ´, ale uz ˇivatele ´ poz ˇadujı ´ funkc ˇnost => vı ´ce ko ´du => vı ´ce chyb => vı ´ce bezpec ˇnostnı ´ch chyb . napr ˇı ´klad prvnı ´ e-mailove ´ syste ´my posı ´laly pouze textove ´ zpra ´vy, byly zcela bezpec ˇne ´ . pozde ˇji jine ´ typy dokumentu ˚ => napr ˇ. dokumenty ve Wordu, mohou obsahovat makra = na poc ˇı ´tac ˇi spous ˇtı ´te cizı ´ ko ´d . jiny ´ pr ˇı ´klad: dr ˇı ´ve se web skla ´dal z pasivnı ´ch WWW stra ´nek, dnes pro prohlı ´z ˇenı ´ stra ´nek c ˇasto nutne ´ spous ˇte ˇt applety TCB ... * pro ne ˇktere ´ organizace je bezpec ˇnost prima ´rnı ´, podı ´va ´me se na ne ˇktere ´ modely - mı ´sto ”bezpec ˇne ´ syste ´my” se v oblasti bezpec ˇnosti OS mluvı ´ o ”du ˚ ve ˇryhodny ´ch syste ´mech” - za ´kladem kaz ˇde ´ho du ˚ve ˇryhodne ´ho syste ´mu je HW a SW potr ˇebny ´ nebo ovlivn ˇujı ´cı ´ vynucova ´nı ´ bezpec ˇnostnı ´ch pravidel, ktery ´ se nazy ´va ´ TCB (Trusted Computing Base) - TCB typicky zahrnuje ve ˇts ˇinu HW (krome ˇ I/O zar ˇı ´zenı ´ neovlivn ˇujı ´cı ´ch bezpec ˇnost), c ˇa ´st ja ´dra (vytva ´r ˇenı ´ procesu ˚, pr ˇepı ´na ´nı ´ mezi procesy, spra ´va mapy pame ˇti, c ˇa ´st spra ´vy I/O), ve ˇts ˇinu programu ˚ s pr ˇı ´stupovy ´mi pra ´vy administra ´tora - v du ˚ve ˇryhodny ´ch syste ´mech je c ˇasto TCB odde ˇlena od zbytku OS z du ˚vodu minimalizace jejı ´ velikosti a ove ˇr ˇenı ´ spra ´vnosti * du ˚ lez ˇitou c ˇa ´stı ´ TCB je monitor odkazu ˚ (reference monitor) - rozhoduje o vs ˇech poz ˇadavcı ´ch ty ´kajı ´cı ´ch se bezpec ˇnosti (napr ˇ. otevr ˇenı ´ souboru) zda mohou by ´t vykona ´ny - dovoluje, aby se vs ˇechna rozhodnutı ´ de ˇla na jednom mı ´ste ˇ bez moz ˇnosti je obejı ´t - ve ˇts ˇina OS nenı ´ navrz ˇena tı ´mto zpu ˚sobem = jeden z du ˚vodu ˚ proc ˇ nejsou bezpec ˇne ´
User process User space All system calls go through the reference monitor for security checking Reference monitor Trusted computing base Operating system kernel
Kernel space
bit/pB-trust.d
15. kveˇtna 2003
5
Matice ochrany .............. * v OS objekty, ktere ´ je tr ˇeba chra ´nit pr ˇed neopra ´vne ˇny ´m pr ˇı ´stupem (soubory, procesy, semafory, segmenty pame ˇti, I/O zar ˇı ´zenı ´) - kaz ˇdy ´ objekt ma ´ jedinec ˇne ´ jme ´no ktery ´m je odkazova ´n a konec ˇnou mnoz ˇinu operacı ´, ktere ´ je nad nı ´m moz ˇno prove ´st - procesy v kaz ˇde ´m c ˇasove ´m okamz ˇiku be ˇz ˇı ´ v ne ˇktere ´ dome ´ne ˇ . dome ´na obvykle odpovı ´da ´ jednomu uz ˇivateli . dome ´na urc ˇuje podmnoz ˇinu operacı ´, ktere ´ je moz ˇne ´ vykonat nad objektem . povolene ´ podmnoz ˇine ˇ operacı ´ r ˇı ´ka ´me ”pr ˇı ´stupova ´ pra ´va” - napr ˇı ´klad v syste ´mu UNIX jsou pr ˇı ´stupova ´ pra ´va k souboru ˚m podmnoz ˇinou { Read, Write, eXecute }, dome ´na je urc ˇena UID a GID procesu * popis mechanismu ˚ ochrany se zava ´dı ´ pojem matice ochrany - r ˇa ´dky = dome ´ny - sloupce = objekty - aby bylo moz ˇne ´ pr ˇepı ´nat mezi dome ´nami (napr ˇ. me ˇnit UID a GID), jsou dome ´ny v matici ochrany uvedeny take ´ Object File1
File2
Read
Read Write
File3
File4
File5
File6
Printer1 Plotter2 Domain1 Domain2 Domain3
Domain 1
Enter
Read
2
Read Write Execute
Read Write
Write Read Write Execute
3
Write
Write
- ve skutec ˇnosti nenı ´ implementova ´no jako matice, nejc ˇaste ˇji implementova ´no jako ACL: . s kaz ˇdy ´m objektem OS sdruz ˇeno ACL, v ne ˇm seznam dvojic (dome ´na, pr ˇı ´stupova ´ pra ´va) . dome ´na napr ˇ. UID a GID, pr ˇı ´stupova ´ pra ´va - bitove ´ pole, 0=odepr ˇeno, 1=povoleno . pr ˇı ´klad ACL v UNIXu: objekt ACL -----------------------------prednaska.txt luki, staff: RW*, staff: R-*, students: R-/etc/passwd
root, root: *, *:
RWR--
Forma ´lnı ´ modely du ˚ve ˇryhodny ´ch syste ´mu ˚ ..................................... * matice ochrany nejsou staticke ´, obvykle se me ˇnı ´ pr ˇi vytva ´r ˇenı ´ novy ´ch objektu ˚ - nad maticı ´ ochrany 6 primitivnı ´ch operacı ´ nad maticı ´ ochrany, ktery ´mi lze modelovat jaky ´koli syste ´m: create object, delete object, create domain, delete domain, insert right, remove right (Harrison et. al. 1976) - tato primitiva mohou by ´t souc ˇa ´stı ´ sluz ˇeb OS (”pr ˇı ´kazu ˚”), ktere ´ mohou vyvola ´vat uz ˇivatelske ´ programy . napr ˇ. vytvor ˇenı ´ nove ´ho souboru: vytvor ˇenı ´ objektu souboru, do matice ochrany vloz ˇenı ´ pr ˇı ´stupovy ´ch pra ´v k souboru . nebo pr ˇı ´kaz pro pr ˇida ´nı ´ pr ˇı ´stupovy ´ch pra ´v pro c ˇtenı ´ pro kohokoli v syste ´mu * autorizovane ´ a neautorizovane ´ stavy matice ochrany - matice ochrany urc ˇuje, jake ´ operace proces v dane ´ dome ´ne ˇ mu ˚z ˇe vykonat - co se stane, pokud se ne ˇkomu podar ˇı ´ vykonat sekvenci pr ˇı ´kazu ˚, ktery ´mi dojde ke zme ˇne ˇ matice ochrany? - je zr ˇejme ´, z ˇe mnoz ˇina vs ˇech moz ˇny ´ch matic mu ˚z ˇe by ´t rozde ˇlena do dvou podmnoz ˇin: mnoz ˇina autorizovany ´ch stavu ˚ , mnoz ˇina neautorizovany ´ch stavu ˚
15. kveˇtna 2003
6
- ota ´zka velke ´ c ˇa ´sti vy ´zkumu: ma ´me-li poc ˇa ´tec ˇnı ´ autorizovany ´ stav a mnoz ˇinu pr ˇ´ ıkazu ˚, mu ˚z ˇeme doka ´zat z ˇe se syste ´m nikdy nedostane do neautorizovane ´ho stavu? - obecne ˇ obtı ´z ˇne ´ (pro ne ˇktere ´ syste ´my nerozhodnutelne ´), pro konkre ´tnı ´ syste ´my je moz ˇne ´ doka ´zat * ve ˇts ˇina OS dovoluje uz ˇivatelu ˚m urc ˇit kdo mu ˚z ˇe c ˇı ´st a modifikovat jejich soubory a dals ˇı ´ objekty * v ne ˇktery ´ch prostr ˇedı ´ch je tr ˇeba pr ˇı ´sne ˇjs ˇı ´ bezpec ˇnost (vojenstvı ´, firemnı ´ vy ´zkum, nemocnice, banky) - organizace stanovı ´ pravidla, kdo co mu ˚z ˇe vide ˇt - pravidla nemohou by ´t jednotlivy ´mi voja ´ky nebo le ´kar ˇi atd. porus ˇena - na ´zev vı ´cestupn ˇove ´ modely bezpec ˇnosti (multilevel security models) * model Bell-La Padula (Bell & La Padula 1973) - pu ˚ vodne ˇ navrz ˇen pro vojenske ´ ´ uc ˇely - kaz ˇdy ´ dokument ma ´ pr ˇir ˇazen stupen ˇ utajenı ´ (du ˚ve ˇrne ´, tajne ´, pr ˇı ´sne ˇ tajne ´) - lide ´ majı ´ take ´ pr ˇir ˇazeny stupne ˇ podle typu dokumentu ˚, ktere ´ mohou vide ˇt (napr ˇ. genera ´l mu ˚z ˇe vide ˇt vs ˇechny dokumenty, du ˚stojnı ´k pouze du ˚ve ˇrne ´ apod.) - procesy majı ´ stupen ˇ podle uz ˇivatelu ˚ ktery ´m patr ˇı ´ - model podle Bella a La Paduly ma ´ na ´sledujı ´cı ´ pravidla: . proces be ˇz ˇı ´cı ´ na stupni K mu ˚z ˇe c ˇı ´st pouze objekty na sve ´m a niz ˇs ˇı ´ch stupnı ´ch . proces be ˇz ˇı ´cı ´ na stupni K mu ˚z ˇe zapisovat pouze objekty na na sve ´m a vys ˇs ˇı ´ch stupnı ´ch (du ˚stojnı ´k mu ˚z ˇe prozradit genera ´lovi vs ˇe co vı ´, ale genera ´l nemu ˚z ˇe prozradit du ˚stojnı ´kovi vs ˇe co vı ´) * proble ´m s modelem: hlavnı ´ za ´me ˇr je, aby syste ´m uchoval tajemstvı ´ - je zr ˇejme ´, z ˇe v mnoha prakticky ´ch pr ˇı ´padech podstatne ´ dals ˇı ´ vlastnosti => existujı ´ dals ˇı ´ modely ”Oranz ˇova ´ kniha” ================ * National Computer Security Center (souc ˇa ´st NSA) - definovalo krite ´ria pro tr ˇı ´dy bezpec ˇnosti OS (1983 ”Trusted Computer System Evaluation Criteria” = TCSEC, nazy ´va ´no te ´z ˇ ”the Orange Book”) - certifikovala se ´ uplna ´ konfigurace vc ˇetne ˇ HW - nahrazeno jiny ´mi standardy, ale sta ´le uz ˇitec ˇne ´ pro za ´kladnı ´ rozlis ˇenı ´ * Orange Book rozde ˇluje syste ´my do sedmi kategoriı ´ podle poskytovane ´ kontroly: - ´ uroven ˇ D: nejsou z ˇa ´dne ´ poz ˇadavky na bezpec ˇnost, nejsna ´ze dosaz ˇitelne ´ (MS DOS, Windows 95/98/Me) - ´ uroven ˇ C pro prostr ˇedı ´ s navza ´jem spolupracujı ´cı ´mi uz ˇivateli . C1 - OS v chra ´nene ´m rez ˇimu, autentizovane ´ pr ˇihlas ˇova ´nı ´, moz ˇnost aby uz ˇivatele ´ specifikovali ktere ´ soubory (zdroje) budou zpr ˇı ´stupne ˇny ostatnı ´m uz ˇivatelu ˚m a jak (discretionary access control), poz ˇadavek minima ´lnı ´ho testova ´nı ´ a dokumentace (napr ˇ. UNIX) . C2 - pr ˇida ´va ´ poz ˇadavek ochrany pr ˇı ´stupu na ´ urovni jednotlivy ´ch uz ˇivatelu ˚, ochrana pr ˇi znovupouz ˇitı ´ objektu - uz ˇivatel nesmı ´ mı ´t moz ˇnost vide ˇt data objektu, ktery ´ jiny ´ uz ˇivatel uvolnil (zrus ˇil soubor, uvolnil pame ˇt’; vs ˇechny objekty jsou inicializova ´ny pr ˇed alokacı ´ uz ˇivateli), bezpec ˇnostnı ´ audit - syste ´m musı ´ detekovat a zaznamena ´vat pokusy o vytvor ˇenı ´, pr ˇı ´stup, zrus ˇenı ´ zdroje; musı ´ by ´t moz ˇne ´ zjistit, kdo se pokusil o neautorizovanou akci - B a A - uz ˇivatelu ˚m a objektu ˚m jsou pr ˇir ˇazena bezpec ˇnostnı ´ na ´ve ˇs ˇtı ´ (napr ˇ. ”neklasifikova ´no”, ”tajne ´”, ”pr ˇı ´sne ˇ tajne ´”), syste ´m musı ´ ume ˇt model Bell-La Pandula . B1 = Labeled Security Protection, viz vy ´s ˇe . B2 - syste ´m musel by ´t navrz ˇen shora dolu ˚ modula ´rnı ´m zpu ˚sobem, na ´vrh musı ´ by ´t prezentova ´n tak aby ho bylo moz ˇno ove ˇr ˇit, analy ´za moz ˇny ´ch covert channels . B3 = B2 + ACL + bezpec ˇnostnı ´ dome ´ny + forma ´lnı ´ TCB + bezpec ˇne ´ zotavenı ´ po hava ´rii - A1 - forma ´lnı ´ model + du ˚kaz jeho spra ´vnosti + demonstrace, z ˇe syste ´m odpovı ´da ´ modelu + forma ´lnı ´ analy ´za covert channels * cı ´lem je, aby jeden proces nemohl druhe ´mu pr ˇeda ´vat informace ner ˇı ´zeny ´m
bit/pB-trust.d
bit/pB-trust.d
15. kveˇtna 2003
7
zpu ˚sobem - pomocı ´ matice ochrany mu ˚z ˇeme zajistit, aby nemohly komunikovat mechanismem za ´pis/c ˇtenı ´ apod. - covert channel napr ˇ. bit 1 = server zate ˇz ˇuje CPU, bit 0 = nezate ˇz ˇuje CPU - cı ´lovy ´ proces mu ˚z ˇe me ˇr ˇit c ˇas odpove ˇdi syste ´mu, pr ˇı ´padny ´ s ˇum mu ˚z ˇe by ´t eliminova ´n pomocı ´ samoopravny ´ch ko ´du ˚ - hleda ´nı ´ covert channels je znac ˇne ˇ obtı ´z ˇne ´ * TCSEC bylo nejzna ´me ˇjs ˇı ´, ale dnes povaz ˇova ´no za zastarale ´ * na ´sledovnı ´k 1996 ”Common Criteria for Information Technology Security Evaluation” (CCITSE; US, GB, Ne ˇmecko, Francie, Kanada, Holandsko) * http://www.radium.ncsc.mil/tpep/library/ccitse * obvykle nazy ´va ´no Common Criteria (CC), zac ˇı ´na ´ by ´t uzna ´va ´no * nove ´ syste ´my (Windows XP apod.) budou ove ˇr ˇova ´ny uz ˇ pomocı ´ CC * ove ˇr ˇova ´nı ´ trva ´ ne ˇkolik let, bude jes ˇte ˇ trvat * nenı ´ a nebude pravda ”Windows 2000 supports C2-level security” (neplatı ´ bez uvedenı ´ konfigurace, NCSC uz ˇ neove ˇr ˇuje oproti TCSEC)
Criterion Security policy Discretionary access control Object reuse Labels Label integrity Exportation of labeled information Labeling human readable output Mandatory access control Subject sensitivity labels Device labels
D
C1
C2
X
X X
B1
B2
B3
→ → X X X X X
→ → X → → → X X X
X → → → → → → → →
A1
→ → → → → → → → →
Accountability Identification and authentication Audit Trusted path
X
X X
X X
→ X X
→ X X
→ → →
Assurance System architecture System integrity Security testing Design specification and verification Covert channel analysis Trusted facility management Configuration management Trusted recovery Trusted distribution
X X X
X → X
X → X X
X → X X X X X
X → X X X X → X
→ → X X X → X → X
Documentation Security features user’s guide X → → → → → X X X X X → Trusted facility manual X → → X → X Test documentation Design documentation X → X X X X
* v tabulce jsou uvedeny ´ urovne ˇ bezpec ˇnosti podle Orange Book: - X = novy ´ poz ˇadavek pro danou ´ uroven ˇ - -> = poz ˇadavek z niz ˇs ˇı ´ kategorie Pozna ´mka (reakce na dotaz)
15. kveˇtna 2003
8
bit/pB-trust.d
V syste ´mech typu UNIX pouz ˇı ´vajı ´ aplikace pro logova ´nı ´ knihovnı ´ fce openlog(), syslog() a closelog(); tyto fce komunikujı ´ s daemonem syslogd(8), ktery ´ se r ˇı ´dı ´ konfigurac ˇnı ´m souborem /etc/syslog.conf. V konfigurac ˇnı ´m souboru je uvedeno, jak naloz ˇit s jednotlivy ´mi poz ˇadavky podle sluz ˇby a priority poz ˇadavku (sluz ˇba je napr ˇ. cron, mail, security, daemon; priorita mu ˚z ˇe by ´t napr ˇ. warning, err, emerg). Program mu ˚z ˇe za ´znamy zapisovat do souboru (napr ˇ. /var/log/auth.log), na termina ´l, pr ˇı ´padne ˇ posı ´lat na jiny ´ stroj. []
❉
