Vlákno názorů k článku
Proč byste měli chtít SELinux?

Mně to přijde nějaký divný.

Dejme tomu, že někdo nalezne bezpečnostní bugu v sshd serveru a SELinux mu zabrání, aby hrabal na soubory na počítači. Ale on stále může posílat libovolné stisky kláves na uživatelské terminály, takže přes to stejně získá práva jakéhokoli uživatele, co se naloguje.

Nebo někdo nalezne bugu v web serveru, SELinux mu sice zabrání hrabat kam nemá, ale útočník může klidně web server upravit tak, že bude místo běžného obsahu distribuovat trojské koně.

Nebo někdo nalezne bugu v nějakém klikacím Xwindow programu a ten program bude mít v pravidlech, že smí komunikovat s Xserverem --- jenomže pak může útočník přes Xserver ovlivňovat jakýkoli jiný program, co je ke Xserveru též připojený (měnit mu všechny Xwindow properties).

To by mě zajímalo, zda to opravdu může útoky nějak omezit (jde nějak prokázat, jakou nejhorší škodu může kompromitace té které služby napáchat?), nebo zda to pouze znefunkční existující rootkity a udělá prostor pro nové, psané s přihlédnutí k politikám SELinuxu.

SELinux tiez neni vseliek. Ale pointa je prave vyrobit dostatocne "fine-grained" pravidla/capabilities, napr. aby po kompromitacii web serveru nemohol pridavat trojske kone na distribuovanie (tj. aby nemohol pridavat subory kam nema a aby nemohol prepisat code segment v pamati apod.).

S tym sshd neviem ako by to vyzeralo, ale SELinux ma nejake role transitions, takze je pravdepodobne, ze po prihlaseni cez sshd prejde user do uplne inej role nez server (ten ktory pocuva) a utocnik by musel napadnut priamo "userov server", v tom pripade zrejme ani SELinux nepomoze (na to by ale na druhej strane musela byt kombinovana chyba v protokole a v binarke, aby dokazal utocnik "rozsifrovat" protokol a hodit na vhodne miesto svoje pakety).

K dokazu: ide dokazat len, ze "utocnik nemoze spravit X a Y". Co moze najhorsie spravit, asi obecne dokazat nejde (halting problem).

Hlavne politiky tiez pisu ludia...ale AFAIK su stylu, co nie je explicitne povolene, je zakazane, tj. chybajuce pravidlo znefunkcni aplikaciu, na druhej samozrejme clovek moze pravidlo napisat chybne.

SELinux/grsecurity maju ale dalsie security featury, napr. nespustitelny zasobnik, address space layout randomization (nahodne vybera namapovanie pamati procesu, vyzaduje position-independent kod), skryvanie mapovania procesov, atd, takze dokopy to uz utocnikovi da celkom solidne zabrat.

jenom technicka: ASLR neni bezpecnostni prvek samo o sobe. Nicmene ve spojeni s IDS je to velmi zajimavy nastroj.

Jasne, ono je to doplnok k nespustitelnemu zasobniku a skryvaniu mapovania procesov, potom ma utocnik tazsie napr. return-to-libc-style utok.

No, asi to není všespasitelné, ale trochu to hází útočníkovi klacky pod nohy, ne? Zrovna sshd je asi průserová záležitost, ale exploit bude se SELinuxem poněkud složitělší (nepůjdou použít jiné porty tcp než 22 apod) a asi bude třeba, aby se útočník dostal dál z domény sshd skutečně odchytat komunikaci s heslama a pak se protlouct dál pomocí simulace přihlášení.
Web server samozřejmě může ukazovat jiný obsah, ale útočník se zase nedostane dál do systému.
Proti kernel level chybám to asi nebude moc platné.
No, je to jenom další překážka útočníkovi, jako třeba chroot no. Mělo by se to zřejmě kombinovat s dalšími ochranami. Určitě bych to nezavrhoval.

Hází mu to klacky pod nohy --- a funguje to právě potud, pokud útočník neví, že je tam SELinux nebo nezná politiku.

Takové bezpečnostní techniky právě fungují pouze do té doby, než se stanou mezi lidmi rozšířenými.

Příklad (což se mi reálně stalo): někdo přes špatně napsaný php skript vlezl na server do uživatele httpd a instaloval tam program, co přes IRC distribuuje warez. Na roota se ten člověk nejspíš ani nesnažil zaútočit.

Pokud tam bude SELinux, tak útočník nemůže spustit podproces --- takže si místo toho ono udělátko na upload warezu přepíše do php. Taktéž nemůže komunikovat přes IRC --- tak místo toho bude ten warez distribuovat přes HTTP. Nemůže warez nahrát kamkoli --- nahraje ho do adresáře, kde si běžně php vytváří dočasné soubory a i ho podobně pojmenuje.

Pokud použiješ SELinux politiku ze svojí distribuce, tak můžeš předpokládat, že útočník si ji taky stáhl a napsal si exploit tak, aby na nic zakázaného nešáhl.

