Jaderné noviny – 3. 3. 2011: Bezpečnostní problémy kolem debugfs a capabilities

14. 3. 2011 | Jirka Bourek | Jaderné noviny | 3175×

Citáty týdne: Ric Wheeler, Roland McGrath. debugfs: pravidla nejsou vítána. Kvalifikace pro nahrávání jaderných modulů.

Obsah

• Aktuální verze jádra: 2.6.38-rc7
• Citáty týdne: Ric Wheeler, Roland McGrath
• debugfs: pravidla nejsou vítána
• Kvalifikace pro nahrávání jaderných modulů

Aktuální verze jádra: 2.6.38-rc7

Současné vývojové jádro je 2.6.38-rc7 vydané 1. března. Opravdu tu není co napsat. Aktualizace ovladačů (náhodné jednořádky a nějaké menší aktualizace dri a zvukových SoC kodeků) a pár oprav souborových systémů (hlavně fiemap a zotavení z ENOSPC u btrfs), většina je ale poměrně malá. Regrese opraveny, doufejme, že žádné nové nezavedeny. Všechny detaily lze nalézt v kompletním changelogu.

Stabilní aktualizace: stabilní jádro 2.6.37.2 bylo vydáno 24. února. Dlouhodobě udržované jádro 2.6.32.30 bylo vydáno 2. března s děkovnou poznámkou: Opět děkuji Maximilianu Attemsovi, který hodně kopal v různých distribučních jádrech a přeposlal mi původní ID commitů v gitu, které by do tohoto stromu měly být aplikovány. Red Hat mu to svým přístupem „jeden obrovský patch“ moc nezjednodušil a Maximilianova šikovnost tedy pomáhá nám všem.

Citáty týdne: Ric Wheeler, Roland McGrath

Také ber v potaz, že dneska není komunita vývojářů btrfs nijak malá a rovná se (nebo možná překonává) i velikosti týmu pracujícího na ext4.

Abych odpověděl na tvoji poslední otázku, nemáme v úmyslu zpomalit. Naopak doufáme, že vývoj zrychlíme tím, že bude víc vývojářů, testerů a uživatelů.

-- Ric Wheeler

Nemá cenu diskutovat v jaderné konferenci detaily nových vlastností ptrace a to, jak ladění pomohou, dokud se lidi od debuggeru neshodnou na tom, co by opravdu chtěli použít. Bylo by kontraproduktivní začít navrhovat a implementovat náhodné napůl syrové nápady do jádra dřív, než si budeme jisti, že jsou to věci, které debuggery potřebují a které jejich vývojáři použijí. Toho už tady bylo dost a vedlo to k současné bažině plné špatně specifikovaných vlastností, které ladění příliš nepomáhají.

-- Roland McGrath

debugfs: pravidla nejsou vítána

napsal Jonathan Corbet, 22. února 2011

Jaderný souborový systém debugfs má být místem, kam vývojáři jádra mohou vložit všechny informace, které by mohly být někomu k něčemu dobré. Narozdíl od ostatních jaderných virtuálních souborových systémů (/proc, /sys) má debugfs explicitní pravidlo „žádná pravidla“. Vývojáři tam mohou vložit cokoliv bez ohledu na vkus, (hypoteticky) stabilitu ABI nebo užitečnost. „Žádná pravidla“ nicméně nejde tak daleko, aby to umožňovalo narušit bezpečnost systému, což vedlo k pokusu strčit debugfs pod zámek.

Eugene Teo nedávno zaslal požadavek na 20 CVE čísel pro dvacet různých slabin týkajících se všeobecně zapisovatelných souborů v debugfs a sysfs. Některé ze slabin v debugfs by podle všeho mohly umožnit jakémukoliv lokálnímu uživateli zapsat libovolné hodnoty do registrů zařízení – situace, ze které těžko může vzejít něco dobrého. V blízké budoucnosti tedy očekávejte další sadu jaderných aktualizací, jak budou tyto díry uzavírány a opravy zpřístupňovány uživatelům.

V reakci na tyto slabiny Kees Cook zaslal patch, který by zajistil, že debugfs bude připojován tak, aby byl přístupný pouze pro superuživatele. Tak by všechny další chyby nebyly přístupné neprivilegovaným uživatelům a tak by nevznikaly nové slabiny, které je nutné opravovat. Patch nebyl přijat dobře; vypadá až podezřele jako pravidlo v zemi, kde žádná být nemají. Greg Kroah-Hartman odpověděl:

Byly tam jenom stupidní chyby, nesnaž se zamknout celý souborový systém jenom kvůli pár chybám.

Kees naznačil, že tyto chyby by se mohly objevovat nadále a že „žádná pravidla“ nemusí být ten nejlepší přístup, ale Alan Cox zareagoval:

Je to fs pro ladění, kromě „nepřipojujte ho na produkčních systémech“ je potřeba se všem pravidlům vyhnout.

Myšlenka nepřipojovat debugfs na produkčních systémech má jeden problém: jsou tam užitečné věci. Na vrcholu seznamu jsou rozhodně řídící soubory pro perf a ftrace; bez debugfs většina naší krásné a nové sledovací infrastruktury nebude fungovat. Také jsou tam knoflíky pro ladění vlastností plánovače, rozhraní pro nástroj „usbmon“, rozhraní, které používá nástroj kvm_stat od Red Hatu a další. V debugfs je dost užitečných věci na to, abychom ho mohli najít připojený na mnoha systémech mimo ladění jádra; dosáhl dokonce bodu, kdy Greg zpochybnil to, že by na produkčních systémech neměl být připojen:

Ani omylem není pravda, všechna „podniková“ distra z dobrých důvodů debugfs připojují.

„Žádná pravidla“ a „připojeno na podnikových systémech“ vypadá jako špatná kombinace; bylo by hezké, kdyby věci byly trochu bezpečnější. Diskuzí proletělo několik návrhů, jak to zařídit, včetně:

• Naučit nástroj checkpatch.pl hledat všeobecně zapisovatelné soubory v debugfs a stěžovat si na ně. K tomuto kroku již došlo; verze checkpatch.pl v 2.6.38 bude ukazovat na takové soubory jak v debugfs, tak v sysfs.

• Zakázat všeobecně zapisovatelné soubory v debugfs. Patch byl zaslán, zatím se nicméně neobjevilo dost komentářů, aby se dalo říci, jestli bude takové omezení bráno jako pravidlo, nebo ne.

• Přesunout obecně užitečná rozhraní z debugfs někam, kde nebude panovat divoký západ, a pak nechat debugfs na většině systémů odpojený. To je nápad, který na první pohled dává smysl, ale také může narazit na praktické potíže. Přesunout rozhraní může znamenat nutnost je pročistit, lépe garantovat stabilitu ABI a – což je důležitější – rozbít nástroje, které závisí na současném umístění těchto rozhraní.

Poslední záležitost může pro toto řešení znamenat stop; mohlo by to vývojáře nutit několik let udržovat jak staré, tak nové rozhraní paralelně. Mnoho vývojářů, když budou čelit takové vyhlídce, se může rozhodnout, že nechají rozhraní tam, kde je. Debugfs nemá, co se týče ABI, garantovat nic, ale jak se ukázalo v minulosti, taková politika nemusí nutně zabránit vzniku ABI, které by bylo nutné udržovat.

Debugfs tedy na produkčních systémech nějaký čas zůstane. Vzhledem k tomu není žádná jiná alternativa než zajistit, aby byl bezpečnější. Změna v checkpatch.pl je dobrým začátkem, ale nemůže nahrazovat podrobné revize kódu. Revidovatelé mají tendence kód debugfs přeskakovat, ale pokud má tento kód běžet na důležitých systémech, s touto tendencí je nutné bojovat. Debugfs musí brát na bezpečnost systému stejné ohledy jako jakýkoliv jiný jaderný kód.

Kvalifikace pro nahrávání jaderných modulů

napsal Jake Edge, 2. března 2011

Na linuxových kvalifikacích [capabilities] se stále pracuje. V jádře jsou již dlouho – od verze 2.1 z roku 1998 – ale z různých důvodů více než desetiletí trvalo, než distribuce začaly tuto vlastnost používat. I když kvalifikace zdánlivě poskytují způsob, jak procesům poskytnout místo všechno-nebo-nic v podobě setuid pouze omezená privilegia, je tato vlastnost obklopena nedokončenými záležitostmi, omezeními, složitostmi a dalšími problémy. Když teď Fedora, Openwall a další distribuce pracují na tom skutečně kvalifikace používat a omezit privilegia udělovaná systémových binárkám, na některé z těchto problémů se naráží a jsou řešeny.

Jedním příkladem je patch začleněný do 2.6.32. Jeho hlavní myšlenkou je, že kvalifikace CAP_NET_ADMIN by měla být dostatečná pro nahrávání modulů, které souvisí se síťováním, a nemělo by být zapotřebí mít kvalifikaci CAP_SYS_MODULE. Kvalifikace CAP_SYS_MODULE umožňuje nahrávat moduly odkudkoliv a neomezovat jejich hledání jenom na cestu /lib/modules/.... Přechodem k CAP_NET_ADMIN by tedy nástroje pro správu sítě jako ifconfig byly omezeny jenom na systémové moduly a ne na libovolný kód.

