Názory k článku Proč byste měli chtít SELinux?

si asi delate prdel, NSA nema s zadnou bezpecnosti nic spolecnyho, je to ekvivalent gestapa s pravem bez obvineni drzet kohokoliv po libovolnou dobu, mucit lidi a podobny svinstvo. http://trn.php5.cz/comix2/vista_patriot_act.jpg

Taková ošklivá organizace by linux neměla používat.

Heh, pleteš si NSA a CIA. NSA nedělá (úplně) špinavou práci.

relativní "pravda", do NSA se cpe více peněz, než do CIA

Ty jsi ale blbecek, vid? NSA je to same co nase BIS, t.j. taky je na ni nahazeno medii a pitomci z rad levicovych extremistu hromada spiny. Ale coz. Kazdopadne mohu ze zkusenosti SELinux jen doporucit (plus sifrovani partisen na disku). Ubere to sice vykon, ale neni to tak hrozne. Ubere to ovsem take cas se to naucit. Myslim ale, ze NSA udelala opravdu dobrou praci v teto oblasti a s nekterymi lidmi (vyvojari) se obcas bavim a tak ti muzu rict, ze s nejakym gestapem toho maji asi tak tolik spolecneho jako treba petrzel...

a valka je spatna a je treba bojovat za mir, jste zapomnel napsat.

Hele, komousi, bezte si cist Rudy Pravo a nesmrdte na rootu. Vite kolik penez daly ty ,,zle americke agentury'' jako je DARPA, NSA a spol na vyzkum Internetu? Kde byste ted bez nich byli, myslite si, ze byste si ted cetli roota? Pche, mekkaci.

Ano, na výzkum decentralizované sítě, která by jim v případě totální války poskytla naprostou výhodu nad nepřítelem.

Zcela mě udivuje, jak dokážou být někteří lidé zaslepeni jakousi pseudo-"vděčností".

Je to stejné jako GPS. Ačkoliv už není signál uměle degradován a je určen široké veřejnosti, stále ho mohou američané *kdykoliv* vypnout. Celý zbytek tupého světa tak bude odříznut od satelitní navigace. Důsledky si můžete domyslet. A podobných příkladů je spousta. A jenom proto, že lidi pociťují nějakou "vděčnost" za skutky minulé (nebo naprosto neopodstatněnou) a cítí se jí být zavázáni.

A za to, že dnes existuje služba WWW můžeme být vděčni tak akorát univerzitám ale určitě ne americkým tajným službám a vládním organizacím (ačkoliv DARPA je faktickým původcem myšlenky decentralizované sítě, bez univerzitního pacifistického a převážně sociálně smýšlejícího prostředí by to asi tak rychle nešlo).

Ako je to s predpripravenymi politikami pre rozlicne programy pod SELinux? Totiz SELinux aj grsecurity su fajn veci, ale bez predpripravenych pravidiel je to mierne nepouzitelne (schvalne si skuste vytvorit politiku napr. pre apache, zabere to tak den). AFAIK hlavne RedHat robi a udrziava dost politik pre mnohe programy, ale dal by sa niekde najst zoznam programov, pre ktore su politiky hotove?

grsecurity ma na vytvaranie politik dobru featuru - "learning mode", kde sa pusti program a on na zaklade nejakych heuristik napise politiku (podla toho k akym suborom proces pristupuje apod., typicky vytvorena politika dovoli vsetko, co program robi), ale aj tak to musi typicky clovek opravit rucne (a su fakt dlhe...). Napr. dovolit pristup nielen na /tmp/ABCDpodivnemeno suboru, ale aj /tmp/ABCD*.

grsec som nikdy velmi neriesil, selinux mi prisiel sympatickejsi.
Mal som moznost hrat sa so selinuxom na gentoo a to ti poviem, ze nastavovanie selinuxu zabralo velmi, velmi vela casu. Co sa tyka RH, tak sa o to stara asi velmi dobre, pretoze vela komercnych firiem pouziva na pocitacoch rhel, takze myslim, ze s tym problem nebude. Treba pozriet na nejake rpm balicky na mirroroch red hatu.

