Jaderné noviny – 12. 9. 2013: Utajování bezpečnostních chyb

30. 9. 2013 | Luboš Doležel

Články - Jaderné noviny – 12. 9. 2013: Utajování bezpečnostních chyb  

Aktuální verze jádra. Citáty týdne: robot, Paul McKenney. Začleňovací okno 3.12, část druhá. Na téma řešení bezpečnostních problémů v jádře.

Obsah

• Aktuální verze jádra
• Citáty týdne: robot, Paul McKenney
• Začleňovací okno 3.12, část druhá
• Na téma řešení bezpečnostních problémů v jádře

Aktuální verze jádra

Začleňovací okno verze 3.12 je stále otevřené, takže aktuálně není žádné vývojové jádro.

Stabilní aktualizace: verze 3.10.11, 3.4.61 a 3.0.95 všechny vyšly 7. září; verze 3.2.51 vyšla 11. září.

Citáty týdne: robot, Paul McKenney

Zbavování se spinlocků znamená více jader; stropem se bohužel zdají být čtyři jádra. Uživatelé musejí rozdělovat svůj čas mezi čtení historie a přispívání do současnosti: jistý objem persistentních dat je nezbytností na každém stroji uživatele. Zdá se, že pixely míří špatným směrem: to je to, co nás znervózňuje.

-- Vypadá to, že na linux-kernel někdo vypustil robota.

Tak schválně, jestli si vybavím všechny kandidáty...

rcu_je_cpu_nečinné() # opačný význam než ostatní
rcu_je_ignorováno() # opačný význam než ostatní
rcu_je_neaktivní() # opačný význam než ostatní
rcu_sleduje_cpu()
rcu_kontrola_čtení()
rcu_je_aktivní()
rcu_je_aktivní_lokálně()
rcu_je_online()
rcu_sleduje_úlohu()
rcu_sleduje_vlákno()
rcu_sleduje_vás()
all_your_base_are_belong_to_rcu()
rcu_je_aktivní_magor()
rcu_byl_jsem_tu_kilroy()

Možná bych je měl přes noc všechny zamknout v nějaké místnosti a ráno by se uvidělo, kdo přežil.

-- Paul McKenney má problém s pojmenováním.

Začleňovací okno 3.12, část druhá

V době psaní tohoto textu bylo do hlavní řady pro vývojový cyklus 3.12 přetaženo téměř 8500 neslučovacích sad změn; téměř 5000 od minulého přehledu. Proces se při selhání Linusova hlavního disku poněkud zpomalil, ale ani selhání hardwaru nemůže vývoj jádra na dlouho zastavit.

V tomto vývojovém cyklu se nadále nachází mnoho velkých interních vylepšení a docela málo vzrušujících novinek. Mezi změny viditelné uživatelům patří:

• Vrstva pro přímé vykreslování má nyní „vykreslovací uzly“, které oddělují vykreslování grafiky od nastavování režimu a dalšího řízení obrazovky; všechny ovladače z „velké trojice“ toto podporují. Více se dozvíte v tomto zápisku od Davida Herrmanna.
• Subsystém netfilter podporuje nový cíl „SYNPROXY“, který simuluje vytvoření spojení na jedné straně firewallu dříve, než dojde k vytvoření spojení na druhé straně. Dá se to považovat za způsob, jak nasadit SYN cookies na perimteru, aniž by se nahodilé pokusy o připojení dostávaly přes firewall.
• Patche pro nastavování velikosti TSO a plánovač FQ byly začleněny. Nastavování velikosti TSO pomáhá odstranit rázy v síťovém provozu při používání TCP segmentation offload. FQ umožňuje jednoduché férové řazení do fronty pro provoz, který je směrován skrz systém.
• Systém souborů ext3 má novou připojovací volbu journal_path=, pomocí které je možné určit vnější umístění žurnálu za použití cesty k zařízení.
• Architektura Tile má podporu pro ftrace, kprobes a úplnou preempci jádra. Současně byla odstraněna podpora pro stará CPU TILE64.
• Systém souborů xfs už konečně podporuje uživatelské jmenné prostory. Přidání této podpory usnadní distributorům nabízet tuto funkčnost, kdyby jim snad nevadily bezpečnostní důsledky s tím spojené.
• Podpora pro systémy ARM „big.LITTLE“ se blíží; verze 3.12 bude obsahovat nový ovladač cpuidle, který je postavený na patchích pro mnohoclusterovou správu výkonu.
• Implementace MD RAID5 nyní běží ve více vláknech, což zvyšuje maximální rychlost I/O u rychlých disků.
• Mapovač zařízení [device mapper] má nový modul pro statistiku, který dovede sledovat I/O aktivitu na určitém rozsahu bloků na zařízení DM. Více najdete v dokumentaci.
• Kód pro strom zařízení nyní předává text celého stromu do zdroje náhodných čísel ve snaze zvýšit objem entropie dostupné při startu systému. Aktuálně není jasné, jak moc to pomáhá, protože stromy zařízení jsou často nebo zcela identické u každého typu zařízení. Je sice možné, aby ve stromu byla unikátní data – například síťové adresy MAC – ale to není zaručené a někteří vývojáři si myslí, že entropii by více pomohlo, kdyby se do ní dodávala přímo unikátní data.
• Podpora nového hardwaru.

Mezi změny viditelné vývojářům jádra patří:

• Správci paměti GEM a TTM uvnitř grafického subsystému nyní používají jednotný subsystém pro správu oblastí virtuální paměti, čímž se odstraňuje jistá duplicita kódu.
• Nový mechanismus lockref nyní může označit položku, pro kterou jsou počítány reference, jako „mrtvou“. Tento oddělený stav je potřeba kvůli tomu, že lockrefy mohou být používány na místech (jako dentry cache), kde může čítač referencí mít hodnotu nula, a přesto je položka při životě a použitelná. Jakmile je ale struktura označena za mrtvou, pak není možné čítač inkrementovat a strukturu používat.

Vypadá to, že k zavření začleňovacího okna dojde 15. září nebo snad o den později, aby se mohl Linus zase rozjet po svém návratu z víkendového potápění.

Na téma řešení bezpečnostních problémů v jádře

Hlášení a řešení bezpečnostních problémů je zrádná oblast. Vyvažuje se tu řada protichůdných zájmů a obecná snaha udržovat věci v tajnosti, která může věci ještě více komplikovat. Proto není překvapivé, že jaderní vývojáři debatovali o řešení bezpečnosti na mailing listu Jaderného sumitu (ksummit-2013-discuss). Je pravděpodobné, že debata bude pokračovat na sumitu jako takovém, který se bude konat v Edinburgu od 23. do 25. října.

Diskuzi zahájil James Bottomley upozorněním na to, že několik posledních oprav se dostalo do jádra bez dodržování řádného postupu, jelikož šlo o „bezpečnostní opravy“. Vzhledem k tomu, že některé z nich způsobily rozličné problémy, má obavy z obcházení procesů jen kvůli tomu, že se v patchi řeší bezpečnostní problém:

V obou případech jsme tu měli commity s tajuplným popisem, bez řádného vysvětlení a prakticky žádným revidováním, a to vše ve jménu bezpečnosti.

Naše základní procesy pro přijímání kódu vyžadují průhlednost, revidování a testování. Tajnůstkářství při přijímání kódu tedy zásadně tato pravidla porušuje a je rizikem, které vede k problémům právě takovým, jaké jsme v obou případech viděli.

Bottomley by rád věděl, jestli se musejí bezpečnostní problémy vůbec řešit potají. Protože si myslí, že toto není oblíbená věc, přemýšlení na téma, jak můžeme do proces určinit transparentnějším, by mohlo být rozumnou alternativou. Součástí jeho teorie je to, že lidé od bezpečnosti, kteří mají tajnůstkářství rádi, mají proces řešení zranitelností na starosti.

Například uzavřený mailing list pro bezpečnost v jádře (security@kernel.org) se buď skládá z „bezpečnostních funkcionářů“ (podle Documentation/SecurityBugs) nebo 'obyčejných' vývojářů jádra (podle Grega Kroah-Hartmana). Kroah-Hartman říká, že lidé na tomto mailing listu nemají žádný zájem na tajnůstkářství, i když souhlasil, že zveřejnění seznamu účastníků tohoto mailingu listu – ke kterému ještě nedošlo – by transparentnosti pomohlo. Vztah mezi bezpečnostním mailing listem a mailing listem linux-distros (uzavřený mailing list pro bezpečnostní obavy v distribucích – nástupce vendor-sec) je také trochu pochybný a hodilo by se ho veřejnosti objasnit, jak Bottomley řekl.

Velkou roli v celém problému hraje to, že je tu několik odlišných stran, které se tu snažíme uspokojit, a to včetně distribucí (některé z nich – jako ty enterprise – mohou mít dodatečné potřeby nebo požadavky), uživatelů (většina z nich dostává jádro od distributora nebo výrobce zařízení), bezpečnostních výzkumníků (kteří ze svých komářích nálezů někdy rádi dělají velbloudy) a tak dále. I když nás může lákat zavržení bezpečnostních výzkumníků jakožto pachatelů toho, čemu Linus Torvalds říká „bezpečnostní cirkus“, je důležité je zahrnout. Oni jsou těmi, kdo často zranitelnosti najdou; pokud je člověk naštve, tak to může často znamenat, že pak nebudou hlásit, co našli.

Tajnůstkářství při řešení zranitelností může být pro enterprise distribuce důležité i z jiných důvodů, jak Stephen Hemminger popisoval. Bezpečnostní zranitelnost a rychlost reakce jsou na těchto trzích často používány jako „obchodní“ nástroj, takže toto může vést k tlaku na větší utajení:

Připadá mi, že při utajování jde spíš o snahu vyhnout se senzačním zprávám od novinářů, které by konkurentům mohly posílit jejich FUD. U enterprise produktů tento typ FUDu může ovlivnit rozhodování při nákupu nebo dokonce finanční trhy.

Torvaldsův zvyk tajit bezpečnostní aspekty oprav v patchích zde také hraje roli. Snaží se zranitelnosti zamaskovat tak, aby je „black hati“ nemohli z logů commitů jen tak grepovat, ale jak James Morris podotkl, není to moc účinné: Tajuplné / ukryté opravy těm špatným jen nahrávají. Commity sledují a provádějí na nich bezpečnostní analýzu.

Je nepravděpodobné (i když ne úplně vyloučené), že Torvalds změní svůj pohled na věc, proto se objevovaly různé návrhy, jak shromažďovat bezpečnostní informace spojené s commity, které dané chyby opravily. Je jasné, že některé informace o bezpečnostních dopadech se dostanou ven jen po commitu – někdy až dlouho po něm – takže je nutné tyto informace schraňovat odděleně tak jako tak.

Kees Cook popsal informace, které by bylo možné shromažďovat, zatímco Andy Lutomirski na to navázal návrhem vytvářet oddělené soubory CVE uložené ve stromě jádra. Tento nápad si získal své příznivce; jiní přišli s návrhem spolupracovat s Debianem nebo účastníky mailing listu linux-distros. V odděleném vlákně pak Lutomirsi vytvořil šablonu jako návrh, jak by informace byly ukládány. Cook přitakával a navrhl, že tyto soubory by mohly být uloženy v Documentation/CVEs nebo tak nějak. Je jasné, že tu je zájem, aby bylo k dispozici více podrobností o zranitelnostech.

Někteří začali s otevřeností na vlastní pěst. Lutomirski nedávno zveřejnil opravu, která byla od začátku jasně označená jako bezpečnostní oprava. Cook udělal to samé u celé řady zranitelností v kódu pro HID. Zneužívání chyb v HID vyžaduje fyzický přístup a specializovaná zařízení, ale i to může pro některé uživatele představovat riziko. Toto nejsou první taková hlášení; i jiní to tak občas dělali. Pravdou je, že některé subsystémy (zejména síťová vrstva) vlastně nikdy nepoužívaly uzavřený mailing list a na bezpečnostních problémech a opravách raději pracují veřejně.

Čerstvějším příkladem pak budiž hlášení od Wannese Romboutse, který popsal bezpečnostní díru v síťovém kódu (používání paměti po uvolnění), který byl na mailing list netdev odkázán lidmi ze security@kernel.org. Dopady této chyby nebyly zcela jasné (ani Romboutsovi nebo Hemmingerovi, kteří odpověděli), ale Ben Hutchings viděl, že uživatelské jmenné prostory by mohly tento problém zhoršit. I když to má souvislost se sítí – proto asi to odkázání na netdev – toto je právě ten typ zranitelnosti, kterou bylo možné řešit za zavřenými dveřmi. Ale díky tomu, že podrobnosti byly zveřejněny, se podařilo odhalit všechny možné důsledky. Navíc ve všech případech pak ti, kterých se chyba dotýká, mají možnost se o problémech dozvědět a buď svá jádra opatchovat nebo jinak problém vyřešit. A to je další výhoda otevřenosti.

