Jaderné noviny – 6. 10. 2011: Kernel.org se postupně vrací

17. 10. 2011 | Luboš Doležel

Články - Jaderné noviny – 6. 10. 2011: Kernel.org se postupně vrací  

Aktuální verze jádra: 3.1-rc9. Citáty týdne: Alan Cox, Chris Mason, Ted Ts'o, Valdis Kletnieks. Lepší jádra s pluginy GCC. Na cestě kernel.org k uzdravení.

Obsah

• Aktuální verze jádra: 3.1-rc9
• Citáty týdne: Alan Cox, Chris Mason, Ted Ts'o, Valdis Kletnieks
• Lepší jádra s pluginy GCC
• Na cestě kernel.org k uzdravení

Aktuální verze jádra: 3.1-rc9

Aktuální vývojová verze jádra je 3.1-rc9 vydaná 4. října. Repozitář je na svém starém místě na kernel.org; Linus začal také s tímto vydáním používat nový podpisový klíč. Co se jádra týče, tak nedošlo k mnoha změnám. Tak či tak by jich moc být nemělo – a určitě by mi nevadilo, kdyby jich bylo ještě méně. Ale obecně jde o docela malé změny a diffstat opravdu nevypadá moc strašidelně – nikde tam nejsou opravdu *velké* změny.

Stabilní aktualizace verze 3.0.5 byla vydána 3. října s více než 200 důležitými opravami; byla okamžitě následována verzí 3.0.6, aby byl opraven problém s ovladačem Radeon.

Citáty týdne: Alan Cox, Chris Mason, Ted Ts'o, Valdis Kletnieks

Jednoho dne někdo napíše něco, co nahradí linuxové jádro. Ještě předtím by pravděpodobně někdo měl opravit nebo nahradit C, aby mělo vestavěnou schopnost popsat zamykání a staticky vynucovat některá pravidla zamykání při kompilaci. Jsem si jistý, že má generace programátorů bude výsledným jazykem opovrhovat, ale časem budeme autorovi děkovat, ať už jím bude kdokoliv.

-- Alan Cox

V Oracle jsme se rozhodli udělat btrfs výchozím souborovým systémem pro Oracle Linux. Jde to zatím do fáze beta a naše produkční nasazení btrfs budeme během příštích čtyř až šesti měsíců rozšiřovat... To znamená, že se bez btrfsck rozhodně nemůžeme nikam pohnout. Firmy RH, Fujitsu a SUSE nad tímto souborovým systémem strávily spoustu času a už je jednoznačně čas jej začít dávat do rukou zákazníkům.

-- Chris Mason

Berte ohled na to, že pokud váš laptop akceptuje příchozí ssh spojení a jste k master.kernel.org připojeni s povoleným forwardováním portů, váš laptop nemusí být v bezpečí. Takže buďte opravdu, opravdu opatrní, než začnete předpokládat, že je. Nejméně jeden jaderný vývojář, jakmile překonal své přesvědčení „rozhodně mi nikdo můj stroj nemohl napadnout“, důkladně prozkoumal situaci a našel na svých strojích rootkity.

-- Ted Ts'o

Co se komunity linuxového jádra týče, tak důležitou věcí je, že ten člověk, kterého vídáme na konferencích a pořád tam něco prezentuje, *je* Andrew Morton, i když jeho pravé jméno je George Q. Smith a je už 27 let na útěku kvůli jednomu trapnému incidentu s pštrosem, starostovou dcerou a 17 galony minerálního oleje v atriu muzea.

-- Valdis Kletnieks

Lepší jádra s pluginy GCC

Článek o pluginech pro GCC z posledního týdne vyvolal komentář „PaXTýmu“ ohledně používání pluginů v projektu PaX. Zdá se, že si vyvinuli sadu pluginů, které jim pomáhají se zabezpečováním jádra. Zmiňované pluginy je obtížné najít; váš redaktor je našel v „testovací“ sadě patchů grsecurity. Vypadá to, že jsou čtyři, přičemž každý z nich má na kompilaci jiný vliv:

• Struktury, které obsahují pouze ukazatele na funkce, jsou změněny na konstantní, i když tak nejsou deklarovány. Samozřejmě se ukázalo, že v mnoha případech to není správná věc, takže vývojáři museli zavést atribut no_const a ve svém patchi jej na nějakých 180 místech použít.
• Je generován histogram rozložení velikostí předávaných funkci kalloc(); (vašemu redaktorovi) není moc jasné, k čemu je tato informace používána.
• Pro procesory AMD je v generovaném assembleru dělána řada sofistikovaných triků, aby se zlepšila ochrana proti spouštění jaderných dat.
• Do zásobníku jádra je vložena instrumentace pro sledování jeho využití.

