Jaderné noviny – 7. 12. 2017: Omezení automatického zavádění jaderných modulů

27. 12. 2017 | Redakce | Jaderné noviny | 2156×

Stav vydání jádra. Citáty týdne: Thomas Gleixner a Matthew Wilcox. Omezení automatického zavádění jaderných modulů.

Stav vydání jádra

Současné vývojové jádro je 4.15-rc2, vydané 3. prosince. Linus řekl: „Jedna věc, na kterou chci poukázat, je, že se snažím dosáhnout ucpání nějakých úniků ASLR a do toho spadá, že nyní ve výchozím stavu hašujeme všechny ukazatele vypsané pomocí ‚%p‘. Mnoho lidí to neovlivní, ale kde půjde o problém s laděním (spíš než únik zajímavých ukazatelů z jádra), tam to budeme muset opravit.“

Stabilní aktualizace: 4.14.3, 4.9.66, 4.4.103 a 3.18.85 vyšly 30. listopadu. Následovaly je aktualizace 4.14.4, 4.9.67, 4.4.104 a 3.18.86, a to 5. prosince.

Citáty týdne, tentokrát o názvech

Několik lidí včetně Linuse požádalo o změnu názvu KAISER. Dali jsme dohromady seznam technicky správných akronymů:

User Address Space Separation, prefix uass_

Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

Ale jsme politicky korektní, takže jsme se shodli na

Kernel Page Table Isolation, prefix kpti_

Linusi, výběr je na tobě :)

—Thomas Gleixner

Nejsem rozhodnutý pro MAP_REQUIRED. Vymyslel jsem několik ošklivých jmen (MAP_TODDLER, MAP_TANTRUM, MAP_ULTIMATUM, MAP_BOSS, MAP_PROGRAM_MANAGER atd.). Ale myslím si, že by se z prostředku jména mělo vyhodit slovo FIXED.

—Matthew Wilcox

Omezení automatického zavádění jaderných modulů

Restricting automatic kernel-module loading. Jonathan Corbet. 4. prosince 2017

Mechanismus jaderných modulů umožňuje sestavení jádra s podporou široké škály hardwaru a softwaru, aniž by všechen ten kód musel být načten do každého běžícího systému. Z dostupnosti všech modulů v typickém distribučním jádře plyne, že k dispozici je mnoho funkcí, ale potenciálně také mnoho zneužitelných chyb. Objevila se celá řada případů, kdy došlo k použití automatického zavádění jaderných modulů, aby se do běžícího systému natáhl chybný kód. Na pokusu omezit expozici jádra modulům s chybami se ukazuje, jak náročné mohou být některé druhy tvrdících prací.

Automatické zavádění modulů

Jsou dva způsoby, jak lze do jádra načíst modul bez explicitního zásahu ze strany správce. Na většině současných systémů k tomu dojde, když je detekován (discovered) nový hardware – buď ovladačem sběrnice (na sběrnicích, které podporují detekci nového hardwaru), nebo z externího popisu, jako je strom zařízení. Detekce způsobí zaslání události do uživatelského prostoru, kde démon jako udev aplikuje jakákoli nastavená pravidla a zavede příslušné moduly. Tento mechanismus je řízen dostupností hardwaru a pro útočníka je relativně těžké nějak ho ovlivnil.

V jádře se ale skrývá starší mechanismus, který má podobu funkce request_module(). Když některá jaderná funkce sezná, že chybí potřebný modul, může zavolat request_module(), aby do uživatelského prostoru vyslala požadavek na zavedení příslušného modulu. Například pokud aplikace otevře znakové zařízení s daným hlavním (major) a vedlejším (minor) číslem a pro tato čísla neexistuje žádný ovladač, kód znakového zařízení se pokusí ovladač vyhledat následujícím voláním:

request_module("char-major-%d-%d", MAJOR(dev), MINOR(dev));

