Jaderné noviny – 5. 4. 2018: Návrh auditních ID kontejnerů

15. 4. 2018 | David Kolibáč | Jaderné noviny | 2033×

Stav vydání jádra. Šifrovací tokeny Nitrokey pro jaderné vývojáře zdarma. Citáty týdne: Russell King, Alexandre Oliva a Linus Torvalds. Návrh auditních ID kontejnerů.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 4. dubna 2018

Aktuální jádro je 4.16 vydané 1. dubna. Linus řekl: „K řadě oprav a pročištění došlo jinde, nic z toho mě nepřimělo říct si ‚hmm–hmm, necháme to ještě týden uležet.‘“ Stěžejní změny v tomto vydání zahrnují prvotní podporu hypervizoru Jailhouse, tvrdící patche whitelistu kopírování do/z uživatelského prostoru, vylepšení plánovače deadline a – samozřejmě – mnoho práce věnované zmírňování Meltdown a Spectre.

Stabilní aktualizace: 4.15.14, 4.14.31, 4.9.91 a 4.4.125 byly vydány 29. března, následovaly je 31. března 4.15.15, 4.14.32, 4.9.92 a 4.4.126

Šifrovací tokeny Nitrokey pro jaderné vývojáře zdarma

Free Nitrokey cryptographic cards for kernel developers. Jonathan Corbet. 4. dubna 2018

Linux Foundation a Nitrokey vyhlašují program, v jehož rámci může každý, kdo je uveden v souboru MAINTAINERS v jádře nebo má e-mailovou adresu na kernel.org, získat šifrovací token Nitrokey Start. Cílem samozřejmě je, že jaderní vývojáři budou tato zařízení používat k bezpečnému uchování svých klíčů GnuPG, a tak se celkově zlepší bezpečnost procesu vývoje jádra. „Čipová karta s tokenem jako Nitrokey Start obsahuje šifrovací čip schopný uchovávat soukromé klíče a provádět operace šifrování přímo v tokenu. Jelikož klíče toto zařízení nikdy neopouštějí, operační systém počítače, ke kterému je připojené, si z něj nemůže vytáhnout soukromé klíče, čímž se výrazně omezují možnosti, jak mohou být zveřejněny či odcizeny.“

Přehled šifrovacích tokenů poskytuje tento článek na Linux Weekly News.

Citáty týdne

Quotes of the week. Jonathan Corbet. 4. dubna 2018

Od začátku roku 2018 už nejsem placený za to, abych podporoval jádro kódu 32bitové architektury ARM. To znamená, že tento kód už není podporován na komerční bázi, nově je podporován pouze z dobré vůle.

—Russell King

Další významná změna v tomto vydání se týká toho, že jak bylo upozorněno, Linux obsahoval chybová hlášení, která uživatele nabádala k aktualizaci mikrokódu procesorů x86. Jelikož příslušný mikrokód není svobodný software (Free Software), taková hlášení do GNU Linux-libre nepatří. Takže nyní jsme vybaveni k detekci a pročištění těchto hlášení. Mnoho se jich do jádra dostalo v poslední době, kdy se spoléhá na to, že změny v mikrokódu se vypořádají s problémy Meltdown a Spectre, ale některé mohou být i staršího data.

—Alexandre Oliva při vydání jádra 4.16-GNU

Už jsem si dávno zvykl, že někteří žijí i mimo vývoj jádra a někdy neodpovídají obratem. Nemusím tomu _rozumět_, ale smířil jsem se s tím.

—Linus Torvalds

Návrh auditních ID kontejnerů

An audit container ID proposal. Jonathan Corbet. 29. března 2018

Komunita jaderných vývojářů vytrvale vzdorovala tomu, aby se do jádra dostal koncept „kontejneru“. Ačkoliv jádro poskytuje základní potřebné stavební kameny (jmenné prostory, řídící skupiny atd.), je na uživatelském prostoru, aby si z toho poskládal, co zrovna potřebuje za implementaci kontejnerů. Takový přístup přispívá k flexibilitě a umožňuje implementaci nejrůznějších abstrakcí kontejnerů, ale zároveň komplikuje přiřazení událostí v jádře tomu kontejneru, který je vyvolal. Auditní ID kontejnerů představují pokus tento problém vyřešit v jednom konkrétním případě užití. V minulosti se nedočkala všeobecně vřelého přijetí, ale práce na nich přesto pokračují.