Hahaha, to mě ale pobavilo.

Prý nešáhne na nic zakázaného. Takže vlastně ten server nekompromituje.Ona totiž právě ta cenná bývají chráněná politikou. K tomu ta ochrana je. :-)

Pokud věříš tomu, že když ti útočník neporuší politiku, tak vlastně neudělal nic špatného, tak jseš opravdu na nejlepší cestě ke zkáze.

Webserver má zakázáno číst tajné soubory? Nevadí, má povoleno vysílat libovolné znaky přes HTTP, a tak klidně i může do intranetu vyslat platný .exe, Java nebo ActiveX program, který někdo pustí a onen program přistoupí k datům, ke kterým se webserver přes politiku SELinuxu nemohl dostat. A podobně.

Jediná chybka se vloudila: takový útočník nedostane právo nahrát PHP skript jinam, než do dočasného adresáře, odkud ale nejde spustit.

Nicméně to, co skutečně brání SELinuxu se rozšířit, je příliš složitý systém konfigurace potřebných fine granted permissions. Daleko radši mám OpenVZ (virtualizaci), je to sice o dost méně bezpečné, ale funguje to spolehlivě a daleko snáz se to nastavuje (místo ve dnech v minutách).

php skript se "spouští" obyčejnou funkcí read(), takže kernel z toho read() nepozná, jestli webserver hodlá ten soubor číst jako data nebo číst a pak to interpretovat jako php.

Tu je asi jedine schodne riesenie upravit php/apache, aby nikdy nespustal/neincludoval skripty zo zapisovatelnych adresarov a spravit www adresare nevlastnene od httpd (alebo mu inak zabranit zmenit pristupove prava k tym adresarom).

Co zase samozrejme nikomu nezabrani napisat blby skript, ktory eval()ne lubovolny kus znakov, co dostane z GET query (napr. na nejakom hostingu)...

blbcum se zakaze pouzivat eval(). ostatne, pote, co jsem videl implementaci nekterych funkci z php, zakazal bych nejradsi uplne vsechny funkce. :-)

FRTM. Sorry chlape, apache/php som naposledy administroval asi pred 4-5 rokmi a vtedy bol php des; vsetky optiony si z hlavy nepamatam, neviem jake su nove, momentalne to nepotrebujem a dufam ze v najblizsej dobe ani nebudem.

Ako by to vyzeralo so SELinuxom:
Utocnik by sice mohol nahrat skript niekam, ale uz by mu nemohol dat pravo na spustenie.