Používání pluginů tímto způsobem umožňuje udělat v jádře rozsáhlé změny, aniž by se musel měnit samotný kód:

Abych vám dal nějaká čísla, tak jádro allmodconfig 2.6.39 i386 přichází o více než 7000 statických (tzn. ne alokovaných za běhu) zapisovatelných ukazatelů na funkce (redukce o cca. 16 %). Rovnocenný patch by měl tisíce řádek kódu a prakticky by nebyla šance, aby byl v rozumném čase přijat.

Na druhou stranu pluginy tohoto typu mohou oddálit to, co se v jádře provádí, od kódu, který člověk vidí; není těžké si představit, že by to pak někdy mohlo doopravdy vývojáře zmást. PaXTým přesto říká, že poměr následků/prospěšnosti řešení pomocí pluginů je špičkový a ještě víc se toho chystá. Není těžké si představit další množnosti využití, která by se nemusela nezbytně týkat bezpečnosti.

(Vtipné je, že pluginy jsou pod licencí GPLv2, což znamená, že se na ně nevztahuje výjimka runtimové knihovny GCC. Jádro tuto knihovnu ale nepotřebuje, takže všechno je v pořádku.)

Na cestě kernel.org k uzdravení

31. srpna světem proběhla zpráva, že primární repozitář pro jaderný kód v různém stádiu vývoje byl napaden – ačkoliv vývojáři s přístupem k serveru byli informováni několik dnů předem. Server byl v době, kdy byla informace publikována, mimo provoz „z důvodu údržby“, což nechalo komunitu bez důležitého místa pro hosting a distribuci. Následkem toho vývoj jádra zpomalil; jádro 3.1, které už mělo touto dobou vyjít, je nadále nevydané. Kernel.org je na cestě k uzdravení, ale už to určitě nikdy nebude to samé místo.

3. října se navrátilo základní kernel.org. Vrátil se i hosting Gitu, ale jen pro velmi malý počet stromů: hlavní řada, stabilní a linux-next. Návrat ostatních stromů je závislý na tom, kdy relevantní vývojáři získají k serveru opět přístup – což je proces, který vyžaduje, aby si vývojáři zkontrolovali integritu vlastních systémů, pak si vygenerovali nový PGP/GPG klíč, zaintegrovali jej do sítě důvěry [web of trust] a předali veřejný klíč správcům kernel.org. Tento postup může chvíli trvat; není jisté, kolik vývojářů bude moci získat zpět přístup ke kernel.org, než se otevře začleňovací okno pro verzi 3.2.

Úvodní stránka webového rozhraní je zpět, i když v této době není aktualizován stav git stromů. Většina ostatních služeb kernel.org zůstává mimo provoz; tak to může ještě nějakou dobu zůstat. Stojí za to vědět, že kernel.org má jen jednoho administrátora na plný úvazek, což je pozice hrazená Linux Foundation od roku 2008. Tento správce, spolu s řadou dobrovolníků, bude mít dost práce, takže méně důležité služby se nemusí vrátit brzy.

Nějaký čas potrvá, než plně pochopíme, k čemu došlo. I když nebylo zveřejněno úplné hlášení o tomto napadení, můžeme učinit některé závěry. První je zjevný: riziko je reálné. Na světě jsou útočníci s časem, prostředky, motivací a schopnostmi. Vzhledem k potenciální hodnotě, jakou pro útočníka představuje umístění backdooru (zadních vrátek) do jádra nebo přidání trojanu, který by běžel na strojích vývojářů, musíme předpokládat, že v budoucnosti budou další útoky. Pokud by kernel.org nebylo více zabezpečeno, bylo by brzy znovu napadeno.

Administrátoři už oznámili, že shellové účty k systémům, kde jsou hostovány gitové stromy, se nevrátí zpět. Před napadením jich bylo řádově 450; to představuje velké množství klíčů od hlavních dveří. Nezávisle na tom, jak opatrní vývojáři jsou – a ne všichni jsou stejně opatrní – se šance, že má někdo z nich napadený stroj, blíží ke 100 %. Zrušení všech shellových účtů je důležitým krokem ke zvýšení bezpečnosti.

Kernel.org má své kořeny v komunitě a bylo provozováno způsobem, jakým vývojáři jádra často provozují své vlastní stroje. Takže kernel.org například často používalo -rc jádra – což může být hezkou ukázkou dogfoodingu (používání vlastních produktů), ale zároveň to vystavovalo systém nejčerstvějším chybám, a ještě závažnější věcí je to, že to zakrylo skutečný důvod kernel panicků, které se staly v srpnu, což zavinilo, že průnik byl odhalen později. Zatím nebylo oznámeno, jaké jádro běží na nových systémech, ale člověk by asi předpokládal, že to bude něco lépe testovaného, podporovaného a stabilního. (Toto není kritika. Kernel.org bylo pod dlouhou dobu dobře spravováno; smyslem je to, že prostředí se změnilo, takže by se měly změnit i zvyky.)

