Jaderné noviny - 27. 5. 2015: Podepisování firmware

16. 8. 2015 | Redakce

Články - Jaderné noviny - 27. 5. 2015: Podepisování firmware  

Stav vydání jádra. Citáty týdne. Podepisování firmware.

Stav vydání jádra

Současné vývojové jádro je 4.1-rc5, vydné 24. května. "Vydání 4.1 jde podle plánu, až na to, že podle načasování to vypadá, že se další začleňovací okno bude krýt s naší letošní rodinnou dovolenou. Uvidíme, jak to dopadne. Možná posunu vydání, abych se tomu vyhnul (nebo posunu otevření začleňovacího okna)."

Stabilní aktualizace: Žádné nebyly minulý týden vydané.

Citát týdne

Myslím, že jako odborníci bychom měli často dělat chyby - viditelné chyby. Aspoň lidi nenapadne si myslet, že nemůžeme. Linus to takhle dělá už léta a očividně to funguje.

-Neil Brown

Podepisování Firmware

Kernel má schopnost vynutit si požadavek podpisu načítaných modulů již několik let. Do jádra se přitom nahrává ještě další kód, který podobnou kontrolou zatím neprochází. Jedním z příkladů je firmware, který se skrze jádro dostává do řadičů. V současné době se pracuje na přidání schopnosti kontrolovat firmware bloby (velké binární soubory), ale má to háček. Ne všichni si myslí, že je taková funkce zapotřebí.

Luis Rodriguez popsal svůj nápad na několika jaderných mailing listech. Na přepracování modul loaderu jádra momentálně pracuje David Howells a snaží se nahradit svůj, podomácku vyrobený mechanismus podepisování modulů, standardem PKCS#7. Podle Linuse přišel čas přijmout stejný standard pro podepisování různých souborů, které se nahrávají do jádra, firmwaru obzvláště.

V návrhu se počítá s tím, že by podpisy firmware (stejně jako vynucení podpisů modulů) bylo volitelné, bylo by možné postavit jádro bez této schopnosti. Většina firmwaru, nahrávaného linuxovými ovladači, se ukládá do firmwarového linuxového repozitáře. Tyto bloby by podepsal firmware maintainer, takže by byly zaveditelné ve výchozím nastavení. Luis navrhl, aby Linux Foundation vytvořila klíč X.509, který by se stal součástí zdrojového kódu jádra, a který by na oplátku našel využití při podepisování klíče maintainera firmwaru. Téma firmwaru mimo hlavní strom nikdo nenačal. Vždycky by ale mělo být možné přidat další klíč na jadernou klíčenku a povolit nahrání nového firmwaru.

Andy Lutomirsky se trochu bojí toho, jak by se s těmito klíči mělo nakládat. Obzvláště by byl rád, kdyby byla využitelnost každého klíče co možná nejvíce omezena. Klíče pro podepisování modulů by podle něj něměly fungovat pro firmware. Podpisy by také měly upřesnit, kde je třeba použít blob, aby se dalo předejít útokům v případě, že dojde k odeslání firmware ke špatnému zařízení.

Základní otázku však položili Alan Cox a Greg Kroah-Hartman: Proč se vůbec zabývat podepisováním firmware? Greg k tomu řekl:

Moc nechápu potřebu podepisovat něco, co nevím odkud a od jaké společnosti je, jen abych to poslal k samostatnému zařízení, které si s tím udělá co bude chtít, ať už je to podepsané nebo ne.

Oba si myslí, že mají-li být firmware podpisy kontrolovány, měla by to dělat zařízení, která tento firmware přijímají. Jinak bude jádro kontrolovat platnost obrazu firmware, o kterém stejně nemůže nic moc vědět.

Jak správně podotkl David Woodhouse, spočívá problém kontroly podpisu v zařízení v tom, že se nahrávaný firmware používá jako metoda snížení spotřeby hardwaru. Zavedením této šifrovací funkce přímo do zařízení (navíc takového, které ještě nemá nahraný operační software), by naopak zvýšilo jeho spotřebu a tím zmařilo původní záměr. Greg sice s tímto názorem nesouhlasil, ale zdá se, že hardware postrádající kontrolu podpisu firmware stejně jen tak nezmizí.

David ještě dodal, že bez IOMMU (I/O memory management unit) mohou škodlivá zařízení běžícímu systému uškodit. Ohrožený firmware může představovat atraktivní způsob, jak zaútočit na systém. Podle něj není podepisování firmware pouze způsob, jak ochránit operační systém, ale také služba prodejcům hardwaru.

Dalším důvodem proč chtít tuto funkci je fakt, že může sloužit pro ověření původu jiných souborů nahrávaných do jádra. Luis si dělá starosti hlavně o CRDA subsystém (central regulatory domain agent). CRDA se stará o právní stránku bezdrátových sítí v různých právních řádech po světě. Různé země mají různá pravidla. Týkají se frekvencí, výkonu a podobně. CRDA subsystém dohlíží na to, aby Linux fungoval podle pravidel daného místa.

