Po 26 letech od protiprávního policejního zásahu, který byl spuštěn na základě podnětu společnosti Microsoft, Obvodní soud pro Prahu 2 rozsudkem potvrdil, že Mironet prokázal významnou část svého nároku na náhradu škody vůči Ministerstvu spravedlnosti ČR. Soudem nyní přiznaná část nároku znamená rekordní odškodné, jaké kdy české soudy přiznaly za nesprávný postup státu. Spor byl rozdělen na několik škod, u pravomocně uzavřených částí
… více »Lehké desktopové prostředí LXQt bylo vydáno ve verzi 2.4.0. Jde o převážně opravné vydání s drobnými vylepšeními podpory Waylandu.
Počítačová hra Kingdom Come: Deliverance 2 českého studia Warhorse získala cenu BAFTA v kategorii nejlepší příběh. V konkurenci pěti dalších nominovaných děl porazila i úspěšnou francouzskou hru Clair Obscur: Expedition 33, která v letošním ročníku získala cenu za nejlepší hru roku.
Projekt KDE oslaví v říjnu 30 let. Matthias Ettrich poslal 14. října 1996 do diskusní skupiny comp.os.linux.misc zprávu, která započala historii projektu. Důležité milníky jsou zobrazeny na časové ose KDE.
Byly vyhlášeny výsledky letošní volby vedoucí/ho projektu Debian (DPL, Wikipedie). Poprvé povede Debian žena. Novou vedoucí je Sruthi Chandran. Letos byla jedinou kandidátkou. Kandidovala již v letech 2020, 2021, 2024 a 2025. Na konferenci DebConf19 měla přednášku Is Debian (and Free Software) gender diverse enough?
Byla vydána nová verze 10.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přidána byla podpora Orange Pi 4 LTS. Přibyl balíček Prometheus.
Implementace VPN softwaru WireGuard (Wikipedie) pro Windows, tj. WireGuard pro Windows a WireGuardNT, dospěly do verze 1.0.
V Pekingu dnes proběhl 2. ročník půlmaratonu humanoidních robotů. První 3 místa obsadili roboti Honor Lightning v různých týmech. Nový rekord autonomního robota je 50 minut a 26 sekund. Operátorem řízený robot to zvládl i s pádem za 48 minut a 19 sekund. Řízení roboti měli časovou penalizaci 20 %. Před rokem nejrychlejší robot zvládl půlmaraton za 2 hodiny 40 minut a 42 sekund. Aktuální lidský rekord drží Jacob Kiplimo z Ugandy s časem 57 minut a 20 sekund [𝕏].
Stanislav Fort, vedoucí vědecký pracovník z Vlčkovy 'kyberbezpečnostní' firmy AISLE, zkoumal dopady Anthropic Mythos (nový AI model od Anthropicu zaměřený na hledání chyb, který před nedávnem vyplašil celý svět) a předvedl, že schopnosti umělé inteligence nejsou lineárně závislé na velikosti nebo ceně modelu a dokázal, že i některé otevřené modely zvládly v řadě testů odhalit ve zdrojových kódech stejné chyby jako Mythos (například FreeBSD CVE-2026-4747) a to s výrazně nižšími provozními náklady.
Federální návrh zákona H.R.8250 'Parents Decide Act', 13. dubna předložený demokratem Joshem Gottheimerem a podpořený republikánkou Elise Stefanik coby spolupředkladatelkou (cosponsor), by v případě svého schválení nařizoval všem výrobcům operačních systémů při nastavování zařízení ověřovat věk uživatelů a při používání poskytovat tento věkový údaj aplikacím třetích stran. Hlavní rozdíl oproti kalifornskému zákonu AB 1043 a kolorádskému SB26-051 je ten, že federální návrh by platil rovnou pro celé USA.
Jádro je 2.6.36 je venku, vydáno bylo 20. října, přičemž od předverze 2.6.36-rc8 došlo jenom k málo změnám. Mezi hlavní vlastnosti této verze patří bezpečnostní modul AppArmor, subsystém pro infračervené ovladače LIRC a nová architektura Tile. Na poslední chvíli byl vypnut mechanismus fanotify sloužící aplikacím pro boj s malwarem; objevily se záležitosti týkající se ABI. Spoustu informací naleznete na stránce o 2.6.36 na KernelNewbies.
Linus také poznamenal, že dva týdny dlouhé začleňovací okno, které začne 21. října, by kolidovalo s jaderným summitem.
(Vývojový cyklus 2.6.36 trval 80 dní, což je shodou okolností téměř přesný průměr za posledních několik let.)
Předtím bylo 15. října vydáno 2.6.36-rc8. Opravdu to dělám nerad a raději bych prostě vydal 2.6.36, ale místo toho vydávám ještě poslední -rc. Je tu (a v nevyřízených mailech) příliš mnoho ruchu, ze kterého nejsem šťastný, a i když jsem si nejprve myslel, že vydání jenom o den nebo dva zpozdím, teď už to vypadá na celý týden, takže proto další -rc.
Stabilní aktualizace: během uplynulého týdne žádné nevyšly.
-- Al Viro
napsal Jonathan Corbet, 20. října 2010
Sada patchů pro škálovatelnost VFS Nicka Piggina je ve vývoji již více než rok. Některé kousky byly začleněny do 2.6.36, ale složitější části byly odloženy, protože si Nick myslel, že potřebují ještě více práce a testování. Pak věci utichly, Nick změnil zaměstnání a jel na dovolenou, takže po nějaký čas se moc nedělo. Nakonec bylo jasné, že Nick pravděpodobně nestihne do začleňovacího okna 2.6.37 patche dokončit.
Proto se David Chinner rozhodl vložit se do toho sám a na těchto patchích zapracovat; konkrétně se věnoval kódu, který rozbíjí zámek inodů na menší části. Jeho první sada patchů byla zaslána koncem září, od té doby následovalo mnoho revizí. Dave pracoval na rozdělení série patchů do menších a snáze revidovatelných kousků. Také vyjmul některé (pro něj) děsivější změny. Následné revize přivedly větší změny, ve verzi 5 se dočteme:
Podle Davea tato sada patchů pomáhá při problémech se škálovatelností, které pozoroval, a i další revidovatelé podle všeho mají názor, že patche začínají vypadat poměrně dobře.
Pak se ale vrátil Nick. I když uvítal nový zájem o práci na škálovatelnosti, netrvalo dlouho a naznačil, že ho nepotěšil směr, kterým Dave jeho patche posunul. Zaslal sérii patchů o 35 částech, o které doufá, že ji začlení; v daném mailu také rozvádí, proč se mu nelíbí Daveův alternativní přístup. Následující diskuze byla občas poněkud drsná, ale většinou se držela technických záležitostí.
Na co nedošlo, byl její závěr. K dispozici jsou dvě sady patchů; obě se týkají průniku vrstvy virtuálního souborového systému a kódu správy paměti. Většina neshod se podle všeho týká toho, jestli by poslední slovo měli mít „lidé od VFS“ nebo „lidé od správy paměti“. Vzhledem ke složité povaze obou sad patchů a blížícímu se otevření začleňovacího okna 2.6.37 se zdá poměrně jasné, že začleněna nebude ani jedna, pokud se Linus nerozhodne, že jednu vybere sám. Odložení tohoto kódu do 2.6.38 poskytne příležitost, aby byly patche důkladně prodiskutovány; možná je bude možné probrat i na nadcházejícím Jaderném summitu.
napsal Jonathan Corbet, 20. října 2010
David Chinner si nedávno všiml problému na jednom ze strojů na kernel.org: slab cache používala více než 2GB paměti, většinu z toho na uzly radix stromu. To ho zaujalo a na problém se podíval blíže; ukázalo se, že na vině je bezpečnostní kód architektury pro ověřování integrity (integrity measurement architecture, IMA), který používá hardwarový TPM a pomáhá tak hlídat, že se soubory v systému se nemanipulovalo. IMA podle všeho používala radix strom, do kterého se ukládaly informace o integritě indexované podle adres inodů. Radix stromy se chovají mizerně, když obsahují řídké klíče, takže IMA způsobovalo vytváření samostatných uzlů pro každý inode v systému. Nasčítalo se to na spoustu paměti.
Z tohoto odhalení vzešlo mnoho otázek včetně následujících:
Odpověď na první otázku je podle všeho to, že když vývojáři IMA začleňovali kód do hlavní řady, nebylo jim povoleno rozšířit strukturu inodu. Proto vytvořili samostatný strom pro ukládání informací o jednotlivých inodech; stalo se, že si vybrali špatný strom a nikdy si nevšimli, jak špatně se choval.
Otázka č. 2 je zodpovězena takto: kód IMA potřebuje neustále sledovat to, které soubory jsou otevřeny pro zápis. Nemá cenu kontrolovat integritu souborů (v podstatě to znamená počítání kontrolních součtů), když je možné je kdykoliv změnit. Bez nepřetržitého sledování souborů IMA nikdy nemůže vědět, které soubory byly otevřeny po zápis, než se nastartovala. Jediný způsob, jak lze mít jistotu, je podle všeho sledování všech souborů od nabootování pro případ, že někdo bude chtít IMA v nějakém okamžiku zapnout.
Co se č. 3 týče, kernel.org používá jádro z Fedory a lidi z Fedory tuto vlastnost zapnuli, protože to vypadalo, že by mohla být pro někoho užitečná. Nikdo neočekával, že bude mít takové dopady na ty, kdo ji nepoužívají. Někteří diskutéři správcům jádra ve Fedoře vytkli, že kód nebyl prověřen před zapnutím, ale prověřit takto bedlivě všechno v jádře je příliš velký úkol na to, aby se dalo očekávat, že se ho Fedora ujme.
Eric Paris začal pracovat na zeštíhlení IMA; jeho patch funguje tak, že čítače „otevřeno pro zápis“ přesouvá přímo do struktury inode, takže většinou není potřeba alokovat samostatné IMA struktury. IMA také začala používat červeno–černé stromy tam, kde tyto struktury potřebuje sledovat. Tato práce odstraňuje většinu plýtvání pamětí za cenu toho, že se struktura inode trochu zvětšuje. To úplně všem nesedlo, obzvláště těm vývojářům, kteří mají pocit, že by IMA vůbec nemělo existovat. Je to ale krok správným směrem, takže lze očekávat, že něco na daný způsob bude začleněno do 2.6.37.
napsal Jonathan Corbet, 19. října 2010
Rychlé prohledání CVE databáze ukáže za tento rok 80 CVE čísel spojených s chybami v jádře. Na jedné z nedávných konferencích se autor tohoto článku svěřil významnému vývojáři jádra, že toto číslo považuje za znepokojivě vysoké. V době, kdy zjevně narůstá komerční, kriminální i vládní snaha o to zneužít bezpečnostní slabiny, by bylo dobré se hodně snažit vyhnout se zatahování nových. Mohli bychom ale dělat více, než děláme teď? Odpovědí, které se autorovi článku dostalo, je to, že v podstatě většina odhalených chyb byly prastaré záležitosti, které byly odhaleny novými nástroji pro statickou analýzu. Jinými slovy opravujeme bezpečnostní problémy rychleji, než je vytváříme.
Toto tvrzení potřebuje ověřit; ověřit ho musí někdo, kdo je dostatečně odhodlán a je dostatečně odolný vůči frustraci. Autor se rozhodl, že to zkusí. „Všechno“, co je zapotřebí, je koneckonců jenom podívat se na každou slabinu a zjistit, kdy byla zavlečena. Jak těžké to může být?
Základní postup tedy byl: vybrat CVE záznam, najít patch, který díru opravil, a pak se prohrabat historií repozitáře a dalšími zdroji a zkusit zjistit, kdy byl problém do jádra poprvé zavlečen. V některých případech bylo relativně snadné najít odpověď; jiné byly dost složité na to, aby to autor nakonec vzdal. Ukázalo se, že jedním z obzvláště cenných zdrojů je bugzilla Red Hatu; vývojáři (hlavně Eugene Teo) tam důsledně pracují na dokumentaci detailů bezpečnostních slabin. Někdy dokonce commit, který chybu zavlekl, byl v daném záznamu jednoduše zmíněn. Pro tento druh výzkumu je užitečná i utilita „git gui blame“.
Takto bylo prozkoumáno přibližně 60 z 80 chyb, pak autor článku definitivně obrátil oči v sloup. Výsledky lze vidět v následující tabulce. Je třeba říci, že v datech níže nevyhnutelně budou nějaké chyby; nejpravděpodobnější chybou bude obvinění commitu, který slabinu ve skutečnosti pouze přesunul z jiného místa. To může vést k posunu, kdy budou slabiny vypadat mladší, než ve skutečnosti jsou. Snaha tu byla, data by neměla být chybná nijak významně.
Další poznámky týkající se tabulky:
Nedošlo k žádnému pokusu najít původce slabin, které byly přítomny již v commitu, jenž zahájil éru gitu během vývojového cyklu 2.6.12. O všem, co tam již bylo tou dobou, lze bezpečně říci, že je to stará chyba.
Některé části kódu se měnily tak často, že by bylo opravdu těžké zjistit, kdy byla slabina zavedena; taková místa autor označil jako „neznámo“. Správnou odpověď by pravděpodobně bylo možné určit dělením půlením [bisecting] a testováním exploitů, ale odhodlání autora nebylo tak silné.
Některé z těchto chyb jsou staré jiným způsobem – CVE-2010-1188 bylo opraveno roku 2008, ale až roku 2010 se zjistilo, že se jednalo o bezpečnostní chybu. Každý, kdo používá aktuální jádro, je v bezpečí, ale takové chyby snadno po dlouhou dobu zůstávají v enterprise jádrech.
Pohled na to, kdy byly slabiny zavedeny, ukazuje následující tabulka:
![[Bezpečnostní slabiny v jádře]](http://www.lwn.net/images/2010/kernel-vulnerabilities.png)
V jistém smyslu měl tedy výše zmíněný hacker jádra pravdu – spousta slabin opravených v uplynulém roce je z doby před érou gitu a jsou tedy více než pět let staré. Zdá se, že bezpečnostní chyby mohou v jádře číhat velmi dlouho, než o ně někdo zakopne – nebo přinejmenším, než je někdo nahlásí.
Podle informací uvedených výše jsme od 2.6.33 opravili tucty slabin, aniž bychom nějakou zavlekli. Platnost druhé části tohoto tvrzení nicméně pravděpodobně nevydrží dlouho – v cyklu 2.6.35 bylo opraveno (přinejmenším) 13 slabin, v 2.6.36 to bylo 21. Můžeme doufat, že jsme jich ve stejné době přidali méně; je nicméně jisté, že 1) jejich počet nebude nulový a 2) pravděpodobně nám bude trvat pět nebo více let, než si jich všimneme.
Může nás trochu utěšit, že velká část známých bezpečnostních chyb z roku 2010 není důsledkem vývoje z roku 2010. Ve skutečnosti, když budeme předpokládat, že některé z chyb jsou ještě starší, můžeme také tvrdit, že nejsou důsledkem „nového“ modelu vývoje jádra, který byl přijat v prvních dnech 2.6. Toto tvrzení by bylo možné ověřit výzkumem dat z éry BitKeeperu; to je ale úkol do budoucna.
Autor článku má nicméně nadále obavy z toho, že je příliš jednoduché vložit do jádra nebezpečný kód a je příliš těžké odhalit slabiny, které byly vytvořeny. Analytické nástroje mohou pomoci, ale když dojde na to udržet slabiny mimo jádro, rozhodně nejsou náhradou pro nudné a únavné revize kódu. Čas od času je zjevné, že revidování není natolik intenzivní, jak by mělo být. Snadno může přijít den, kdy si budeme přát, abychom bývali byli opatrnější.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
netbsd a openbsd maju podobne resp. nizsie pocty (ako freebsd). je vsak pravda, ze maju hodne mensi pocet riadkov ako linux.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz