Stabilní verze grsecurity patchů nebudou volně k dispozici

Grsecurity (Wikipedie) je sada bezpečnostních patchů pro linuxové jádro (porovnání se SELinuxem a AppArmorem). Dle oficiálního oznámení nebudou od 9. září 2015 stabilní verze grsecurity patchů volně k dispozici. Získat je budou moci pouze sponzoři. Důvodem jsou neustálá porušování licence GPL a ochranné známky grsecurity®. Testovací verze patchů zůstanou nadále volně ke stažení.

29.8.2015 11:11 | Ladislav Hagara | Komunita

Komentáře

[m00t]

Fuck... Asi nejlepší bezpečností systém a dopadne takle špatně...

[AlYoSHA]

Pravdu mas. Asi sa pridam ku sponzorom. Na grsek som si celkom zvykol.

[Petr Tomášek]

200$/m ?

[Václav "Darm" Novák]

Vypadá to na Verifone a Intel… Jojo, malé to firmičky.

[Odin]

Softwarove piratstvi, zde konkretne porusovani podminek uziti dila, skodi i svobodnemu software. Nechapu, jak muze nekdo volit stranu, ktera propaguje tyto myslenky. Ono porusit gpl a porusit podminky u komercniho dila je to same.

[Václav "Darm" Novák]

Osobně jsem vnímal ČPS spíš jako někoho kdo se snaží zasadit o reformu autorského práva aby dávala smysl a víc reflektovala realitu, než jako někoho kdo vyloženě propaguje pirátství. Možná se mýlím a osobně jsem je nevolil z jiných důvodů. Každopádně, myslím že povinná kolektivní správa autorských děl a společnosti se státem garantovaným ziskem z jejich užívání moc do kapitalistického konceptu volného trhu nezapadají.

[Odin]

Nevim, co maji byt spolecnosti s garantovanym ziskem. Se zrusenim kolektivnich spravcu absolutne souhlasim, to je zlo.

Nevim, zda propaguji piratstvi, jen vim, jaky je nazev strany, co rika napr. Pan bartos a profant v tv, sdileni je aktem lasky, atd.

[Václav "Darm" Novák]

Třeba OSA má zisk garantovaný zákonem. Nebo se pletu? :) Kolektivní správa by nebyl problém, pokud by byla dobrovolná a vznikl rozumný trh kolektivních správců které je možné, ale není nutné využít. Samozřejmě by se musely upravit i jejich pravomoci. To že OSA chtěla výpalné i za akci kde se hrála pouze Public Domain a CC hudba byl docela vrchol.

[Václav "Darm" Novák]

V podstatě, tím trhem kolektivních správců myslím něco fungujícího tak jak teď třeba FSF, kdy poskytují právní pomoc GPL projektům. Spíš než kolektivní správce tedy právní společnosti.

[Odin]

Ano, pokud by kolektivni sprava nebyla vynucena, pak by bylo vse v poradku.

[xkucf03]

reformu autorského práva

Reforma je potřeba, na tom se shodneme – nicméně reforma ve smyslu narovnání zákona a vyházení věcí, které tam různé NGO a paraziti přilepili.

Každopádně, myslím že povinná kolektivní správa autorských děl a společnosti se státem garantovaným ziskem z jejich užívání moc do kapitalistického konceptu volného trhu nezapadají.

Nezapadají a to je potřeba změnit. Bohužel piráti to ohýbají jiným směrem a vlastně jednu nesvobodu nahrazují jinou nesvobodou. Dneska jsem nesvobodný v tom, že musím platit výpalné parazitům (kolektivní správa). Ve světě podle pirátů bych byl zase nesvobodný v tom, že bych musel sdílet svoje díla i s těmi, se kterými nechci a za podmínek, které jsme si nedohodli dobrovolně na trhu, ale za podmínek, které nám direktivně určil stát.

[Václav "Darm" Novák]

Hmm, budu si muset pročíst jejich program. Osobně jsem za to aby si každý autor vybral licenci a případně i správce co mu tu licenci pomůže za provizi vymáhat. Ale situace kdy se stává tohle je opravdu šílená.

