Jaderné noviny – 16. 6. 2011: Sjednocující FS v jádře?

29. 6. 2011 | Jirka Bourek | Jaderné noviny | 4063×

Aktuální verze jádra: 3.0-rc3. Citáty týdne: pageexec, Linus Torvalds, Greg-Kroah Hartman. Nativní nástroj pro KVM v Linuxu v2. Debata o overlayfs. Přepracovaný alokátor spojité paměti.

Obsah

• Aktuální verze jádra: 3.0-rc3
• Citáty týdne: pageexec, Linus Torvalds, Greg-Kroah Hartman
• Nativní nástroj pro KVM v Linuxu v2
• Debata o overlayfs
• Přepracovaný alokátor spojité paměti

Aktuální verze jádra: 3.0-rc3

Současné vývojové jádro je 3.0-rc3 vydané 13. června. Linus říká: Je tu spousta jednořádků, ale i větší kousky: aktualizace DRI pro Radeon, nějaké aktualizace btrfs a oprava podpory Sparc LEON (a podpora PCI). Menší aktualizace nilfs2 a ceph a s390 a arm. Krom toho jsou to většinou náhodné úpravy ovladačů všude možně. Zkrácený changelog je v oznámení, detaily najdete v kompletním changelogu.

Během tohoto týdne nevyšly žádné stabilní aktualizace. Aktualizace 2.6.32.42, 2.6.33.15 a 2.6.39.2 se v době psaní tohoto článku revidují; lze je očekávat 18. června nebo poté.

Citáty týdne: pageexec, Linus Torvalds, Greg-Kroah Hartman

Vypadá to, že se rok za rokem překonáváte v absurditě. Jeden by si položil otázku, jestli pro letošní pwnie awards nebude potřeba nová kategorie, protože vy se pravděpodobně do kategorie nejhloupější odpověď od výrobce už nevejdete.

-- pageexec

Vypadá to, že je zde příliš mnoho problémů na to, aby se mohlo nazývat „3.0“, a to je smutné. Není to ale omluva pro to, když se ty chyby nepokusíme opravit.

-- Linus Torvalds se připravuje na 3.0.0

Kompletní sada patchů bude jako obvykle zaslána, ale budou o pár hodin opožděny s ohledem na ty, kteří jsou ještě vzhůru a snaží se něco udělat

-- Greg-Kroah Hartman posouvá problémy na východní polokouli.

Nativní nástroj pro KVM v Linuxu v2

Druhá verze Nativního nástroje pro KVM v Linuxu (náhrada za QEMU) byla zaslána. Nástroj nyní obsahuje podporu grafiky, SMP, síťování, I/O se soubory je údajně rychlejší než v QEMU atd. „Oficiálním cílem“ vývojářů je nyní začlenění do vývojového cyklu jádra 3.1.

Debata o overlayfs

napsal Jonathan Corbet, 15. června 2011

Sjednocující souborové systémy umožňují zkombinovat několik souborových systémů a zpřístupnit je uživateli jako jediný strom. Při typickém použití zapisovatelný souborový systém překrývá základ, který je pouze pro čtení, což vytváří iluzi, že všechny soubory v daném souborovém systému lze změnit. Tento způsob práce je užitečný pro Live CD, embedded systémy, kde je potřeba rychlý reset do továrního nastavení, virtualizované systémy vybudované nad společným základním souborovým systémem a tak dál. Přestože by tato vlastnost byla užitečná, Linux nikdy neobsahoval sjednocující souborový systém, i když několik pokusů nějaký vytvořit tu bylo. Nedávný pokus situaci změnit možná uspěje, možná ne.

Jaderné noviny se souborovým systémem overlayfs zabývaly loni. Autorem overlayfs je Miklos Szeredi a souborový systém jako takový se odlišuje od jiných svou relativní jednoduchostí. Nedávno se Miklos zeptal, jestli by bylo možné začlenění do vývojového cyklu 3.1. Možná se mu toto přání splní, ale nejprve bude potřeba vyřešit nějaké problémy.