Nyní se zdá být jasné, že jediný administrátor pro takto významný server není adekvátním množstvím. Vzhledem k množství prostředků, které jsou v komunitě k dispozici, se zdá, že by mělo být možné zvýšit množství podpory věnované kernel.org. Říká se, že se na tom pracuje, ale nic ještě nebylo oznámeno.

Vývojáři se budou muset naučit věnovat více pozornosti bezpečnosti vlastních systémů. Objevují se nahodilá hlášení o vývojářích, kteří hlásí, že měli napadený systém; v některých případech mohli být nakaženi následkem přehnané důvěry v kernel.org. Některé zvyky se budou muset změnit; z tohoto důvodu je oznámení projektu Fedora o nulové toleranci k soukromým klíčům na systémech Fedory vítáno. Vývojáři jsou zde první linií: všichni závisí na tom, že udrží svůj kód – a infrastrukturu, která tento kód šíří – bezpečnými.

S tímto souvisí zajímavá otázka: kteří jaderní vývojáři se vrátí na kernel.org? Vývojáři si během výpadku museli najít nové domovy; je pravděpodobné, že se někteří z nich rozhodnou nechat repozitáře na nové adrese a bude to pro ně snazší, než aby museli ověřovat svou identitu v síti důvěry [web of trust] a vracet se zpátky na kernel.org. Linus jednou řekl, že vnímá přítomnost repozitáře na kernel.org v požadavku o přetažení jako známku větší důvěryhodnosti. Nezdá se být pravděpodobné, že by bylo v komunitě toto vyžadováno. Není úplně jasné, jestli představuje rozmístění repozitářů po celém Internetu nějaké bezpečnostní riziko pro jádro, nebo jestli by složení všech vajec do jaderného hnízda bylo horší.

Jeden závěr, který bychom teď mohli udělat je to, že existuje řada jiných důležitých projektů a hostingů. Je stejně pravděpodobné, že se stanou cílem útoku, jako se stalo kernel.org. Pokud se nemá přihodit dlouhá řada trapných napadení, s nepříjemnými důsledky u některých z nich, budeme muset všude brát větší ohled na bezpečnost. Bude přinejmenším těžké to udělat, aniž bychom zničili otevřenost naší komunity, ale musíme se do toho pustit. Bezpečnost je trápení, ale ještě horší je, když se vám někam vlámou a využijí vás k útoku na vaše vývojáře a uživatele.

Diskuse k tomuto článku

[HrabalVojta]

Akorát jsem se chtěl zeptat, z kterého data to je ... a mám pocit, že 10.6 to určitě není, článek o napadení vyšel dřív než napadení samotné

[Michal]

10/6/2011 - takže 6. října .. ach ti američani.

[David Watzke]

Díky, opraveno.

[Luboš Doležel (Doli)]

Vida, už přepisuju October 6 jako 10/6, to je vážný.

[vain]

Však to je správně ne? =)

[Sten]

Správně je 10-6, ISO datum používá lomítka pro intervaly a opakování

[Ondrej 'SanTiago' Zajicek]

Spravne je 2011-10-06, ISO 8601 neumoznuje vynechat uvodni rok (a ani 0 pred 6).

[Bedňa]

Tento zápis je výborný na triedenie od najnovšieho k najstaršiemu, používam ho na weboch aj na zálohovanie, je to easy.

[vain]

Jen nesmíš zapomenou, co je den a co měsíc

[Bedňa]

Však práve že musíš mať dáta vždy vo formáte YYYY-MM-DD a keď ich dáš zoradiť, máš ich pekne podľa rokov, potom podľa mesiacov a tiež podľa dní v mesiaci, fakt naj "čitateľný" formát v kompiš svete.

[David Jaša]

Holt big endian.

[Josef Kufner]

Lomítka se používají tam, kde píšou pořadí divně. Tedy: YYYY-MM-DD vs. MM/DD/YYYY vs. DD.MM.YYYY. Tohle rozpoznávání podle oddělovače funguje celkem spolehlivě, jen výjimečně se najde nějaké pako, které to píše jinak.

[Sten]

Třeba Francouzi, Španělé nebo Italové vás převezou

[Luboš Doležel (Doli)]

Vůbec nechápu, proč tam mají Češi jinou barvu než Slováci.

[Ladicek]

All hail Alan Cox!

[Sten]

Nesplnilo by požadavky Alana Coxe nové C++? Je to hodně podobné C, zamykání to umí dobře popsat i vynucovat a Alanova generace (hlavně Linus) tím jazykem opovrhuje už dlouho

[little.owl]

Nove C take ....

Pokud C++, tak Embedded C++.