Zdravim,
myslim, ze to je prave ta nejvetsi osina v pate - upstream malokdy resi nejaky SELinux. Co se tyce distribuci RH, tam mam docela dobrou zkusenost, RHEL je celkem vyladeny (pouzivam na serverech CentOS a zatim jsem resil jen 3rd party aplikace, je ale pravda ze mi to zabralo cely den), na Fedore obcas nejake problemy jsou, ale Dan Walsh na bugreporty odpodvida jednim komentarem a to "Fixed in policy $version-$release" :-)

Na serverech ktere jsou pripojene primo k Internetu si ale myslim ze se to vyplati..potencialni skody muzou byt casto drazsi nez cena jednoho dne prace..

Jasne, na kritickych serveroch sa to urcite oplati.

Najlepsie by bolo, keby politiky pisali priamo autori softu (najlepsie sa v nom vyznaju), ale to sa zatial nedeje a asi ani tak skoro nebude. Mozno by nebolo zle pisat to pre nejaky "spolocny model" RBAC, tj. ze by z toho sli odvodit politiky pre SELinux, grsecurity a ine RBAC systemy (nepamatam si, jak moc sa lisia, asi by slo "prekladat" SELinux politiky na grsec politiky). Keby to slo aj opacnym smerom, tak grsec learning mode je fakt dobry nastroj, s ktorym sa cas na napisanie politiky tak o polovicu skrati (AFAIK SELinux nema learning mode).

Prave, na Fedore me problemy donutily to hned vypnout (nesel dnsmasq a tak). AppArmor mi na SuSE zatim problemy nezpusobil, i kdyz mozna neni tak ucinny, moc se v tom nevyznam.

Stav je spatny. Ani ty predpripravene politiky od Redhatu pro bezne programy typu apache,bind,samba,openldap a dalsi nejsou to prave orechove. Docela casto narazim na chyby. Redhat se snazi sec muze. Aktualizuje celkem casto. Chyba je podle me v selinuxu. Viz muj prispevek s vulgarnimi vyrazy.

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.

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.

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 %....

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.

Ahoj,
se mi zdá, že LSM je framework kernelu pro psaní security modulů do jádra (tedy i SELinux) a je to tedy něco jiného než modularita SELinux Reference policy.
Jinak docela pěkné intro do SELinuxu.

SELinux nedoporucuji a na desktop v zadnem pripade, PAX, GrSec, Medusa, NX bit a je po starostech, mozna jeste nekdo muze uvazovat o patchich do cstdlib, pridavajicich automaticky boundary checking, sice to znatelne snizi vykon, ale je to narozdil od SELinux nemainstreamove reseni, ktere tedy bude znat mensina utocniku a jen minimum z teto mensiny to cele dokaze obejit. Nadruhou stranu si myslim, ze pokud se vam nekomu zavede rootkit do interrupt table, ze jej nikdy v zivote nenajdete, takze asi tak, ...

co viem tak mrduza ostala pri 2.4.26 jadre a dalej sa nepokracuje...

PAX ma zmysel tak na 64-bit stroji, takze dnes uz neni problem vacsinou. S tou Medusou si zaspal dobu - niekolko rokov. GRSecurity je fajn a lahko konfigurovatelne dokonca aj s RBAC, takze sa "na desktop" IMHO "hodi asi najviac". SELinux je vsak lepsi ale nevhodny pre paranoikov. Ja osobne co sa tyka tazkeho kalibru odporucam RSBAC.