Andrew Morton přišel s několika připomínkami; jednou z nich je, že by problém mohlo být lepší vyřešit v uživatelském prostoru. Jednoduchost overlayfs přešel s tím, že Nezačlenit to vůbec je ještě menší a jednodušší, a navrhl, že by problémy s výkonností měly být řešeny zrychlením implementace v uživatelském prostoru. Linus nicméně tento aspekt debaty ukončil tím, že řekl: Lidí, kteří si myslí, že souborové systémy v uživatelském prostoru jsou dobré k něčemu jinému než k hraní si, jsou jednoduše pomatení. Implementace sjednocujícího souborového systému v jádře má tedy podle všeho cestu volnou.

Další Andrewova obava se týká toho, že overlayfs nemusí být dostatečné řešení:

Jestliže overlayfs dostatečně nesníží motivaci začlenit další sjednocující souborové systémy, pak můžeme skončit se dvěma podobnými věcmi. A předpokládám, že pozdější a kompletnější implementace by mohla způsobit, že overlayfs bude zastaralé, ale těžko se ho budeme moci zbavit.

Reagovat na tuto námitku je těžší. Bylo poukázáno na to, že OpenWRT overlayfs s klidem používá a Ubuntu to zvažuje. Jediný možná použitelný alternativní projekt jsou sjednocená připojení [union mounts], kterým se ale v nedávné době moc pozornosti nedostalo. Co se vlastností týče, nezdá se, že by v blízké budoucnosti přišlo něco dalšího, co by overlayfs zastínilo.

Co se technické stránky týče, sjednocující souborové systémy vždy přinášely nějaké unikátní problémy. Valerie Aurora, která v této oblasti odvedla dost práce, se na overlayfs dívala v červnu a zdá se, že se jí líbil:

V rychlosti jsem se podívala na současnou sadu patchů overlayfs a je malá, čistá a snadno pochopitelná. Jestliže to bude dělat to, co lidé potřebují, dodávejme to.

V současné diskuzi lehce změnila tón a naznačila, že jsou zde nějaké těžkosti, které je potřeba vyřešit:

Overlayfs není v současnosti nejjednodušší možné řešení. Například nebrání změnám adresářů v nižších souborových systémech, což je podle Ala naprosto nezbytné k tomu, aby se zabránilo chybám. Al navrhl řešení, se kterým byl spokojen (superbloky pouze pro čtení), pro sjednocená připojení jsem to implementovala a věřím, že by to bylo možné portovat do overlayfs. Ale to by se mělo stát před začleněním.

Také měla nějaké námitky ohledně zamykání, na což Miklos detailně zareagoval; námitky ohledně změn nižších souborových systému nicméně řešeny nebyly. Je tedy možné, že záležitosti s technickou korektností mohou zbrzdit začlenění overlayfs do jádra. Je zjevné, že po této vlastnosti je poptávka a že overlayfs je schopen ji hezky pokrýt – přijde čas, kdy bude jeho zdržování mimo jádro příliš těžké ospravedlnit.

Přepracovaný alokátor spojité paměti

napsal Jonathan Corbet, 14. června 2011

Problém spojený s alokací velkých kusů fyzicky spojité paměti je zde diskutován často. Povaha virtuální paměti je taková, že často rozhází stránky v systému; jádro ani nemusí běžet dlouho na to, aby byly relativně vzácné sousedící stránky. Mnoho let se s tímto problémem vývojáři jádra vyrovnávali tím, že se vyhýbali závislosti na velkých spojitých alokacích všude, kde to bylo možné. Jaderný kód, který se pokouší alokovat více než dvě fyzický spojité stránky, je výjimkou.