[Hans1024]

S Piraty je to slozite. Rekl bych, ze prakticky vsichni clenove Piratske strany si uvedomuji, ze copyright je regulace a s vlastnictvim nema nic spolecneho. Setkal jsem se ale s ruznymi nazory co s touhle regulaci vlastne delat.

Z meho pozorovani: Podstatna cast clenu, ktera pravdepodobne prevlada - rikejme ji treba "vetsinovy proud" - je vpodstate pro reformu, ktera zhruba odpovida tomu (a ted uz hodne zobecnuju), co navrhuje Richard Stallman - zkraceni copyrightu na cca 10 let od publikace, povoleni remixu, a pravdepodobne i nekomercniho sdileni neupravenych kopii.

Ja lidi z tohohle "vetsinoveho proudu" moc nemusim. Pripada mi, ze meni Piratskou stranu v "transparentni stranu mirneho pokroku v mezich zakona".

Pak je tam jeste dalsi, a dnes uz asi podstatne mensi skupina "revolucionaru", kteri jsou podstatne radikalnejsi, copyright by proste zrusili, volebni system prekopali, atd.

"Revolucionarsky proud" podle mne zastava puvodni myslenky, ktere staly u zrodu Piratskych hnuti, a ke kterym se hlasim i ja. Lidi jako Rick Falkvinge, ktery se oznacuje za libertariana a ma anarchisticke/anarchokapitalisticke tendence, nebo Birgitta Jonsdotir, ktere jsem tleskal za vyrok, ze proste neni jeden spravny zpusob, jak by mela spolecnost na nejakem uzemi fungovat, a ze je nutne umoznit komunitam, aby zkousely zpusoby nove...; tak takovi lidi mi davaji nadeji, ze tyhle "revolucionarske" myslenky nebudou umlceny tupym stadem a strachem z neznameho. Dnesni svet takovym myslenkam zjevne nepreje, a kdyz nekdo jenom naznaci "neseru se do vas tak se do me neserte", tak uz lezi na zemi spoutany za to, ze pestoval nelegalni rostlinu, nebo jedl nelegalni jidlo, nebo si honil u nelegalniho porna, nebo mel sex s nezletilou osobou, ktera sice se vsim jednoznacne souhlasila, libilo se ji to a nema z toho zadne trauma, ale "stat rozumi psychice nezletilich nejlepe"(tm) a "dokud nejsi plnolety, jsi nesvepravny blbecek"(tm). Svuj rant, ktery jsem puvodne vubec nechtel psat, bych zakoncil jednim trefnym komentarem z diskuse o Liberlandu:

"To be accepted as a 'real country' by the world you must oppress your people and commit crimes against humanity."

[to je fuk]

Jj, je to tak jak kdosi pravil: piráti jsou svobodní bez hypotéky.

[Hans1024]

Ve světě podle pirátů bych byl zase nesvobodný v tom, že bych musel sdílet svoje díla i s těmi, se kterými nechci

Nemusel, jenom by ses musel dohodnout s temi, se kterymi bys to sdilel, aby to nesdileli dal.

za podmínek, které jsme si nedohodli dobrovolně na trhu, ale za podmínek, které nám direktivně určil stát.

Ja myslel, ze to uz jsme si vysvetlili. Dobrovolne si podminky muzes dohodnout jake chces i bez copyrightu. Jenom nemuzes za poruseni dohody postihovat nekoho, kdo ji neodsouhlasil. Kdyz se snazis postihovat kazdeho, kdo je zvyhodneny tim, ze nekdo jiny porusil nejakou dohodu, tak se v takovem systemu bud absolutne neda existovat, nebo musis tolerovat masivni hromadne porusovani zakonu (coz je soucasny zpusob).

[Jacob]

Aby s tímhle přístupem neskončili v propadlišti dějin jako jiné projekty. GR mám raději než SELinux a AppArmor.

Trochu mi to připomíná můj pobyt v nemocnici za komunismu, kde si sestry s pocity méněcennosti léčily své komplexy na dětech tím, že jim všem odepřely večerníček, protože jeden nebo dva jedinci "zlobili". Potrestat všechny za hříchy konkrétních jedinců není spravedlivé a nemohu se za takovou strategii postavit.