Druha vec je, ak sa da napr. cez GET premennu nejaky iny skript prinutit, aby utocnikov skript includol (AFAIK bohuzial celkom bezna technika napadania blbo napisanych skriptov). Specialne ak by v politike bolo pre rolu http servera povolene citanie /var/http/nejaky/adresar/tmp/*, tak to holt moc nepomoze (utocnikov skript sa includne a spusti). SELinux by dokazal zabranit exec()u, ale v pripade includovania sa otvara ten utocnikov skript len na citanie (co je zase podobne ako obycajne citanie nejakych dat, tj. z pohladu SELinuxu neodlisitelne).

Hlavne: politiku si musi admin upravit sam, lebo iba on vie, kto kde ma sahat, defaultna distribucna politika pre apache samozrejme nemoze tusit, ake skripty bude spustat. Samozrejme takato bezpecnost je dost narocna/draha.

Mimochodom, celkom dobry kompromis medzi zlozitostou RBAC a "benevolentnostou" klasickych distribucii je grsecurity bez RBAC. Je to lahkotonaznejsie nez plne RBAC, ale clovek sa z administrovania nezblazni. Mam pocit, ze to navrhovali stylom, ze zobrali najbeznejsie zranitelnosti a urobili proti nim nejake obrany (samozrejme to neni nepriestrelne), napr.:
-spominany non-executable stack, ASLR, odstranenie "zbytocnych" informacii ako process memory maps, neviditelne cudzie procesy apod. (tj. hlavne proti buffer overflow)
-trusted path execution, povoli exec() len z niektorych ciest (zase v pripade includovania utocnikovho skriptu ale nepomoze)
-je mozne zakazat urcitym userom vytvarat nove sockety (jak "klientske", tak "serverove")
-vselijake moznosti auditu
-zamerne disablovanie "featur" typu /dev/mem, /dev/kmem, ..., pri disablovani LKM je zarootkitenie potom naozaj hodne tazkou ulohou
-dalej viz. http://www.grsecurity.net/features.php

Holt ale blbo napisany skript je blbo napisany skript - ziadny RBAC system napr. nezabrani SQL injection a tomu spominanemu includovaniu, ak utocnik tam uz ten svoj skript raz uploadne.

Do apacha vies dohodit mod_security, mod_chroot moduly, ktore zvysia "bezpecnost" apacha o par %, v PHP zakazes nebezpecne funkcie ako system, exec, eval, shell_exec... das Suhosin Patch, co ti zvysi "bezpecnost" php o par %....

No já nevím, jak někdo chce bezpečnost počítat na procenta. Systém buď bezpečný je nebo není, to je binární proměnná, která může nabývat pouze dvou hodnot. Buď existuje sekvence bytů, která dokáže zmanipulovat server, aby vracel podvržená data nebo neexistuje.

uplne bezpecny system nexistuje, to by si ho musel mat odpojeny zo siete :-), tak preto tie %...

No s tema procentama to asi nejde hodnotit ciselne, ale ten cernobily pohled bezpecny/neni bezpecny je zrejme spatne. Teda ten stav bezpecny - to je utopie. Ve vsem jsou chyby, jenom se o nich jeste nevi. Ze je system bezpecny prakticky nikdy rici nemuzeme. Takze bych se skutecne priklanel k tomu vice nebo mene deravy sytem. Podle toho jak se kdo o system stara, co tam instaluje. Jestli si tam pusti PHP apod.
Proste je rozumne davat do systemu nejake bariery (jako SELinux), ktere utoky ztezuji nebo znemoznuji.

afaik jde selinux pouzivat i stylem HIPS, tj. po zaznamenani podezreleho chovani zablokuje program. alespon si tedy matne vzpominam, ze nekdo chtel do selinuxu pred par lety delat dynamicka prava.

Odpověď je sice 1,5 roku po otázce ale jelikož se to dost dobrá námitka a nikdo nebyl schopnej ji odpálit, tak se o to pokusím já.

Za prvé „binární bezpečnost“ neexistuje. Není otázka JESTLI se povede Váš systém kompromitovat, ale KDY a JAK a za kolik peněz. Zabezpečení systému je o tom, aby náročnost probourání, náročnost zabezpečení, a následky probourání byly v jistém poměru.

Vždycky existuje nějaká cesta, například bouchačka u hlavy a příkaz „nahraj mi data“. Pokud Vaše bezpečnostní řešení s tímto přístupem nepočítá jen proto, že to nejde ošetřit na počítači, tak je to hloupé řešení, a budete-li mít dostatečně cenná data, tak bude tato metoda použita.

Nyní k bugu na web serveru. SELinux může v této situaci podstatně zvednout náročnost kompromitace. Jak jste řekl, bylo by nutné složitě distribuovat trojské koně nebo najít nějakou schůdnou cestu přes pravidla politiky k datům nebo jinému cíli. Je zřejmé, že to nebude tak jednoduché, než v případě klasického zabezpečení. Například pokud byste se přes web server proboural až na úroveň, že si spustíte nějaký shell (což nemusí být triviální), tak v normálním linuxu by tento shell měl poměrně široké pole působnosti, zatímco v SELinuxu se Vám nemusí podařit ani základní věci (např. zabít web server a spustit svůj, nebo číst věci z /etc, otevírat sockety mimo port 80). Dejme tomu že přes všecha tato omezení nějak dostanete práva roota (tj. euid 0), v klasickém systému byste nyní mohl číst a měnit úplně všechno, zatímco v SELinuxu nemusíte mít právo vůbec k ničemu, jelikož Vaše systémová identita je pořád ta, se kterou běžel web server. Nedostanete se k datům uživatelů, nemůžete měnit heslo roota, instalovat backdoory, interagovat s ostatními službami, atd.

Dále dejme tomu že se Vám podaří zmocnit se účtu uživatele napadeného stroje pomocí trojského koně tak, že jakmile uživatel otevře tajný dokument (k čemuž má právo), trojský kůň tento soubor odešle do Vašeho prostoru (získaného probouráním se přes web server) kdežto mu dáte dostatečná práva zápisu (tohle není tak jednoduché s dobře nastavenou politikou, ale pořád se to může stát: např. pokud má uživatel možnost publikovat soubory na webu…). Tento problém lze fundamentálně vyřešit pomocí MLS. Je to trochu složitější než běžná konfigurace SELinuxu, ale jde to. V MLS systému se trojský kůň spustí na úrovni důvěryhodnosti uživatele, tj. vyšší než má Váš kompromitovaný web server, a z tohoto důvodu bude poslání dat do Vašeho prostoru zamítnuto. Jinými slovy soubor s přívlastkem „tajné“ se nedostane nikam jinam než do prostoru s přívlastkem „tajné“, což samozřejmě není web server. Tento princip můžete rozšířit na celou síť pomocí MLS sítě a tak zabránit i úniku dat přes kompromitovanou pracovní stanici.

Takže já bych nebral SELinux na lehkou váhu jen proto že Vás ke každému opatření ihned napadne protiopatření. To protiopatření tady bude vždy, ale je dost velký rozdíl mezi výpravou se samopalem k hard disku serveru a mezi přečtením si všech dat přes dementní chybu v javascript interpretu prohlížeče.