V nedávné době ale potřeba spojitých alokací začala růst. Jedním zdrojem poptávky jsou velké stránky [huge pages] a vlastnost transparentních velkých stránek konkrétně. Dalším je starý příběh s novým zvratem: hardware, který není schopen používat DMA rozsypej/sesbírej [scatter/gather]. Každé zařízení, které umí DMA pouze s fyzicky spojitou oblastí, vyžaduje (pokud není přítomna jednotka pro správu I/O paměti) k práci spojitý buffer. Tento požadavek je často příznakem low-endového (hloupého) hardware; můžeme jenom doufat, že takový hardware bude postupem času výjimkou. Co ale vidíme v současnosti, jsou čím dál schopnější zařízení, která si požadavek na spojitou paměť pro DMA ponechala. Příkladem jsou zachycovací jednotky, které dokáží vyprodukovat data ve vysokém rozlišení, provést s nimi několik transformací, ale pro uložení výsledku stále potřebují spojitý buffer. Příchod videa ve vysokém rozlišení problém zhoršuje – ty fyzicky spojité buffery jsou nyní o dost větší a alokují se hůře než dříve.

Téměř před rokem se Jaderné noviny zabývaly patchi pro alokátor spojité paměti [contiguous memory allocator, CMA], které měly problém vyřešit. Sada patchů následovala starou tradici rezervace kusu paměti při bootu jenom kvůli tomu, aby se vyhovělo požadavkům na velké alokace. Postupem let tuto techniku používal patch „bigphysarea“ i jednoduché bootování s parametrem mem=, který zajistil, že se kus paměti ponechal volný. Ovladač pmem z Androidu, který je mimo strom, také alokuje paměť z rezervované oblasti. Tento přístup rozhodně funguje; téměř 20 let zkušeností to potvrzuje. Nevýhodou je, že rezervovaná paměť se nedá použít jinak; pokud ji žádné zařízení nevyužívá, prostě nečinně sedí. U jaderných vývojářů – a uživatelů – bývá takové plýtvání poměrně nepopulární.

Z tohoto důvodu nebyly patche CMA nikdy začleněny. Problém ale nezmizel a nezmizeli ani vývojáři, kteří ho řeší. Nejnovější sada patchů CMA vypadá úplně jinak; i když je stále potřeba vyřešit nějaké záležitosti, má tato sada na první pohled mnohem lepší šance dostat se do hlavní řady.

Alokátor CMA stále může pracovat s rezervovanou oblastí paměti, ale rozhodně to není zamýšlený způsob fungování. Místo toho se CMA pokouší udržovat oblasti, ze kterých by bylo možné alokovat velké kusy spojité paměti, když to bude potřeba. Za tímto účelem se CMA hodně opírá o mechanismus „migrace typu“ [migration type], který je zabudován hluboko do kódu správy paměti.

V každé zóně jsou označeny bloky, které se mají používat pro stránky, které nejsou přesunutelné a které nelze zabrat [reclaim]. Přesunutelné stránky jsou hlavně cache stránek a anonymní stránky; přistupuje se k nim přes tabulky stránek a radix strom cache stránek. Jejich obsah lze přesunout jinam, pokud budou změněny i odpovídající tabulky a strom. Zabratelné stránky by mělo být možné vrátit jádru, když je to potřeba; obsahují datové struktury jako cache inodů. Nepřesunutelné stránky jsou obvykle ty, na které má jádro přímé ukazatele; například paměť získanou pomocí kmalloc() normálně nejde přesunout, aniž by se něco rozbilo.

Subsystém správy paměti se pokouší držet přesunutelné stránky pohromadě. Pokud je cílem uvolnit velký kus paměti tak, že se stránky odstěhují jinam, jediná přibitá stránka stačí k tomu, aby tato snaha přišla vniveč. Tím, že se přesunutelné stránky shlukují, jádro doufá, že bude schopné uvolnit na vyžádání velké rozsahy, aniž by se narazilo na nějaký háček. Kód shlukování paměti spoléhá na to, že takové rozsahy budou existovat, jinak by nemohl dělat svoji práci.