[Roman]

Ani ja, ale z toho blogu mam pocit, ze za tim opatrenim neni naplnovani nejake strategie, za kterou by se hrde postavili, ale spis zoufalstvi...

[pavlix]

Takže nejenom, že se jedná o sadu patchů nezačleňovaných do mainline kernelu, ale ještě to ani nebude bez úplaty dostupné.

[Mike]

Testing verze patchů je a bude dostupná stále. Pokud člověk používá moderní kernel, tak stejně musel už teď používat testing verzi (stable byla jen na starší kernely).

Jinak to že Linus a spol. nechtějí do kernelu začlenit podobný security framework je smutné a jedině ku škodě Linuxu. Linux bez PaXu není bezpečný a SELinux/AppArmor/SMACK/Tomoyo ani žádný jiný linuxový LSM to nezachrání. Ty přistupují na scénu až v okamžiku, kdy už došlo k průlomu a slabým místem kde může útočník stále zasáhnout je samotný kernel. GRSecurity/PaX naopak předcházejí tomu, aby vůbec k nějakému průlomu došlo (asi takový rozdíl jako mezi antikoncepcí a potratem ). A nejde jen o PaX, třeba ASLR které dělá GRSecurity je podstatně lepší než ta parodie co je přímo v mainline kernelu.

[Hans1024]

Grsecurity patche jsou brilantni. Problem je ten, ze Linus si ustrikne do kalhot pokazde, kdyz zjisti, ze vykon neceho je o 0.0001% lepsi, nez vykon konkurencni implementace. To proste s praktikami jako randomizace vseho a vynulovani pameti nejde dohromady. Navic autor techhle patchu trpi vlastnosti, ktera je u bezpecnostnich expertu az podezrele casta. Ma totiz tendenci rikat kazdemu "chachacha, podivejte se na ty blbce, cely svet to dela spatne, my jsme to udelali spravne a jsme v tom proste nejlepsi".

[pavlix]

Já osobně si myslím, že by jednotlivé věci z grsecurity měly jít do kernelu a kdo chce plný výkon, ať si je nezapíná. Jinak díky za objasnění těch stable patchů, to mi už nepřijde tak divoké, jako to vyznívalo na začátku.

[Hans1024]

K zacleneni do upstreamu se spender (autor grsec) nekolikrat vyjadril, ze nejsou systemd a nemaji se potrebu nekomu vnucovat a kdo to chce zaclenit, at to udela. Problem je ten, ze by bylo treba to rozdelit na tisic malych patchu a nez aby tim spender plytval cas, tak bude radeji grsec vylepsovat. Navic myslim, ze pri implementaci ASLR nechteli Linuxovi vyvojari pouzit implementaci PaXu, protoze autor nepouzival sve prave jmeno, ale oznacoval se jako "PaX team".

Chapu, proc patchum na nejnovejsi stable jadro radeji rika testing. Staci se podivat na mnozstvi noveho kodu u novych verzi jadra. Bohuzel, Linux v podstate nema stable verze. Do starsich stable verzi jsou backportovane jenom nektere bugfixy. To je problem typicky pro hodne opensource projektu - vsichni vyvojari jedou na upstreamu. Navic Linus odmita oznacovat bezpecnostni bugfixy kvuli tomu, ze by tim "pomahal nepriteli" a nesnasi delat neco vic z bezpecnostnich bugu, kdyz podle nej jsou vsechny bugy stejne dulezite. Greg (maintainer stable Linuxu) na oss-sec mailing listu sam radil, ze nema smysl pouzivat stable jadro, ze nejvic bugfixu je v nejnovejsim jadre. Ale to, ze tam novy kod pritahne milion novych bugu uz nezminil.

[pavlix]

K zacleneni do upstreamu se spender (autor grsec) nekolikrat vyjadril, ze nejsou systemd a nemaji se potrebu nekomu vnucovat a kdo to chce zaclenit, at to udela.

To ovšem docela zavání.

[xm]

