Jaderné noviny – 9. 2. 2011: Podpora více LSM

21. 2. 2011 | Jirka Bourek | Jaderné noviny | 3536×

Aktuální verze jádra: 2.6.38-rc4. Citáty týdne: Alan Cox, Greg Kroah-Hartman, Markus Rechberger a další. Podpora více LSM.

Obsah

• Aktuální verze jádra: 2.6.38-rc4
• Citáty týdne: Alan Cox, Greg Kroah-Hartman, Markus Rechberger a další
• Podpora více LSM

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

Současné vývojové jádro je 2.6.38-rc4 vydané 7. února. Není tu nic, co by vyčnívalo. Nějaké aktualizace v architekturách (arm a powerpc), obvyklé aktualizace ovladačů: dri (radeon/i915), síťové karty, zvukové, multimediální, scsi, nějaké změny v souborových systémech (cifs, btrfs) a nějaké další drobnosti (síťování, sledovací body, atd.). Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: aktualizace dlouhodobě udržovaného jádra 2.6.35.11 vyšla 7. února s dlouhým seznamem důležitých oprav.

Aktualizace 2.6.27.58 byla vydána 9 února. Obsahuje pár tuctů důležitých oprav.

Citáty týdne: Alan Cox, Greg Kroah-Hartman, Markus Rechberger a další

Každý, kdo chce programovat ATA řadiče podle zdravého rozumu místo podle dokumentace, podle errata a testování místo spekulací, je naivní.

-- Alan Cox

Zde požaduji uplatnění antidiskriminačních pravidel v zájmu těch z nás, kdo nemají rádi pivo.

-- James Bottomley napíná hranici tolerance

Uvědom si, že 50 % dnešních profesionálních programátorů nikdy nenapsalo ani jednu řádku kódu, která by se musela překládat.

-- Casey Schaufler

Jak z toho můžete vidět, Ralink zasílá patche s podporou nových čipů pro ovladač rt2x00 v upstreamu a nehází na nás jenom obrovský samostatný tar archiv, jako to dělali v minulosti. To ukazuje velkou snahu naučit se, jak pracovat s jadernou komunitou, a je třeba je za tuto významnou změnu přístupu podporovat a chválit.

-- Greg Kroah-Hartman

Žádná „pravidla“ nejsou, věci musí fungovat a to je jediné pravidlo.

-- Markus Rechberger (kontext zde)

Podpora více LSM

napsal Jake Edge, 9. února 2011

Téma jak umožnit, aby mohlo být naráz aktivních víc linuxových bezpečnostních modulů [Linux Security Module, LSM], se v jaderné komunitě objevuje s určitou pravidelností. V minulosti se objevily pokusy „skládat“ nebo „řetězit“ LSM, ale do hlavní řady se nikdy nedostalo nic. Na druhou stranu ale pokaždé, když se vývojář objeví s nějakým patchem, který by zvýšil bezpečnost jádra, je obvykle směrován na rozhraní LSM. Vzhledem k tomu, že „monolitická“ bezpečnostní řešení (jako SELinux, AppArmor a další) ve většině distribucí představují ten jediný aktivní LSM, ty jednodušší a konkrétněji zacílené LSM obvykle nelze použít. Diskuze v e-mailové konferenci linux-security-module nicméně naznačuje, že na vyřešení tohoto problému se pracuje.

Existující implementace LSM používá jedinou sadu ukazatelů na funkce ve struct security_operations, kam se ukládají „háčky“ volané, když se má rozhodnout o povolení přístupu. Jakmile se zaregistruje bezpečnostní modul (typicky při bootu použitím příznaku security=), jeho implementace se uloží do této struktury a ostatní LSM mají smůlu. Nápad skrývající se za skládáním LSM je mít několik verzí struktury security_operations a volat háčky každého registrovaného LSM, když se rozhoduje. I když to zní poměrně přímočaře, jsou tu jisté detaily, které je potřeba vyřešit, obzvláště když různé LSM dávají různé odpovědi na otázku ohledně stejného přístupu.

Tento problém sémantiky „spojení“ dvou (nebo více) byl na různých místech diskutován, aniž by bylo nalezeno skutečné globální řešení pro spojení dvou libovolných LSM. Jak před rokem varoval Serge E. Hallyn:

Problém je v tom, že spojení dvou bezpečnostních politik může mít snadno jemné, nepředvídané, ale nebezpečné důsledky. To je důvod, proč jsme se zatím drželi statutu quo, kde je 'aktivní' jenom jeden LSM, který může manuálně volat háčky jiných LSM.

Jeden příklad skládání LSM tak, jak to popisuje Serge, v jádře již je; LSM kvalifikací [capabilities] je tam, kde je potřeba, volán z jiných LSM přímo. Tento konkrétní přístup nicméně samozřejmě není příliš obecný a správci LSM pravděpodobně hodně rychle ztratí trpělivost s přidáváním volání všech dalších LSM. Je potřeba snáze rozšiřitelnější řešení.

David Howells zaslal sadu patchů, která by tento rozšiřující mechanismus přidala. Dělá to tak, že umožní více volání inicializační funkce register_security(), každé s vlastní strukturou security_operations. Místo současné situace, kdy si každý LSM spravuje vlastní data pro každý objekt (přihlašovací údaje a práva, klíče, soubory, inody, superbloky, IPC a sockety), alokuje a spravuje tato data Davidův bezpečnostní framework.

Pro každý druh objektu získá struktura security_operations nová pole *_data_size a *_data_offset, to první vyplní LSM před voláním register_security(), to druhé spravuje framework. Pole s velikostí dat říká frameworku, kolik místa je potřeba pro informace o objektu specifické pro daný LSM, offset používá framework k lokalizaci soukromých dat LSM. Pro struct cred, struct key, struct file a struct super_block se data pro každý registrovaný LSM přilepí na konec struktury, ostatní používají zprostředkující ukazatel. Jsou definovány obalující funkce, které umožňují LSM získat svá data o objektu z nových polí v tabulce operací.

Framework poté udržuje seznam registrovaných LSM a na první místo vkládá LSM kvalifikací. Když je zavolán některý z bezpečnostních háčků, framework projde seznam a volá odpovídající háček pro každý registrovaný LSM. Způsob procházení závisí na specifickém háčku, ale obvykle se hledá nenulová návratová hodnota, která indikuje zamítnutí a která je frameworku vrácena. Další způsoby procházení se používají pro specializovaná volání, například když žádná návratová hodnota neexistuje nebo když má být volán jenom první nalezený háček. Výsledkem je, že se háčky pro registrované LSM volají v daném pořadí (kvalifikace jsou první) a první, kdo zamítne přístup, „vyhrál“. Protože je volání kvalifikací vyřešeno samostatně, nemusí se jimi ostatní LSM zatěžovat; framework to zajistí za ně.

Je tu ale pár háčků, které v prostředí více LSM nefungují moc dobře, hlavně jde o obslužné funkce (tj. secid_to_secctx(), task_getsecid() atd.) pro secid (ID bezpečnostního návěští specifické pro LSM). Davidova současná implementace tento háček prostě zavolá pro první LSM, který ho implementuje, což zabrání používat více LSM, které tyto háčky implementují (v současnosti pouze SELinux a Smack). Davidovo řešení je konkrétní kombinace explicitně zakázat:

Myslím si, že jasným řešením je odmítnout jakýkoliv vybraný modul, který implementuje některé z těchto rozhraní, pokud jsme již vybrali modul, který je implementuje také. To by znamenalo, že si můžete vybrat buď Smack, nebo SELinux, ale ne obojí.

Vývojář Smack Casey Schaufler ale není přesvědčen o tom, že to je správný přístup: To trochu bere vítr z plachet, že jo?. Raději by viděl obecnější řešení, které by umožnilo, aby framework obsluhoval více secid a s nimi spojených secctx (bezpečnostní kontext):

Znamená to, že je potřeba standard pro secctx, který by umožnil přítomnost více souběžných LSM. Bude muset vzniknout rozhraní, kde by kód pro skládání modulů rozdělil secctx na jednotlivé části, nebo kterým by si LSM mohl vytáhnout bity, které ho zajímají. V každém případě bude možná potřeba aktualizovat LSM, aby akceptovaly secctx ve standardizovaném formátu.

Další zajímavá část Caseyho zprávy je, že pracoval na alternativním přístupu k problému více LSM, který nazval „Glass“ [sklo]. Kód ještě nebyl vydán, ale Casey ho popsal jako LSM, který se skládá z jiných LSM:

Bezpečnostní blob Glass je pole ukazatelů, jeden pro každý dostupný LSM včetně commoncap (tj. LSM kvalifikací), který je vždy na posledním místě. LSM Glass se vždy registruje první, když se registrují další, jsou přidány do vektoru LSM. Když je zavolán háček, Glass projde vektorem a pokud LSM háček poskytuje, zavolá se a zapamatuje se návratová hodnota; v takovém případě se commoncap přeskočí. Jestliže žádný LSM háček neposkytl, volá se commoncap.