CMA tento mechanismus rozšiřuje přidáním nového typu migrace „CMA“; ten funguje podobně jako typ „přesunutelné“ [movable], ale s několika rozdíly. Typ „CMA“ je pevný; u stránek, které jsou takto označeny, by jádro nikdy nemělo změnit typ. Alokátor paměti nikdy v této oblasti nealokuje nepřesunutelné stránky; co se jiného použití týče, CMA stránky se alokují jenom, když není jiná možnost. Se štěstím by tedy oblasti paměti označené pro používání CMA měly obsahovat jenom přesunutelné stránky a měly by mít relativně velký podíl volných stránek.

Jinými slovy je takto označená paměť k dispozici zbytku systému za podmínky, že může obsahovat pouze přesunutelné stránky. Když přijde ovladač a žádá o spojitou oblast paměti, CMA alokátor se obrátí na jednu ze svých speciálních oblastí a pokusí se odházet dost zabraných stránek tak, aby se vytvořil spojitý buffer vhodné velikosti. Pokud jsou stránky v dané oblasti opravdu přesunutelné (skutečný svět někdy překáží), mělo by být možné dát ovladači buffer, který potřebuje. Když tento buffer není potřeba, paměť lze použít k jinému účelu.

Mohli bychom si položit otázku, proč je tento mechanismus vůbec zapotřebí, vzhledem k tomu, že shlukování paměti již teď umí vytvářet velké fyzicky spojité kusy pro transparentní velké stránky. Tento kód funguje, systém autora tohoto článku v době jeho psaní má cca 25 % paměti alokováno jako velké stránky. Odpověď je, že DMA buffery mají jiné požadavky než velké stránky. Mohou být například větší; transparentní velké stránky jsou na většině architektur 2 MB velké, zatímco DMA buffery mohou mít 10 MB nebo více. Také může být potřeba vložit DMA buffery do specifických rozsahů paměti, pokud je hardware dostatečně divný – a vývojář CMA Marek Szyprowski podle všeho opravdu podivný hardware má. A nakonec, velká stránka o velikosti 2 MB musí být také správně zarovnána, zatímco požadavky na zarovnání DMA bufferů obvykle bývají mnohem volnější. CMA alokátor může zabrat přesně požadovaný kus paměti (bez zaokrouhlování velikosti nahoru na další mocninu dvou, jako to dělá buddy alokátor), aniž by se zabýval příliš přísnými požadavky na zarovnání.

Sada patchů CMA poskytuje sadu funkcí pro nastavení oblastí paměti a vytváření „kontextů“ pro specifické rozsahy. Pak jsou zde jednoduché funkce cm_alloc() a cm_free(), které poskytují a uvolňují buffery. Očekává se nicméně, že ovladače zařízení nikdy nebudou volat CMA přímo; místo toho bude používání CMA zabudováno do podpůrných funkcí pro DMA. Když ovladač zavolá funkci jako dma_alloc_coherent(), automaticky se pro splnění požadavku použije CMA. Ve většině případů by to mělo „prostě fungovat“.

Jeden ze zbývajících problémů CMA je to, jak se speciální oblasti vytváří. Současné schéma očekává, že v souboru s definicí systémové desky bude speciální volání; je to velmi ARMistický přístup. Záměrem je těchto souborů se zbavit, takže bude potřeba přijít na něco jiného. Jak upozornil Arnd Bergmann, přesun této informace do stromu zařízení [device tree] není možný; je to rozhodnutí o politice. Arnd tlačí na vytvoření nějakého rozumného výchozího nastavení, které bude na většině systémů fungovat; obezličky pro systémy se speciálními problémy lze přidat později.

Konečným výsledkem je, že než se tato sada patchů dostane do hlavní řady, pravděpodobně se objeví přinejmenším ještě jedna její iterace. CMA nicméně řeší skutečný problém, na který se naráží, aniž by k tomu používal hacky různé nekvality, které lze najít mimo strom. Kód má potenciál zajistit, že alokace fyzicky spojitých bloků bude spolehlivější a dopad na zbytek systému přitom bude minimální. Vypadá to jako něco, co stojí za to mít.

       

Komentáře

[Synt]

Vidim ze pipacs zas vybuchol :D. A to je dobre treba ukazat retardom z Red Hatu a hlavne tomu blbovi Ingovi ze su naozaj retardi.