Pokud má modul ovladače nastavený alias s odpovídajícími čísly, bude automaticky zaveden do jádra, aby byl zpracován otevřený požadavek.

V jádře se nacházejí stovky volání request_module(). Některé případy jsou docela konkrétní: jeden například načte modul ide-tape, když má uživatel tu smůlu, že disponuje dotyčným zařízením. Jiné jsou obecnější: v síťovém subsystému je mnoho volání například k nalezení modulů implementujících určité síťové protokoly nebo mechanismy filtrování paketů. Zatímco volání specifická pro konkrétní zařízení byla většinou nahrazena mechanismem udev, moduly funkcí, jako jsou síťové protokoly, stále spoléhají na automatické zavádění, které je z pohledu uživatelů transparentní, pomocí request_module().

Automatické zavádění zajišťuje pohodlnou správu systému, ale zároveň jeho pohodlné zneužití. Zranitelnost protokolu DCCP, která byla zveřejněna v únoru, se nedá zneužít, pokud není modul načten do jádra – což běžně nebývá, protože DCCP má málo uživatelů. Jenže mechanismus automatického načítání umožňuje libovolnému uživateli vynutit si zavedení tohoto modulu prostým vytvořením DCCP soketu. Automatické zavádění tedy rozšiřuje možnosti útoku na jádro na cokoli, co mohou neprivilegovaní uživatelé načíst – a v běžné distribuci jádra je takových modulů hodně.

Utahování systému

Djalal Harouni pracuje na sadě patchů zaměřené na omezení vystavení jádra zranitelnostem způsobeným automatickým načítáním. Zatím nejnovější verze byla zveřejněna 27. listopadu. Harouni se inspiroval tvrzením v sadě patchů grsecurity, z ní si ale nebere žádný kód. V této podobě (která se v průběhu času poněkud změnila) přidává novou volbu sysctl (/proc/sys/kernel/modules_autoload_mode), která se dá použít k omezení jaderného mechanismu automatického zavádění modulů. Pokud je volba nastavena na nulu (výchozí nastavení), funguje automatické zavádění stejně jako na současných jádrech. Změna nastavení na jedničku omezí zavádění na procesy s určitými schopnostmi (capabilities): procesy s CAP_SYS_MODULE mohou způsobit zavedení libovolného modulu, zatímco ty s CAP_NET_ADMIN mohou nahrát libovolný modul, jehož alias začíná na netdev-. Nastavení volby na dvojku zakáže automatické zavádění úplně. Jakmile je hodnota nastavena na více než nulu, nelze ji po dobu životnosti systému zase snížit.

Tato sada patchů implementuje i příznak, který může být nastaven jednotlivým procesům, a to pomocí systémového volání prctl(). Tento příznak (který akceptuje stejné hodnoty jako globální příznak) může určitému procesu a všem jeho potomkům omezit možnost automatického zavádění modulů, aniž by došlo ke změně chování v zavádění modulů v celém systému.

Dá se s jistotou říct, že tato sada patchů nebude ve své stávající podobě začleněna, a to z jednoho důvodu: Linusi Torvaldsovi se vůbec nelíbila. Zákaz automatického zavádění modulů pravděpodobně rozbije mnoho systémů, což znamená, že distributoři nebudou ochotni tuto volbu nastavit, takže se nebude moc využívat. „Bezpečnostní volba, kterou uživatelé nemohou použít, aniž by si rozbili systém, je naprosto zbytečná,“ řekl. Diskuze na toto téma se občas vyostřila, ale Torvalds proti myšlence omezit vystavení jádra automaticky zavedeným zranitelnostem, nic nemá. Jde pouze o to najít správné řešení.

Zdá se, že řešením by mohly být právě příznaky pro konkrétní procesy. Daly by se použít například k omezení automatického zavádění modulů z kódu běžícího v kontejneru, zatímco systém jako takový by zůstal beze změny. Není neobvyklé uvnitř kontejneru vytvořit proces se schopností CAP_NET_ADMIN k nastavení přístupu kontejneru k síti a zároveň chtít, aby si většina kódu v kontejneru nemohla vynutit zavádění modulů.