Narozdíl od Davidova návrhu by Glass ponechal volání LSM kvalifikací v existujících LSM a commoncap by byl volán jenom v případě, že daný háček neimplementuje žádný LSM. Odůvodňuje to tím, že LSM již nyní řeší volání kvalifikací podle toho, jak je to potřeba, takže volání commoncap je potřeba jenom v případě, že to neudělal nikdo jiný. Glass navíc ponechává alokaci a správu bezpečnostních „blobů“ (data specifická pro LSM a objekt) na jednotlivých LSM a necentralizuje je ve frameworku jako Davidovy patche.

Kromě dalších rozdílů je zde zásadní rozdíl ve způsobu, jak se tato dvě řešení chovají v případě, že více LSM má háčky pro jednu bezpečnostní operaci. Glass úmyslně volá každý háček v každém registrovaném LSM, zatímco Davidův návrh typicky přeskočí zbytek řetězu, jakmile některý z LSM přístup zamítl. Casey si myslí, že LSM by měly být schopné udržovat stav, což znamená, že přeskočení jejich háčků může později ovlivnit rozhodnutí o přístupu:

Případ, které se obávám nejvíce, je LSM, který zakládá řízení přístupu na statistické frekvenci přístupů k souboru. Není možné přeskočit kterýkoliv z jeho háčků a takhle narychlo mě nenapadá žádný háček, který by nepoužíval. Slyšel jsem lidi (napadají mě firmy poskytující kreditní karty) takové věci navrhovat a i když pro něco takového nemám použití, nemůžu ignorovat potenciál, že se něco takového objeví.

Je potřeba vyřešit spoustu dalších záležitostí včetně věcí jako práce s /proc/self/attr/current (obsahuje bezpečnostní ID pro současný proces), protože různé programy v uživatelském prostoru již nyní zpracovávají obsah tohoto souboru, přestože se liší podle toho, který LSM je aktivní. Lepší by byl standardizovaný formát, který by bral na vědomí možnost běhu s více LSM, ale to by znamenalo porušit jaderné ABI a pravděpodobně to tedy neprojde. Obecně nicméně Casey a David poměrně dobře pokročili, co se týče definice požadavků pro podporu více LSM. Casey je optimistou s tím, že tato spolupráce ponese ovoce: Myslím si, že se nám tentokrát podařilo překonat problémy, které skládání LSM dříve zabránily.

Zatím je k dispozici pouze Davidův kód, ale Casey slíbil, že Glass brzy zveřejní. Se štěstím to povede na řešení skládání LSM, na kterém se vývojáři LSM budou moci shodnout bez ohledu na to, jestli přijde od Davida, Caseyho nebo společně od obou. Silnější odpor může klást Linus Torvalds a další jaderní hackeři, ale absence způsobu, jak kombinovat LSM, se objevuje příliš často na to, aby to bylo možné ignorovat donekonečna.

       

Komentáře

[Voty]

An unmatched left parenthesis creates an unresolved tension that will stay with you all day. (http://xkcd.com/859/)

Za posledním citátem chybí závorka, tak pěkně děkuju ... )

[kip]

Taky přebývá háček v citátu Jamese Bottomleyho nemají řádi pivo. A ještě v šestém odstavci od konce chybí "t" v Jesliže. V neposlední řadě bych v posledním odstavci ve větě Se štěstím to povede na řešení použil "k" místo "na".

[Wylda]

Při čtení o háčcích jsem si hned vzpomněl na Guru jménem Jára. Možná by jádro potřebovalo taky odháčkovat společně se všema sekjůrity expertama

[Kaacz]

Dnes jsem pochopil, proc vzdy nakonec to hnusne PONDELI preziju. Prectenim jadernych novin se nalada moc zlepsi. Dekuji autorovi.

PS: byl jiz autor tohoto serialu clanku pozlacen ? Pokud ne, melo by se s tim neco udelat.

[JoHnY2]

Zatim jsme ho jen pochromovali, aby nesel prehlidnout. Na zlaceni budou prostredky, az bude Linux vladnou svetu.

[stativ]

No tak to je prasárna (reakce na blog odkazovaný v citátu týdne).

[Luboš Doležel (Doli)]

To je ten cvok, co dělal em28xx-new, kód nesplňoval kvalitu vyžadovanou pro zařazení do jádra, tak svůj repozitář smazal, zanevřel na open source a evidentně mu totálně hráblo.

[geebranz]

Any announcement?

Recognize