Podobný přístup je vlastní spoustě kroptologů a bezpečnostích expertů Stačí se podívat třeba na DJB, to je takový příklad za všechny

Když se to střetne s přístupem Linuse, který zas pro změnu na bezpečnost relativně kálí a jiné věci jsou pro něj důležitější, je jasné že grsec nemá asi nikdy šanci dostat se do jádra. Bohužel

[xm]

Heh, kryptologů samozřejmě... kroptolog nevim co by zkoumal

[pavlix]

Podobný přístup je vlastní spoustě kroptologů a bezpečnostích expertů

Stejně jako je vlastní fyzikům používat k výpočtům stroje a systémy, které někdo uvedl do provozu před dvaceti lety bez ohledu na to, zda by bylo nebo nebylo lepší trochu upgradovat.

Stačí se podívat třeba na DJB

Zrovna tímhle člověkem bych neargumentoval. Obávám se, že nebýt Lennarta, tak po něm dneska pes neštěkne.

Když se to střetne s přístupem Linuse, který zas pro změnu na bezpečnost relativně kálí a jiné věci jsou pro něj důležitější, je jasné že grsec nemá asi nikdy šanci dostat se do jádra.

Tak jestli to správně chápu, tak oni nemají zájem se střetávat s Linusem vůbec. Tomu nasvědčuje i zde popsaný komerční zájem. Kdyby došlo na střet s Linusem a k začlenění podmnožiny patchů, to by byla jiná pohádka.

[xm]

WTF? Co má DJB společného s Lennartem Poetteringem? Kromě arogance tedy Ale na DJB má Lennart ještě co dohánět

Btw. díky DJB tady (mimo jiné) máme Curve25519, Ed25519, ChaCha20-Poly1305 a spousty dalších moderních šifrovacích algoritmů (a nebýt Curve25519/Ed25519, pořád jsme asi ještě závislí na eliptických křivkách s NSA-parametry). DJB je skutečně geniální kryptolog a matematik, to mu nikdo upřít nemůže...

[pavlix]

Tak je pravda, že se na to dívám pohledem vývoje software, pokud jde o matematiku a kryptologii, tak beru zpátečku.

[Petr Tomášek]

IMHO se ale jedná o jiný typ arogance. DJB si hraje na svém písečku a když ho někdo nasere, tak je arogantní. V tomhle se podobá spíš Linusovi.

Lennart se snaží zavirovat těma svýma sračka celej linuxovej „eko“systém a vůči jakékoliv kritice je pak arogantní.

Já v tom teda vidím zásadní rozdíl. Protože DJB přístup je defaultně tak user-unfriendly, že by se nemohlo stát, že bude kdokoliv proti své vůli jeho nástroje nucen používat .

[Michal Kubeček]

DJB si hraje na svém písečku … Lennart se snaží zavirovat těma svýma sračka celej linuxovej „eko“systém

Takže rozdíl je vlastně jen v tom, co kdo považuje za "svůj píseček". :-)

[Petr Tomášek]

Ano, přesně jako v reálném životě . Např. ten, kdo považuje „cizí píseček“ za „svůj vlastní píseček“ většinou bývá zloděj nebo podobný čůrák...

[Hans1024]

Kdyby rekl jenom to, tak to mozna zavani. Ale ze bude grsec radeji dal zlepsovat, nez aby ho nekolik let rozstepoval do malych patchu a premlouval vyvojare se kterymi se nema v lasce, to je celkem logicky duvod.

[Michal Kubeček]

To možná ano, ale v tom případě je ta vize zlých maintainerů mainline jádra coby hlavní překážky, kterou Mike (a částečně i vy) nastínil na začátku, přinejmenším hodně zkreslená.

[Hans1024]

Oni nejsou zli, akorat maji zjevne jine priority.

[pavlix]

Taky se to dá říct tak, že on má zjevně jiné priority než dávat něco do jádra.

[Michal Kubeček]

