Microsoft oznámil, že WSL kontejnery (WSLC) aneb linuxové kontejnery ve Windows Subsystem for Linux (WSL) jsou již obecně dostupné. Současně popsal jejich architekturu.
openSUSE Leap 16.1 vstoupil do RC fáze. Nově lze instalovat jako standardní systém (Standard) nebo jako neměnný systém s atomickými aktualizacemi (Immutable). Samostatná neměnná distribuce openSUSE Leap Micro končí.
Byl vydán Mozilla Firefox 157.0. S nejvýraznější vizuální proměnou za poslední roky. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 157 bude brzy k dispozici také na Flathubu a Snapcraftu.
Rodina produktů Raspberry Pi se rozšířila o Raspberry Pi Smart Display Module. Deska pro Raspberry Pi Compute Module 5 se zasouvá přímo do displejů dle specifikace Intel SDM. Cena desky je 30 dolarů.
Byla vydána nová verze 2.56.0 distribuovaného systému správy verzí Git. Přispělo 104 vývojářů, z toho 39 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Hackerská skupina ShinyHunters oznámila průnik do informačních systémů FBI, prostřednictvím zero-day zranitelnosti v platformě Oracle PeopleSoft, kterou úřad využívá mimo jiné pro náborový portál FBIJobs.gov. Útočníci tvrdí, že získali až 3 TB dat o současných i bývalých zaměstnancích a uchazečích o práci. Jako důkaz zveřejnili vzorek přibližně 5 000 záznamů obsahující jména, adresy, telefonní čísla, data narození, čísla
… více »Doba kompilace linuxového jádra se díky rychlejšímu hardwaru a optimalizacím kbuildu snižuje k deseti sekundám. Nejnovější patche Lorenza Stoakse (vznikají i s pomocí SI) zkrátily na testovacím stroji dobu sestavení z dlouhých 22 vteřin na pouhých 15, a to bez použití RAMdisku. Testovací systém tvořily dva procesory AMD EPYC 9575F (oba dohromady poskytují celkem 128 jader a 256 vláken), čtyřiadvacet 64GB DDR5-6400 paměťových modulů a
… více »Před rokem a půl vývojáři postmarketOS informovali, že pro projekt hledají nové jméno. Včera bylo oznámeno: postmarketOS se nově jmenuje Nura.
Hra Factorio dorazila na Printables. Hned teď si můžete stáhnout 65 různých modelů a nechat celou mimozemskou planetu oživnout na svém stole.
GNU Project Debugger aneb GDB byl vydán ve verzi 18.1. Podrobný přehled novinek v souboru NEWS.
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