[setuid]

Vidim ze pipacs zas vybuchol :D. A to je dobre treba ukazat retardom z Red Hatu a hlavne tomu blbovi Ingovi ze su naozaj retardi.

Poslouchaj synt, když pipacs někoho chválí, sou to retardi? Já jen abych si v tom udělal jasno..

> ..it's what pretty much everyone else (other than you, that is) in > the world does, including your own employer, Red Hat.

> i already asked you about this and you never responded so here it is again: > what do you think about Red Hat publishing security errata (including kernel > vulnerabilities)? with CVEs, description of fault, etc.

[a.syntsow]

Riadis sa len tym co bolo napisane v tomto maile. Nevidis suvislosti predtym...

[geebranz]

More modification

Reap

[Ladicek]

Žeru Linuse:

So Andrew, I think that arguing that something _can_ be done with fuse, and thus _should_ be done with fuse is just ridiculous. That's like saying you should do a microkernel - it may sound nice on paper, but it's a damn stupid idea for people who care more about some idea than they care about reality.

[fikus]

plan9 ma pekne vyresene souborove systemy pomoci API/protokolu 9P. v jadre nemusi byt souborove systemy implementovany, je to v userlandu a daji se delat uniony a jine hovadiny. tohle by bylo fajn mit mimo jadro i v linuxu, ale muselo by to byt lepe a rychleji nez s FUSE.

[Michal Kubeček]

Obávám se, že tím jen demonstrujete přesně to, o čem Linus mluvil…

[zdgadgsdfg]

mozna. v plan9 to ovsem funguje skvele. no ani linus neni neomylny a nezna vsecko

[Michal Kubeček]

A nebo se na to dá dívat tak, že kouzlo úspěchu Linuxu je mimo jiné v tom, že Linus je pragmatik a tak často před řešením, které je z teoretického hlediska skvělé, upřednostní takové, které sice není tak elegantní, ale je praktičtější. A přesně o tom IMHO mluví v tom příspěvku…

[Sten]

U overlayfs by se hodilo, aby se dal změnit spodní souborový systém za běhu (třeba kvůli jednotným aktualizacím všech virtuálních strojů), ale i polovičaté řešení by bylo super Na btrfs se zatím nedá spoléhat (nedávno se mi rozsypalo a hláška fsck.btrfs, že je ten systém rozbitý a fsck.btrfs zatím neumí opravovat, fakt nepotěší) a LVM místo neušetří, pokud se nechcete dostat do problémů.

Malá poznámka k překladu: migration type je migrační typ (typ migrace).

[trekker.dk]

Na btrfs se zatím nedá spoléhat (nedávno se mi rozsypalo a hláška fsck.btrfs, že je ten systém rozbitý a fsck.btrfs zatím neumí opravovat, fakt nepotěší)

To bude asi to docela stabilně

[Sten]

Jenom dodám, že mě místo nedošlo, ale nějak se pohádaly btrfs, aktualizace (resp. velká zátěž na disk) a hibernace a výsledkem byl rozbitý adresář emotikon pro KDE4, což při rw mountu okamžitě shodilo jádro. Na ext* jsem nikdy s hibernací během jakékoliv zátěže na disk problém neměl (a jestli nějaké byly, tak to automatický fsck vyřešil).

[BostX]

Kto je ten pageexec resp. pipacs???

[a.syntsow]

Pipacs je legendarny security developer. Autor PaX-u. Je to clovek co vymyslel najucinnejsie techniky a protection mechanizmy. Da sa povedat ze je to najschopnejsi whitehat hacker tohto storocia. Uznavaju ho nielen ostatni whitehat hackeri (taviso, julien, drosenbe, kees...) ale aj blackhats.

PaX je mimochodom superlativom security. Selinux je oproti tomu detska hracka. OpenBSD vykradlo PaX a vdaka tomu vytvorilo svoju povest najbezpecnejsieho operacneho systemu. V PaXe sa prvykrat objavilo ASLR, ktore neskor pouzili spolocnosti ako Microsoft (ALE ZLE !). Jedine originalny koncept a implementacia plni svoj ucel.