Diskuse k tomuto článku

[clayman]

Jo, s pojmenováváním mám problém taky. Občas bych potřeboval otroka, který by vedle mě seděl a jen říkal, jak co nazvat.

[j]

Ad bezpecnost ... musim se tomu leda od srdce zasmat - hrat si pri OS vyvoji na utajovani ...lol. Dovolim si tvrdit, ze k vetsine uzivatelu se nova/opatchovana verze (nejen) kernelu tak jako tak dostane az za dlouhy mesice - tedy davno po tom, co se o dire "vi", ale prave tim, ze se to tutla, je zpusobeno i to, ze nebohy admin ani netusi, ze ma deravej kernel.

Podle vseho se tedy staci soustredit na neokomentovany/narychlo vlozeny commity ... dobrej navod.

[petr_p]

To bych si nedovolil tvrdit. Například propírané chyby v HID šly do stabilního jádra v Gentoo v pátek. Do Fedory už 12. RHEL postižen není. Debian zatím opraven není. Do SLES se to už čtyři dny připravuje. Mandriva je opravena od čtvrtka.

[j]

To bych si tvrdit dovolil, gentoo je spis extrem, ale ani v gentoo nekompiluju novou verzi kernelu hned jak se objevi ani nahodou. A patchovat produkcni system ... lol ... rozhodne nehodlam riskovat, ze sice budu mit "naprosto bezpecny" ale zcela nefunkcni system.

Minimalne par tydnu je zaklad ... to se uz na webu a diskusich objevi dost zkusenosti ... a tak clovek aspon muze predpokladat, co vsechno se mu potencielne podela.

[pavlix]

Komu není rady...

[petr_p]

Tak příště nepiš takovou lež. Bezpečnostní aktualizace vyšly. Že jsou správci, jako ty, kteří aktualizace odkládají, je tvůj problém. Za to distributor nemůže.

[j]

Tak se hosanku laskave nauc cis ... pokud je nekdo negramotnej, nemel by lizt na net.

Pro tvoji informaci, zadnej normalni spravce nepatchuje naprosto nic, pokud to neni naprosto nezbytny. Narozdil od tvy domaci masiny, ktera kdyz mesic nepojede, tak maximalne dostanes par facek od rodicu, produkcni stroj stoji kazda minuta vypadku penize ... a to rozhodne ne maly penize. Bavime se o tisicich, ale klidne i milionech eur.

Nehlede na to, ze proc by mel neco patchovat, kdyz informace o dire se tutla, ze ...

[Jendа]

Tak se hosanku laskave nauc cis ... pokud je nekdo negramotnej, nemel by lizt na net.

Distributoři s podporou většinou backportují pouze opravu chyby, takže je menší šance, že se podělá něco naprosto nesouvisejícího (na rozdíl od upgrade).

Narozdil od tvy domaci masiny, ktera kdyz mesic nepojede, tak maximalne dostanes par facek od rodicu

OTOH, jsou stroje, kde je mnohem lepší, když nepoběží, než když je někdo zpwnuje přes děravý kernel.

produkcni stroj stoji kazda minuta vypadku penize ... a to rozhodne ne maly penize. Bavime se o tisicich, ale klidne i milionech eur

Hledal bych chybu v tom, že máš stroj, jehož výpadek bude stát tisíce a miliony eur za minutu. Normální člověk si kvůli takovým věcem postaví HA cluster.

[trekker.dk]

Normální člověk si kvůli takovým věcem postaví HA cluster.

Normální člověk možná, ale tady mluvíš se superdrsňákem, co oslovuje ostatní "hošánku", má superdůležitý stroje a absolutní pravdu o tom, kdo je to "normální" správce. (Přičemž podle všeho neumí během měsíce nabootovat starý jádro, když se ukáže, že update něco rozbil.)

[j]

Jo, zdravim dalsiho ynteligenta, co vzivote nevidel provozni stroj, na kterym jede neco vic, nez piskvorky ... Fakt bych chtel videt, jak budes 3x za sebou rebootovat masinu ktera ridi vyrobni linku ... kdyz jeden start ty masiny trva hodinu ... Opravdu chci videt, jak budes vedeni firmy vysvetlovat, ze si chtel jen patchnout kernel ... ale ze to nejak nevyslo ... a tak si tam musel vracet ten starej ... a firma kvuli tomu pulden stala ...