Toto uspořádání má jeden problém, na který poukázal Vasilij Kulikov, protože procesům s CAP_NET_ADMIN umožňuje nahrát jakýkoliv modul z /lib/modules, ne jenom ty spojené se síťováním. Nebo jak to ukázal on:

root@albatros:~# grep Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: fffffffc00001000
CapEff: fffffffc00001000
CapBnd: fffffffc00001000
root@albatros:~# lsmod | grep xfs
root@albatros:~# ifconfig xfs
xfs: error fetching interface information: Device not found
root@albatros:~# lsmod | grep xfs
xfs                   767011  0 
exportfs                4226  2 xfs,nfsd

Tento příklad si žádá malé vysvětlení. První příkaz ukazuje, že kvalifikace shellu jsou opravdu jenom CAP_NET_ADMIN (ze současných 34 definovaných kvalifikací má číslo 12). Vasilij poté ukazuje, že modul xfs není nahrán až do volání ifconfig; poté už ano. To rozhodně není očekávané chování. Ve skutečnosti je to nyní CVE-2011-1019 (v době psaní tohoto článku pouze rezervováno.) Pro ty, kteří by to chtěli zkusit doma, poskytl Vasilij správné zaklínadlo ve verzi 2 svého patche:

# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --

Berte na vědomí, že u jader, která nejdou popsat slovy bleeding edge (jako například jádro Fedory 14), je potřeba 34 nahradit číslem 33, protože v nich bude chybět kvalifikace CAP_SYSLOG, která byla přidána teprve nedávno. Spuštěním daného příkazu dostanete shell, který bude mít kvalifikaci pouze CAP_NET_ADMIN.

Vasilijův první návrh patche jednoduše měnil volání request_module() ve vnitřní funkci síťování dev_load() tak, aby nahrávala jenom moduly začínající „netdev-“, kde se nastavení odpovídajících aliasů očekává od udevu. V kódu již mají aliasy tři moduly (ip_gre.c, ipip.c a sit.c), takže patch mění jejich prefix na „netdev-“. Davidu Millerovi se ale změna jmen nelíbila, protože s tím přestane fungovat existující kód.

Také se objevily nějaké neshody ohledně útočníků, kteří by mohli moduly přeložit s aliasem „netdev-“, ale pokud takový útočník nenainstaluje kód do /lib/modules, nepředstavuje to žádný problém. V takovém případě je modelem ohrožení podvržená binárka, která má CAP_NET_ADMIN, což ale není kvalifikace, která by umožnila zápis do /lib/modules. Davidova stížnost je nicméně podstatnější, protože cokoliv, kde se používalo například „ifconfig sit0“, přestane fungovat.

Po nějakých diskuzích o tom, jak problém vyřešit, si Arnd Bergmann všiml, že problém se zpětnou kompatibilitou platí jenom pro systémy, které kvalifikace nedělí (tj. používají buď oprávnění superuživatele nebo setuid a mají tedy všechny kvalifikace.) Na těch může být vyžadována kvalifikace CAP_SYS_MODULE, zatímco programy, které budou mít jenom CAP_NET_ADMIN budou nové a tudíž mohou používat jména s „netdev-“. Kód bude vypadat nějak takto:

no_module = !dev;
if (no_module && capable(CAP_NET_ADMIN))
        no_module = request_module("netdev-%s", name);
if (no_module && capable(CAP_SYS_MODULE)) {
        if (!request_module("%s", name))
                pr_err("Loading kernel module for a network device "
"with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-%s "
"instead\n", name);

Davidovi a dalším toto řešení přišlo akceptovatelné, takže ho možná brzy uvidíme v hlavní řadě. Je nicméně potřeba poznamenat, že kvalifikace jsou součástí jaderného ABI, takže změny jejich chování bude obecně obtížné prosadit. Tato změna opravuje bezpečnostní problém – a doufejme, že to není chování, na kterém nějaká aplikace v uživatelském prostoru závisí – takže si pravděpodobně najde rozumně hladkou cestu. Jiné změny, které se objeví, až se na více strojích začnou kvalifikace používat, to budou mít těžší, přestože problémy s definicemi různých kvalifikací jsme již vidět mohli.

       

Komentáře

Diskuse byla administrátory uzamčena

[Peter Fodrek]

Nevie niekto, ako urobit kvalifilkaciu pre misc moduly?

mame totiz RT aplikaciu, ktora musi byt modulom jadra a tak to riesime, nie velmi korektne, cez sudoers a NOPASSWD pre modprobe, insmod a rmmod priopadne depmod pre vyvojrara

Ale kvalifikacie vyzeraju bezpecnejsie.