Pipacs vystupuje anonymne pod pseudonymom "pipacs" alebo "PaX team", povodom je z Madarska. Spolu s Bradleym Spenglerom "spender" su jedinymi developermi grsecurity.

Obidvaja su taktiez flameri na lkml :). Totizto bezpecnost nikdy nebola v Linuxe dolezita. Nie pre Linusa ktory sa hnal vzdy za vykonom a efektivitou. Ale ludia od Red Hatu su fakt retardovani...a hlavne Ingo Molnar. Vdaka Crap Hatu tu mame suxxovne .rpm, zamlcane bugy v kerneli, ignorovanie zavaznych bugov, silent fixing atp.

Dufam ze takto ti to staci ;)

[BostX]

THX!

[trekker.dk]

zamlcane bugy v kerneli, ignorovanie zavaznych bugov, silent fixing atp.

To jsou zase bláboly...

[jk001]

to nemůžou být bláboly. Zmínil přeci dost zkratek, odkázal na anonymního odborníka, pohanil microsoft, proste odborník na všechno.

Asi nejlepší je srovnání selinuxu a PaX (http://en.wikipedia.org/wiki/PaX), to už mi přislo vyloženě jako sebeukamenování :).

A protože odborník je to skutečně na všechno, tak se vyzná i v "Crap hatu", rpm je samozřejmě debilní, jak taky jinak :)) Nějak marně hledám, na co ten člověk vlastně odborník není, ale napadá mě jen jedno přirovnání:

Prázdný sud dělá největší randál :).

[a.syntsow]

Vy dvaja ste retardovani pepici. Bez vseobecneho rozhladu v security.

1) Pipacs si vybral cestu anonyma 2) Implementacia ASLR v MS, vo vanilla linuxe je ZLA ! To je cisty fakt. To ze ty si jebnuty pepicek je vec dalsia. 3) Selinux je ubohost oproti PaXu. Selinux je prachsprosty MAC ktory v poslednom case vykrada viac a viac PaX. Neobsahuje vsak ani 1/3 z toho co grsec. Pouziva LSM, neriesi arbitrary RWX bugy v kerneli ani infoleaky. Exec Shield je na smiech. 4) Na bugy ktore boli zamlcane existovali exploity, neboli vydane ziadne advisory, CVEcka

Prazdny pepik s mastnymi vlasami robi najvacsi randal :)

[msk]

Prosim nekrmit! Nie kazdy Slovak je kokot...

[a.syntsow]

Ale ty k nim samozrejme patris ty retardovany kus kokota. Pozri si moje prispevky a ich. Ja v nich uvadzam ciste fakty a oni zacali so zbytocnym trollovanim. Ale co mozem ocakavat od cloveka co veri tomuto http://www.abclinuxu.cz/blog/msk/2006/11/test-zabezpecenia. ROFL. Ty budes nejaky pridrbany studentik s mesiacom praxe.

[trekker.dk]

LOL, slovenská varianta PT, včetně vytříbeného stylu argumentace, dokonalých schopností komunikace s oponenty a prezentace faktů, která jsou fakty, protože jsem to řekl. Pověz nám, taky tě v přestávkách mezi webovými diskuzemi zavírají do klecového lůžka, nebo u vás tuhle vymoženost zrušili a vystačí si se svěrací kazajkou?

[a.syntsow]

A ty si pepicky kokot. Staci ti to tak ? Ja som uviedol ciste fakty ty si tu zacal s obvinovanim ako klasicky retardovany cesky chuj dokaze len trollovat a pisat o ceskej gramatike v diskusiach.

[m-a]

Paneboze ty si oberchuj.

[Chytrex]

+1

[R]

Nie PT, ale RH. Ten vie vsetko najlepsie a pise megabajty kvalitneho kodu v PHP.

[msk]