Nezaspal jsem dobu, vsechny security patche do kernelu, ktere jsem uvedl, jsou velmi zastarale, vy si mozna volite dle toho, co je vice zastarale ci mene zastarale, ja ne. Mozna to vyzni neuveritelne, ale stale spousta serveru uziva Linux rady 2.4 a to prave z bezpecnostnich duvodu, rada 2.4 ma totiz vetsinu chyb jiz zalatanych a na 2.6 se prechazi az kdyz je to nevyhnutelne kvuli podpore HW. Radovi admini maji deb* a ridi se heslem "Never touch the running server".

Povinna cetba zde: http://conference.hackinthebox.org/hitbsecconf2007dubai/materials/D2%20-%20Rodrigo%20Rubira%20Branco%20and%20Domingo%20Montanaro%20-%20Kernel%20Hacking%20-%20If%20I%20really%20know%20I%20can%20hack.pdf

Reagoval som na prispevok ktory z ktoreho to dost zavanalo, ze sa momentalne bavime o desktope, kde je IMHO 2.4 uz zo spominanych HW dovodov dost neprakticka a tym padom si stojim za svojim, ze je Medusa uz dost mimo.
PS: ja sam som debianista, takze som v podstate tiez zastanca vami spominaneho hesla: "Never touch the running server". Zas na druhej strane pokrok nezastavite a hold medusa to uz ma za sebou a stava sa historiou - hoc velmi kvalitnou.
PPS: povinneho citania podobneho razenia som mal pri pisani DP az az, takze netreba, aj ked som si to rad prebehol :)

"Pres vsechnu snahu vývojáru vyvinout bezchybný a bezpecný systém je jisté, ze se jim to prozatím nepodarí."

Podle toho jak ignorujou patche na zavazne chyby (race conditions, deadlocky) me pride ze zadnou takovou snahu nemaj.

Nemuzu si pomoci, ale prijde mi ze SELinux je slepa vetev vyvoje pocitacove bezpecnosti. Veci by meli spet k jednoduchosti. V jednoduchosti je sila. SELinux je prilis komplexni na to aby se uchytil. Myslim si ze pridani nejake dalsi vrstvy k tomu aby mi omezovala aplikace neni zas tak spatny napad, ale v podobe v jake to resi selinux je to ftakovina. Kdo si ma pamatovat tu spoustu picicurek a ftakovinek? Zbyde vubec cas na skutecnou praci? Neni to security trough obscurity? Vzdyt pri komplexnich konfiguracich uz se clovek straci. Pokud mi na serveru bezi treba jenom indian tak dobre. Oki. Jakz takz to uhlidam. Ale kdyz je tech veci treba 5? A po kazdem updatu se meni chovani aplikaci. SELinux neni zas az tak uzitecny aby si zaslouzil studium tak komplexniho systemu. Nehlede na to ze mi to nikdo nezaplati:)

Moje zkusenosti se SELinux
1.Precteni nekolika clankum, nainstalovani distra zatim mimo zakaznicky server jenom k testovani. Prvni dojem: je to kurva slozity nebo jsem starej?
2.Dojem prvni. Tyjo to je docela dobry napad. Hmm supr. Neco takoveho jsme potrebovali
3.Dojem druhy. Hmmm ono to nebude tak jednoduchi. Ok. Tak to je holt dan za bezpecnost. Aspon se neco noveho uzitecneho naucim
4. Proboha kdo vymyslel takovy komplikovany kolos? Jak je mozny udrzovat prehlednou a jasnou konfiguraci kdyz se v tom clovek sotva vyzna!
5. Nasrani pri nerozbehnuti samby(nejaka blokace ze SELinux protoze jsem ji rucne smazal soubor ktery nova updatnuta verze nemohla sezrat(myslim ze to byl ntdrivers.tdb) a nejaky lock.
6. Nasrani pri nerozbehnuti messagebus a komplet jebnuti systemu pri nabihani. Duvod. Blbe napsany pravidla v SELinuxu. Vse original puvodni instalace od Redhatu.
7. Nastaveni selinuxu na disabled a venovani se virtualizaci. Selinux? Nasrat!