Jenže ty priority nejsou tak jednoznačné, jak se tu psalo. Nedá se bez rozmyslu prohlásit, že Linus "kašle na bezpečnost, protože ho zajímá jen výkon". Pokud bude na stole sada patchů, která bude splňovat obvyklé nároky na kvalitu a přehlednost kódu a bude rozumným způsobem zvyšovat bezpečnost, ale buď nebude mít podstatný vliv na výkon nebo půjde aspoň při kompilaci vypnout, aby ho neměla, nemyslím si, že ji Linus automaticky zamítne.

Problém vidím spíš v tom, že grsecurity jako celek takhle navržena není, protože autoři jsou přesvědčeni, že bezpečnost "na krev" je tak zásadní, že ji potřebují všichni a případné negativní efekty jsou přijatelné vedlejší ztráty. Jenže Linux se dnes používá na širokém spektru systémů s různorodým způsobem využití; a třeba taková HPC farma kdesi hluboko v izolované síti má výrazně nižší nároky na bezpečnost, zatímco výkon je u ní naprosto kritický.

Obávám se, že je to jen další příklad na populární schéma "tady je geniální sada patchů, bez které nelze žít, ale zkostnatělý Linus (se svými nohsledy) nechápou její genialitu, tak ji pod průhlednými záminkami do jádra nepustí". Stejně jako kdysi ReiserFS a později ReiserFS4 (a další, méně medializované, příklady). Dokonce bych se ani nedivil, kdyby to bylo tak, že autoři o začlenění do mainline vlastně nestojí, protože jim volnost out-of-tree vývoje vyhovuje, a jen jejich fanklub šíří tu iluzi, že "Linus na bezpečnost kašle a proto grsecurity v mainline nechce".

[pavlix]

Dokonce bych se ani nedivil, kdyby to bylo tak, že autoři o začlenění do mainline vlastně nestojí, protože jim volnost out-of-tree vývoje vyhovuje, a jen jejich fanklub šíří tu iluzi, že "Linus na bezpečnost kašle a proto grsecurity v mainline nechce".

A navíc se to konečně začne monetizovat!

[Hans1024]

Pokud bude na stole sada patchů, která bude splňovat obvyklé nároky na kvalitu a přehlednost kódu a bude rozumným způsobem zvyšovat bezpečnost, ale buď nebude mít podstatný vliv na výkon nebo půjde aspoň při kompilaci vypnout, aby ho neměla, nemyslím si, že ji Linus automaticky zamítne.

Vetsinu z nich by pravdepodobne nakonec prijal, nektere ne, podle jeho komentaru k tomu, kdyz nekdo kdysi navrhoval zacleneni PaXu. Ale jak uz jsem psal, znamenalo by to par let travit separovanim patchu a diskusemi na mailing listech. Spender misto toho bude grsec dal zlepsovat. Nevim, co je na tom nepochopiterlneho. Soucasna situace je zjevne pro vsechny zucastnene strany vyhodnejsi.

autoři jsou přesvědčeni, že bezpečnost "na krev" je tak zásadní, že ji potřebují všichni

Prave ze ne. Kdyby chteli, aby to meli vsichni, tak se to snazi protlacit do jadra.

Obávám se, že je to jen další příklad na populární schéma "tady je geniální sada patchů, bez které nelze žít, ale zkostnatělý Linus (se svými nohsledy) nechápou její genialitu, tak ji pod průhlednými záminkami do jádra nepustí".

Ale to prece nikdo nerika. Proste ma kazdy jine priority. Linus neni zkostnately, proste ma vyhranene nazory na vsechno okolo programovani, to neni zadne tajemstvi. Nevim proc z toho porad delate neco, co to neni.

[pavlix]

Nevim, co je na tom nepochopiterlneho.

Nepochopitelného na tom není vůbec nic. Na tom, co dělá Microsoft taky není nic nepochopitelného, rozdíl je jenom v tom, komu zrovna kdo fandí a podle toho všechny posuzuje. :)

[Hans1024]

Ok, tak: Nevidim natom nic spatneho.

[pavlix]

Tak pokud se to alespoň řekne na plnou hubu, tak jako proč ne.

[Michal Kubeček]

Nevim, co je na tom nepochopiterlneho. Soucasna situace je zjevne pro vsechny zucastnene strany vyhodnejsi.