Lol. Dokazes pochopit pisanemu textu? Ten blog bol mysleny ako ironia. Inak pocuj, pochadzam z jedneho pekneho stredoslovenskeho mesta, mame tam psychiatricku nemocnicu, je tam jazero, chovaju tam lamy. Ak chces, prihovorim sa tam za teba ...

[trekker.dk]

To asi není, ale ti, co jsou, se z nějakého důvodu stahují na abclinuxu.cz

[trekker.dk]

Neobsahuje vsak ani 1/3 z toho co grsec.

Je to už nějaký pátek, co tady někdo získal přístup k IRC, které ovládalo nějaký botnet složený ze zabordelených Linuxových strojů. Strojů s grsec jádrem tam bylo opravdu požehnaně, takže to asi nebude taková výhra, jak nám tady, pane odborník na všechno s.u.d., prezentujete.

[a.syntsow]

Ty si ultimatny retard. Na spustenie trapneho trapackeho IRC bota nepotrebujes UID 0 ale staci ti trapnotrapna PHP vuln s uid nobody.

[trekker.dk]

Až na to, že ten bot jaksi měl kompletní přístup k těm strojům. Na to už asi uid nobody nestačí, že ne?

[a.syntsow]

Ako vies ze mal ? Ako vies ze admin nebol retardovany a nejednalo sa o toto ?

jeden nejmenovany server v jedne nejmenovane instituci, roztomile zafirewallovany a pouzivajici grsecurity. diky bugu v cyrrus imapd a exploitu pouzivajicim tuto techniku remote root. ale ouha, pseudo-root nemuze psat do /bin a nemuze browsovat /home. ovsemze grsecurity a jeho access listy. ale jelikoz sitovy demon byl v grupe s ostatnima co muzou pouzivat raw sockety nebyl problem nahodit 7350ssharp a zachytavat a presmerovatat ssh sessny nekam jinam :) pak uz jenom staci pockat az se logne root a da nam password od gradm :) takze ackoliv jsou tyto patche mocne nastroje, neni to nic platne jsou-li v rukou hlupaku co si je ani nevi poradne nastavit.

Citujem cloveka s pseudonymom sd, kupodivu cecha na ktoreho mozete byt hrdy pretoze patril / i k top blackhats.

[a.syntsow]

*so , *hrdi

Okrem toho konfiguracia grsec jadra je zlozitejsia.Potrebujes mat zapnute veci ako uderef aby si mohol povedat ze aha ano som v bezpeci. Ako mozes vediet ako bolo jadro nakonfigurovane aby si toto tvrdil ? GRSEC JE ETANOL BEZPECNOSTI PRETOZE TI LUDIA VEDIA CO ROBIA. ONI NEFIXUJU BUGY, ONI FIXUJU TECHNIKY.

[trekker.dk]

Zaseknul se ti caps lock. Ale to je dobrý, pan doktor přinese prášek, utře z monitoru pěnu, která ti létá od úst, a caps lock uvolní.

A jestli je grsec takový etanol bezpečnosti, tak jaktože tolik strojů s ním jde tak snadno napadnout?

[R]

Kolko toho ETANOLU si vypil?

[lyon]

> GRSEC JE ETANOL BEZPECNOSTI

Alkohol je metlou nejen lidstva? :o)

[trekker.dk]

Ako vies ze admin nebol retardovany a nejednalo sa o toto ?

Jak vím, že se nejednalo o to, co cituješ? Fakt snadno, jako duševní cvičení si domysli, jak je to možné...

[jk001]

Aby to úplně nezaniklo v záplavě těch splašků, kterými nás tu oblažujete...

SELinux kupříkladu řeší přesně tohle (tj. impad si prostě nemůže dovolit bind na nějaký divný porty nebo raw sockety).

Ono to totiž předně chce nebýt fanatik a diskutovat k věci. Pokud Vám tu všichni přijdou retardi, možná bude na čase schovat to zrcadlo :).

Mám takový pocit, že většina lidí, které tu zmiňujete, by s Vámi nechtěla mít nic společného. Váš boj :). I tak přeji pěkný den.

[Chytrex]