A to nemluvim o tom, ze zcela zjevne vubec netusite (ani ujeden z vas) jak se provozuji produkcni stroje ... ona totiz na nich (velke prekvapko) bezi nejaka aplikace ... u ktery jeji dodavatel jednoduse garantuje provoz s nejakym zcela konkretnim sestavenim kernelu ... a kdyz si tam da kdokoli jiny, tak to sice mozna fungovat bude ... ale kdyz ne, tak si ty milionovy skody muze calovat z vlastniho.

I polodement pak vi, ze v clusteru umi behat tak promile aplikaci. A to nemluvim o tom, ze to velmi casto funguje pouze proti vypadku, nikoli jako moznost jak to po castech patchovat, protoze to jednoduse nefunguje, pokud na tech strojich jsou ruzne verze SW.

[Rada]

Tak pokud se jedná o embedded systém, na kterém běží jedna jednoúčelová aplikace a celý funguje jako jednoúčelové zařízení (a není nejspíš ani připojený k internetu), tak to samozřejmě nemá smysl patchovat.

Pokud ale ten stroj připojený je, tak neopravovat bezpečnostní chyby je šílenství. Zajímalo by mě, jak byste vedení vysvětloval, že linka půl dne vyráběla zmetky, protože tu mašinu někdo z venku sabotoval? IMO spíš projde to, že bude tři hodiny stát. Jinak... u tak drahého provozu bych předpokládal (zkušenosti v této oblasti nemám), že k tomu stroji s vysokou dostupností bude existovat identická kopie - HW i SW, na které se budou právě testovat aktualizace a úpravy dřív, než se provedou na produkčním stroji. Nebo to z nějakého důvodu nejde?

[tecik]

Heh, ja zil v domeni, pokud je neco standalone, a neni mozne na to pres den rypnout, tak je tu vzdy vecer. Jedna nocni akce a mas po starostech ;)

Jinak - to co jsi "j" psal o clusterech je kec jak prase. Zdaleka ne jen "promile" aplikaci funguji v clusteru Ono zalezi jak ten cluster postavis Dokonce se da udelat "cluster-like" appka ktera o clusteru vi prd. Je to vazne jen o predstavyvosti. A ohledne verzi, build/test vs run env. nic nerika?

Vidim cloveka, ktery hleda problemy proc to nejde, nez "jak by to slo". Nebo prosim "j" dodej konkretni priklad, a to s detaily proc. Protoze ted proste vazne duvod proc to nejde nevidim.

[ufon]

mnoho vyrobnych liniek fici 24h denne a aplikacia sa pouziva taka aku dodal vyrobca. myslis ze nejaky upoteny autisticky linuxak bude prepisovat cely framework stroja? :D

kazdopadne patchovanie "len obcas" sa pouziva bezne

[trekker.dk]

A to nemluvim o tom, ze zcela zjevne vubec netusite (ani ujeden z vas) jak se provozuji produkcni stroje ...

Jasně, drsňáku...

[Atom321]

Pro řízení výrobní linky se občas ještě dneska používá DOS nebo dokonce Windows 3.0. Tedy, samotné řízení zajišťuje nějaká jednoúčelová krabice. Ta je spojená přes sériák s nějakým prastarým PC s dávno zastatralým operačním systémem, na kterém běží nějak splácané uživatelské rozhraní. Dokud to funguje, tak se na to nesahá. Naštěstí taková věc obvykle není připojená k síti a už vůbec ne do internetu.

Aplikace pro cluster jsou samozřejmě psané tak, aby zvládly instalovat aktualizace po částech, bez výpadku celého clusteru. Pokud stojí výpadek milion korun na hodinu, tak už se vyplatí investovat do vývoje a napsat to pořádně.

[Field]

chocho šedivá je teorie, zelený je strom života

[Petr Ježek]

Kdyby se tak chovali všichni, nebude po pár týdnech kernel o nic bezpečnější než byl při uvolnění.

[Jendа]

Například propírané chyby v HID

Cool. Další důvod při zamykání obrazovky ještě unloadovat modul na USB.

[trekker.dk]

No, jestli máš USB klávesnici, tak by tohle řešení mohlo mít trochu problém, až si to zase budeš chtít odemknout

[Jendа]

Naštěstí nemám :)