Na tomhle není nepochopitelné nic, někomu opravdu víc vyhovuje udržování out-of-tree patchů a dostat něco komplexnějšího do mainline vyžaduje netriviální úsilí, které tomu každý není ochoten věnovat. Já ale reagoval na výroky typu

Jinak to že Linus a spol. nechtějí do kernelu začlenit podobný security framework je smutné a jedině ku škodě Linuxu.

nebo

Grsecurity patche jsou brilantni. Problem je ten, ze Linus si ustrikne do kalhot pokazde, kdyz zjisti, ze vykon neceho je o 0.0001% lepsi, nez vykon konkurencni implementace. To proste s praktikami jako randomizace vseho a vynulovani pameti nejde dohromady.

vzbuzující dojem, jako by hlavním (nebo dokonce jediným) důvodem toho, že to v mainline není, byl odmítavý postoj Linuse a spol.

[Hans1024]

Grsecurity patche jsou brilantni. Problem je ten, ze Linus si ustrikne do kalhot pokazde, kdyz zjisti, ze vykon neceho je o 0.0001% lepsi, nez vykon konkurencni implementace. To proste s praktikami jako randomizace vseho a vynulovani pameti nejde dohromady.

vzbuzující dojem, jako by hlavním (nebo dokonce jediným) důvodem toho, že to v mainline není, byl odmítavý postoj Linuse a spol.

Tak samozrejme, ze kdyby mel jiny postoj, bylo by to snazsi, respektive Linusuv postoj tam sdili vic lidi, ale s pomoci vic security-minded lidi jako Andy Lutomirski by to asi slo i s nimi, ale rozhodne ne vsecko. Napriklad takovy UDEREF (oddeleni uzivatelskeho a jaderneho adresniho prostoru) na amd64 je kvuli chybejici segmentaci implementovan pomoci triku jako vyhrazeni casti adresniho prostoru pro premapovani userspace pameti pri systemovem volani. Nedokazu si predstavit, ze by Linus neco takoveho prekousnul i jako konfiguracni moznost.

A myslim, ze v tom, co jsem napsal o jeho pristupu k vykonu, jsem pouzil vyjadrovaci prostredky, kterym by zrovna Linus dobre rozumnel - viz. "Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys" - stejne jako to od Linuse nejsou osobni utoky, ode mne taky ne, jenom proste hodne lidi takovy styl vyjadrovani nepobere

[Conscript89]

Hm, jak to funguje? Ono to umi zabranit zneuziti shellshocku, nebo ho primo odstranuje? Takovy SELinux se pri nem hodil. Dhclient a apache procesy mohly pristupovat jen k tem souborum, ke kterym potrebuji a nemohly pouzivat syscally, ktere nepotrebuji.

[xm]

Nevím jak zrovna Shellshock, ale spoustě typů exploitů opravdu GRSecurity/PaX dokáže předejít. MAC je samozřejmě také důležitý (ať už SELinux, AppArmor nebo přímo v GRSecurity obsažený RBAC), ale je to až další vrstva obrany (až když už k nějakému průniku prošlo). Vždy je lepší nejdříve se snažit samotnému průniku předejít. Navíc MAC sám o sobě není účinný vůči některým kernel exploitům (kterým ale GRSecurity/PaX může předejít). Zkrátka ideální je kombinace GRSecurity/PaX a MAC (ne nutně SELinux, RBAC v GRSecurity obsažený je v mnohém lepší a přitom podstatně jednodušší).

[Conscript89]

No, tak jsem si zbezne precetl co GRSecurity dela prijde mi ze dela prakticky to same co SELinux a dam jej (GRSecurity) neznam, takze nedokazu bohuzel posoudit v cem je lepsi/horsi. Mozna se na nej nekdy ale podivam. A PAX resi uplne neco jineho co jsem se docetl.

[xm]

He? Jediné co dělá stejnou věc jako SELinux (tedy MAC) je v GRSecurity obsažený RBAC. To je ale pouze oddělená součást GRSecurity, kterou ani člověk nemusí používat. Pokud chceš můžeš používat GRSecurity/PaX v kombinaci se SELinuxem jakožto MAC, nikdo tě nenutí používat RBAC. Tak to ostatně dělá třeba bezpečná distribuce androida Copperhead OS (protože SELinux je již v Androidu dobře integrován).