Vy dvaja ste retardovani pepici. Bez vseobecneho rozhladu v security.

Tak teď si jim to nandal.. a úplně shodil svůj post..

1) Pipacs si vybral cestu anonyma 2) Implementacia ASLR v MS, vo vanilla linuxe je ZLA ! To je cisty fakt. To ze ty si jebnuty pepicek je vec dalsia. 3) Selinux je ubohost oproti PaXu. Selinux je prachsprosty MAC ktory v poslednom case vykrada viac a viac PaX. Neobsahuje vsak ani 1/3 z toho co grsec. Pouziva LSM, neriesi arbitrary RWX bugy v kerneli ani infoleaky. Exec Shield je na smiech. 4) Na bugy ktore boli zamlcane existovali exploity, neboli vydane ziadne advisory, CVEcka

Cituj nějaký důvěryhodný zdroj...

Prazdny pepik s mastnymi vlasami robi najvacsi randal :)

Opět si jim to nandal a eště víc si zdiskreditoval svůj post.

[a.syntsow]

Dovryhodny zdroj ? ROFL.

[Chytrex]

že ty sis zas nevzal prášky?:D Jesli chceš tvrdit že ten tvůj post byl důvěryhodný, tak spadnu ze židle smíchy..

[a.syntsow]

Ked sa pytas ako dement a nedokazes si najst odpoved na to co som povedal :). Vobec nemam chut vyhladavat a vypisovat ti tu linky a presne citacie ako dokazy.

[Chytrex]

Ty se snažíš nás přesvědčit že máš pravdu.. proč bych si měl hledat něco na netu kvůli někomu kdo má chování řeznického psa?

[msk]

Ale no tak, jedneho reznika poznam osobne, ma teda psov dvoch, ale ani jeden si taketo prirovnanie nezasluzi ...

[Chytrex]

Ok, Ok.. Omlouvám se psům inkriminovaného řezníka..:D Jen jsem nechtěl spadnout do žumpy, ze které píše "mistr" na kterého bylo reagováno:)

[Sten]

PaX není nic jiného než ochrana stránek obsahujících kód proti přepisování plus ASLR. To první uměl už DOS, potom se to nevyužívalo kvůli flat modelu a dneska na to máme NX bit. To ASLR v PaXu není moc kvalitní, samotný návrh je poměrně slabý a i pro Linux existuje kvalitnější (ExecShield). A třeba i ten windowsí ASLR je méně kvalitní jenom kvůli implementaci, ale návrh je daleko kvalitnější.

I PaX občas obsahuje chyby a to i třeba privilege escalation (tipuji, že kvůli tomu padlo spousta strojů s grsec jádrem). Picaps se z toho zhroutil a rozhodl se projekt předat někomu jinému. Ale nikdo o něj neměl zájem

SELinux se ochranou stránek v paměti nezabývá a daleko lépe implmenetuje least privilege principle.

Mimochodem v bezpečnosti je první pravidlo: nikomu nevěřit. A autorovi bezpečnostních knihoven už vůbec ne

[a.syntsow]

Prispievat na tento portal je ako sypat zlato do hovna. Tento server tvoria pseudocelebritky, skrachovani studenti, homosexuali a pepici.

[kyytaM]

Do ktorej kategorie sa radis? :) Je mozne aj clenstvo vo viacerych kategoriach naraz?

[a.syntsow]

Ano ako typicky priklad spolukokota (suhlasi s masou kedze nema ziadny vlastny nazor) ta mozem zaradit do vsetkych kategorii.

[kyytaM]

Ty si jeden z tych slobodomurarskych zidov, co odpalil dvojicky a priviedol Grecko ku krachu?

[a.syntsow]

Ano a som ficovolic.

[kyytaM]

:D Davam 10 z 10. :D

[m-a]

Aj si sa pri pisani odbavil? Bude aj "Rez a rubaj do krve, nebude to poprve", ci "Cesi pesi do Prahy" a podobne hity?

[R]

Zlato tu ziadne nevidim, ale hovna je tu dost. Najma v tvojich "prispevkoch".