Ale jak řekl Torvalds, jediný příznak nebude nikdy schopen patřičně pokrýt všechny situace, kdy automatické zavádění hraje roli. Některé moduly by možná mělo být možné načíst vždy, zatímco jiné mohou vyžadovat nějakou konkrétní schopnost. Takže navrhl funkci request_module_cap() z Harouniho sady patchů (která provede zavedení pouze tehdy, když je k dispozici konkrétní schopnost) zachovat a používat ji šířeji. Na druhou stranu si vyžádal několik změn.

První z nich je, že request_module_cap() by ve skutečnosti neměla blokovat zavádění modulů, když požadovaná schopnost chybí – alespoň ne zpočátku. Místo toho by funkce měla zaznamenat zprávu. Umožní to zjistit, ve kterých případech je automatické zavádění opravdu zapotřebí, což by se štěstím mohlo poukázat na místa, kde je možné ho omezit bez rozbití existujících systémů. Navrhl také, že kontrola schopností je příliš zjednodušující. Například výše popsané automatické zavedení „char-major-“ nastane pouze tehdy, je-li proces schopen otevřít uzel zařízení s uvedeným hlavním a vedlejším číslem. V takových případech již byl úspěšně proveden test oprávnění (schopnost otevřít speciální soubor) a modul by měl být bezpodmínečně zaveden. Takže možná budou zapotřebí další varianty request_module() k popisu případů, na které se schopnosti nevztahují.

Nakonec měl Linus Torvalds další nápad, který se týkal myšlenky, že nejhorší chyby se obvykle ukrývají v modulech, které jsou spravovány přinejlepším bídně. Například o modulu DCCP zmíněném výše je známo, že se využívá zřídka a je téměř neudržovaný. Pokud by dobře udržované moduly byly označeny zvláštním příznakem, mohlo by jít omezit neprivilegované automatické zavádění pouze na tyto moduly. Tím by se zabránilo automatickému zavádění některých spíše zbytných modulů, aniž by došlo k narušení automatického zavádění jako takového. Tato myšlenka vyvolává jednu otázku, kterou nikdo nepoložil: Pokud modul přestane být udržován, kdo se postará o to, aby byl smazán příznak „dobře udržovaný“?.

V každém případě nebude tento příznak přidán hned, bude-li platit plán navržený Keesem Cookem. Ten navrhl začít s request_module_cap() s povolenými varováními. Příznaky pro jednotlivé procesy by byly přidány pro ty, kteří je mohou používat, ale globální volba k omezení automatického zavádění by přidána nebyla. Nakonec by mohlo být možné zbavit se neoprávněného zavedení modulu, ale to je cíl do budoucna. Krátkodobými přínosy by byla jednak lepší znalost toho, jak se automatické zavádění skutečně používá, a jednak možnost volby pro správce, kteří chtějí systém utěsnit již nyní, aby mohli omezit jednotlivé procesy.

Tato debata zvýrazňuje jedno ze základních pětí kolem práce na tvrzení jádra. Jen málo lidí je proti bezpečnějšímu jádru, ale situace se komplikuje, jakmile může tvrzení rozbít stávající systémy, což se často stává. Vývojáři orientovaní na zabezpečení jsou často frustrováni tím, že se jaderná komunita brání změnám v tvrzení s viditelnými dopady na uživatele, zatímco jaderní vývojáři mají málo sympatií pro změny, které povedou k nahlášeným chybám a nešťastným uživatelům. Některé projevy takové nespokojenosti se v této diskuzi ukázaly, ale většina zúčastněných vývojářů měla vesměs zájem spolupracovat na řešení, které by fungovalo pro všechny.

       

Komentáře