Bezpečnost není jen MAC! To je to co se tu celou dobu snažím vysvětlit. MAC je až další bezpečnostní vrstva, která se využije až poté, co už došlo k průniku. GRSecurity/PAX se snaží předejít tomu, aby vůbec k průniku došlo.

[Conscript89]

Cetl jsem si jen na wikipedii, na jejich webu jsem moc nevedel kde to najit. https://en.wikipedia.org/wiki/Grsecurity rika ze PAX je soucasti, ale oni jej nevyviji ale jen jej bundluji a o nem jsem prohlasil ze resi neco jineho (v kontextu shellshocku). Jasne, zni to super a clovek by rekl ze neco takoveho by melo byt by-default zapnuto (ja bych si to dovolil tvrdit). Pak vidim ze je tam prave MAC, ktery je imho co se tyce problematiky a reseni zajimavejsi problem. Pak je tu omezeni chroot, urcite ma vyuziti (pro me ani ne) a pak ma auditovani co zvlada i SELinux. Takze mi vychazi ze ma navic PAX (ktery oni jen bundluji) a chroot restrikce.

Proto ta ma reakce. Rozhodne netvrdim, ze je/neni uzitecny, protoze ho nepouzivam, tak ani nevim.

A ze bezpecnost neni jen MAC, s tim souhlasim, jenom si myslim ze MAC je to hlavni a zaklad. A samozrejme, nejlepsi je prevence a bezchybny kod (jak by se to zilo krasne) :)

[xm]

PaX je nejdůležitější součástí Grsecurity, o tom žádná, vyvinutý je samostatně, ale upřímně netuším, zda nějaké samostatné PaX patche oproti Linux kernelu vůbec existují. Co já vím primární forma distribuce PaXu je právě prostřednictvím Grsecurity. I stránky PaXu jsou hostované jako subdoména pod grsecurity.net.

Jinak doporučuji koukni na tohle porovnání

[Hans1024]

V patchich je toho mnohem vice, nez si myslis. PaX krome silneho ASLR a zakazani write+executable mappingu obsahuje napr.:

Vynulovani uvolnene pameti, vynulovani pouzite casti jaderneho zasobniku po kazdem systemovem volani, read-only function pointery, ochrana proti preteceni vseho mozneho, a hlavne UDEREF, ktery brani zneuziti dereference chybneho ukazatele v jadre. Problem je, ze systemove volani jede ve stejnem adresnim prostoru, jako userspace kod. Utocnik obvykle zneuzije dereferenci chybneho function pointeru k tomu, aby spustil kod z userspace v kernelu. Proto se UDEREF postara o to, aby userspace kod nebyl v kernelu spustitelny. Zneuzit se da ale i chybneho pointeru na data, a podstrcit tak jadru data z userspace. Proto se UDEREF snazi adresni prostor userspace a kernelu uplne separovat.

Vsechny tyhle veci se snazi zabranit exploitnuti jadra uzivatelskym procesem, protoze nejaky MAC je ti k prdu kdyz ten proces co mel byt izolovany ovladne jadro.

Spender (autor grsec) sam napsal mnoho exploitu, takze vi po jakych zranitelnostech utocnici jdou. Do celeho patchsetu pridava spoustu dalsich lahudek, napr.:

Randomizace jadernych struktur. Zabraneni pretykani jaderneho zasobniku. Randomizovane vzdalenosti mezi zasobniky vlaken. Mechanismus ktery kdyz neco casto crashuje usoudi, ze se nekdo snazi bruteforcnout randomizaci a zakaze forky vickrat nez jednou za 30 sekund. Odstraneni spousty infoleaku - kdyz je totiz vsechno randomizovane, tak utocnik hleda neco, ceho se chytit. V adresarich /sys a /proc je pristupna tuna veci, ktere utocnikovi nesmirne usnadni zivot a proto je grsec znepristupni. Spender taky backportuje bezpecnostni bugfixy, ktere jsou ve stable Linuxu bud mnohem pozdeji, nebo tam nekdy nejsou vubec.