Luis vyjádřil CRDA uznání za to, že nás dostalo ze situace, kdy výrobci bezdrátových adaptérů mohli odmítnout poskytnout free ovladače ke svým zařízením. Díky CRDA si výrobci mohou být jisti, že se jejich hardware používá vyhovujícím způsobem. Ovšem tato důvěra obstojí pouze v případě, kdy uživatelé nebudou moci samovolně modifikovat CRDA databázi. Za tímto účelem je databáze v současné době podepsaná. Na některých distribucích dojde před jejím načtením do jádra k ověření v uživatelském prostoru.

Problémem do budoucna může být použití specifického šifrovacího kódu subsystému. Napsat jej dobře nebude snadné a počet lidí, sledujících kód kontroly podpisu, CRDA je zřejmě dost malý. Luis by tedy rád kontrolu přesunul do jádra, kde by využívala stejného kódu jako modul loader. Tím by se snížilo množství kódu pro kontrolu podpisů a zvýšila jistota, že daný kus kódu pracuje tak, jak by měl.

V tomto případě neexistuje zařízení, které by převzalo zodpovědnost nad kontrolou podpisů. Jedná se o data, která užívá přímo jádro. Má li se ochránit před poškozenou CRDA databází, mělo by dělat kontrolu samo. Kód, který tuto kontrolu dělá, by mohl stejně dobře kontrolovat firmware. Takže zavést mechanismus kontroly firmware, který by zároveň kontroloval celistvost jiných souborů nahrávaných do jádra, dává vlastně trochu smysl.

Jakmile bude jasné, že funkce funguje jak bylo zamýšleno, nebude s jejím přidáním do jádra pravděpodobně žádný problém. Celkově se komunita staví k přidávání podobných mechanismů ověřování integrity spíše pozitivně, důležité ovšem je, aby rozhodnutí ohledně použití takové funkce, zůstalo v rukou uživatele. Distribuce mohou, ale nemusí zapnout kontrolu podpisu firmware, ale pro zájemce bude tato možnost k dispozici.

Diskuse k tomuto článku

[Petr Tomášek]

Celá "slavná" CRDA je pěkná debilita... Tohle má být svobodný systém? Tak proč ho takhle mrvit...!

[Jendа]

Co přesně mi u CRDA zabrání prostě to ověřování podpisu zakomentovat?

[petr_p]

Co brání připojit výkonnější anténu?

[Jendа]

Nic, a přesto nemáme antény které by s wifi kartami komunikovaly kryptograficky bezpečným protokolem, kterým by se dohodly na maximálním přípustném výkonu.

I když od té doby co jsem viděl vysavač s podobnou technologií, tak bych se nedivil.

[Sten]

A byla to kryptograficky bezpečná komunikace nebo to jen řeklo zdroji, jaký proud (a případně napětí) do toho má poslat?

[Jendа]

To jsem nezkoumal.

Zdroji to nic neřeklo (byl to takový ten jednoduchý adaptér na 12 V), ten dolní procesor jenom rozsvěcel červenou nebo zelenou ledku podle stavu baterky, ale bez něj se to prostě nenabíjelo.

[Tany]

To je prostě další stupidní berlička, která to zachrání proti zlým hackerům distribuujícím CP a podporujícím teroristy.

Stejný problém, jako si udělat další kanál, nebo si sednout přesně mezi dva existující. Za ty roky jsem už viděl prasáren…

[Petr Tomášek]

Třeba nutnost překompilovávat jádro?

[little.owl]

Coz na systemu se secure bootem neni cesta.

[Mrkva]

A stahnout image SPI flashky, vylistovat seznam klicu a pridat si tam svuj nejde? (Ok, trochu se desim kam se dostavame s intellim boot guardem...)

[Grunt]

A v čem by měl být problém? Vzhledem k tomu, že ke všem běžícím jádrům je dostupný SPEC soubor (na RPM systémech, na Debianu nevim) není problém vytvořit téměř 1:1 kopii jádra včetně naprosto stejné konfigurace. Je to pouze otázka času víc než čehokoliv jiného.

[vlastikroot]

Co mi brani proste do CRDA poslat jinej stat, nez ve kterem jsem a vysilat na zakazany frekvenci?

[Petr Tomášek]

Třeba to, že ti to ovladač zakáže, protože má cosi zapsáno v EEPROM. Takže mnohdy si nezavysíláš na úplně žádný frekvenci, protože ta karta je nastavena na "mezinárodní nejmenší společný jmenovatel"...

[Atom321]

Zákon 127/2005 o elektronických komunikacích