Mechanismus auditních ID kontejnerů byl původně navržen (ale ne implementován) koncem roku 2017. Shrnutí tehdejší diskuze najdete v tomto článku. Myšlenka spočívala v tom, že se ke všem procesům běžícím uvnitř kontejneru připojí ID dané uživatelským prostorem. Toto ID se pak bude objevovat ve všech událostech vyvolaných auditním subsystémem. Takže například když auditní kód zaznamená pokus o otevření souboru, monitorovací kód v uživatelském prostoru by mohl použít ID kontejneru uvedené v auditní zprávě k nalezení kontejneru, který pokus provedl.

Richard Guy Briggs dodal implementaci konceptu ID kontejnerů v půlce března. V tomto návrhu jsou ID kontejnerů 64bitové hodnoty bez znaménka. Hodnota „samé jedničky“ je rezervována jako indikátor, že žádné ID nebylo nastaveno. Do adresáře /proc každého procesu přibyl nový soubor (containerid) – procesu se ID kontejneru nastaví tak, že se do tohoto souboru zapíše nová hodnota. Nastavení ID je ale následovně omezeno:

Ke změně této hodnoty je vyžadována schopnost CAP_AUDIT_CONTROL. Když se myšlenka ID kontejnerů poprvé objevila, proběhla poměrně rozsáhlá diskuze, co za schopnost by mělo být vyžadováno. Původně měla vzniknout nová schopnost speciálně pro tento účel, ale to se setkalo s odporem. CAP_AUDIT_CONTROL již existuje za účelem poskytnutí přístupu auditním filtrovacím pravidlům apod. Vývojáři auditování variantu rozšíření působnosti této schopnosti na ID kontejnerů sice nepovažovali za nejlepší řešení, ale nakonec to akceptovali.
Proces si nemůže nastavit své vlastní ID kontejneru, to může udělat jenom nějaký jiný proces.
Auditní ID procesu může být nastaveno pouze jednou od vytvoření procesu. To se ve skutečnosti implementuje tak, že změna je možná pouze tehdy, když je ID kontejneru buď onen příznak skládající se ze samých jedniček, nebo stejné jako v rodičovském procesu.
ID kontejneru může být procesu nastaveno pouze tehdy, když proces nemá žádné potomky, ani vlákna. Smyslem tohoto omezení je zabránit procesu obejít pravidlo, že si nemůže nastavit své vlastní ID kontejneru, tím, že by si vytvořil potomka, který by mu pak toto ID nastavil. Jelikož pravidlo o nastavení pouze jednou závisí na porovnání s ID kontejneru rodiče, toto pravidlo by také šlo obejít, kdyby si mohly ID změnit procesy s potomky.

Jakmile je procesu ID kontejneru nastaveno, každý další proces–potomek toto ID zdědí. Jinak jádro s touto identifikační hodnotou skoro nic nedělá. Jediná výjimka je, že události vytvořené auditním subsystémem budou zahrnovat toto ID, je-li nastaveno. Nástroje uživatelského prostoru dostaly patche, aby mohly ID kontejneru využívat, když je k dispozici.

Pozoruhodný průnik je však mezi ID kontejnerů a síťovými jmennými prostory. V síťovém jmenném prostoru mohou nastat potenciálně zajímavé události, ale některé z nich může být složité spojit s konkrétním kontejnerem. Jedním možným příkladem je odmítnutí paketu na základě pravidel firewallu. Situaci komplikuje skutečnost, že v jednom síťovém jmenném prostoru může koexistovat více kontejnerů. Skupina patchů tento problém řeší tak, že každému síťovému jmennému prostoru přidává seznam ID kontejnerů všech procesů, které v něm běží. Když nastane auditní událost, která se týká tohoto jmenného prostoru, ale nemůže být spojena s konkrétním procesem, uvedou se všechna příslušná ID kontejnerů.

Zůstává otázka, zda mechanismus ptags není lepším řešením tohoto problému. Zde diskutovaná skupina patchů v principu umožňuje přiřadit procesům určitý štítek – ptags takovou schopnost poskytují v obecnější podobě. Je vcelku zřejmé, proč by vývojářům auditování vyhovoval stávající postup: ptags je patch mimo strom, který v současné podobě závisí na věčně nedokončeném kombinování bezpečnostních modulů. Oproti tomu jsou auditní ID kontejnerů poměrně jednoduchá a mohla by být začleněna v dohledné době.

Přístup, který někteří vývojáři považují za nejsnazší, není vždy tím, co se prosadí v komunitě. Tentokrát se ale zdá, že přímočarý přístup by mohl zvítězit. Chtít po vývojářích auditování, aby vyřešili problém kombinování modulů, by bylo příliš i pro ty nezarytější jaderné vývojáře. Pokud dojde k začlenění některé verze této skupiny patchů, bude to sice malý, přesto však první krok k přidání konceptu kontejnerů do jádra – což se ještě může setkat s odporem.