Pro dalsi featury viz bud porovnani na ktere odkazuje xm nade mnou, nebo popis jednotlivych jadernych nastaveni .

[Michal Kubeček]

Mechanismus ktery kdyz neco casto crashuje usoudi, ze se nekdo snazi bruteforcnout randomizaci a zakaze forky vickrat nez jednou za 30 sekund.

DoS as a service? :-)

[xm]

Viz Active kernel exploit response

Rozhodně lepší potenciální DoS, než dokonaný kernel exploit.

[Conscript89]

Mimochodem, PAX je nepouzitelny pro chyby v interpretovanych jazycich pokud to chapu dobre.

[xm]

PaX je použitelný víc než dobře, jen se u některých aplikací (třeba kde se používá JIT) musí některé funkce (ne všechny!) PaXu disablovat.

[xkucf03]

GRSecurity/PAX se snaží předejít tomu, aby vůbec k průniku došlo.

To se bavíš jen o určité skupině útoků, která staví na náhodných chybách, omylech (typicky přetečení zásobníku, záměna dat a programu). Ale pak tu jsou útoky, kde se útočníkovi podařilo upravit program před jeho spuštěním – ať už proto, že je sám autorem, nebo s ním spolupracuje nebo ho vydírá, nebo na něj zaútočil, nebo provedl MITM útok na distribuční cestu, kterou se k tobě program dostal. A tyhle útoky jsou neméně významné.

Začal bych tedy spíš tím, že program, který nemá legitimní důvod komunikovat po síti, bude mít komunikaci zakázanou, program, který nemá důvod číst tvoje soukromé klíče, je nebude smět číst, program, který má přehrávat hudbu, nebude moci lézt do tvých dokumentů atd.

[xm]

Začal bych tedy spíš tím, že program, který nemá legitimní důvod komunikovat po síti, bude mít komunikaci zakázanou, program, který nemá důvod číst tvoje soukromé klíče, je nebude smět číst, program, který má přehrávat hudbu, nebude moci lézt do tvých dokumentů atd.

A tady přichází na řadu kontejnery/sandbox, viz má aktuální zprávička o Oz sandboxu ze Subgraph OS. Samotný MAC (ať už SELinux, AppArmor nebo RBAC, to je jedno) kompletní izolaci uspokojivě neřeší (a už vůbec neřeší u GUI aplikací třeba problém s nebezpečností X11).

[Heron]

Když už jsou tady komentáře s tím, jak je ta věc super a strašně nutně potřebná, máte z toho ze svých prostředí nějaké statistiky? Kolika reálným problémům to zabránilo?

Když se totiž podívám do logů selinuxu, tak celkem 0 programů chtělo číst něco "vyloženě divného" (tj data z jiných procesů stejného uživatele, zkusit vlézt do cizího home, pokusy číst shadow, komunikovat po síti když to není síťař apod.)*, z toho, co by zabránil přečíst selinux, ty programy stejně nemají právo číst (takže i z hlediska selinuxu stejně postačují základní unix práva). Výsledek je tedy nula * více než 100 strojů za x let (tedy několik set strojových let bez zásahu i selinuxu).

Jaké jsou statistiky z grsecurity?

Chápu, že tento komentář lze napadnout argumentem, že "zrovna zítra se může stát". No ano, může, ale z dosavadních zkušeností je to nula, takže se blbě dělá statistika, ale kdyby byla pravděpodobnost jednou za 100 000 let, tak je to stejně v praxi irelevantní.

---

*) To, že program čte nějaká veřejně dostupná (právo o+r) data z /usr /lib apod, která sice na první pohled nepotřebuje, ale o nic nejde (třeba konzoloidní program načítá ttf fonty), mě netankuje a nepovažuji to za hrozbu, pokud by mi to vadilo, tak program půjde na samostatný stroj a za trest ty soubory nebudou nainstalovány.

[Hans1024]

Uspesny exploit zahladi stopy

[Heron]

No v tom případě tedy nemá smysl instalovat žádný security prostředek, ne? Když je každý útok úspěšný a nezaznamenaný