Jaderné noviny – 8. 7. 2011: Sandbox, aneb filtry seccomp

18. 7. 2011 | Jirka Bourek | Jaderné noviny | 3187×

Aktuální verze jádra: 3.0-rc6. Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds a další. Seccomp filtry: žádná jasná cesta kupředu.

Obsah

• Aktuální verze jádra: 3.0-rc6
• Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds a další
• Seccomp filtry: žádná jasná cesta kupředu

Aktuální verze jádra: 3.0-rc6

Současné vývojové jádro je 3.0-rc6 vydané 4. července. Obsahuje nový isci ovladač od Intelu, který přidává výrazný kus kódu, ale jinak se jedná o jednoduché opravy. Blíží se to k bodu, kdy si myslím, že bychom měli prostě vydat 3.0, byl poměrně klid a opravy nejsou nijak výrazně zajímavé. Detaily vizte v kompletním changelogu.

Stabilní aktualizace: během minulého týdne žádné nevyšly a žádné se v době psaní tohoto článku nerevidují.

Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds a další

Je ohromující, kolikrát jsem musel průmyslovým zákazníkům vysvětlovat, že Linux nestojí za prd, ale výchozí nastavení jsou stupidní. Pak se ptali, proč autoři či jejich dodavatel jsou totální a naprostí pitomci.

-- Alan Cox

Musím říci, že když se na ty patche dívám, moje mysl se chce věnovat věcem, jako jsou štěňátka. A zmrzlina.

-- Andrew Morton

Tvůj changelog neuspěl v základním testu zmínkou o „okrajovém případu“ jednoduše proto, že celý kód futexů se skládá pouze z okrajových případů.

-- Thomas Gleixner

Uvědomuji si, že je otravné trávit spoustu času na specifické implementaci a pak zjistit, že se začlení kód konkurence. Tohle se bohužel děje pořád a kód, který začleníme, často není ten, kterému se věnovalo nejvíce snahy, ale ten, který v době začlenění vypadá nejslibněji.

-- Arnd Bergmann

A upřímně, Christoph Hellwig teď podruhé řekl, co je na tom ovladači dobré, což je poměrně neobvyklé. Mohlo by to znamenat, že ten ovladač je skvělý. Samozřejmě mnohem pravděpodobnější je, že mimozemšťané na Christophovi testují veselé pilulky. Nebo jenom vyměknul.

-- Linus Torvalds

Seccomp filtry: žádná jasná cesta kupředu

napsal Jake Edge, 7. července 2011

Patche, které rozšiřují funkcionalitu seccomp („secure computing“, bezpečné vykonávání kódu) poletují okolo hlavní řady dva roky, ale dostat se do ní se jim nedaří. Mnoho projektů má zájem rozšířený seccomp používat, ale patche samotné se dostaly do bezvýchodné situace. Jsou tu konfliktní představy o tom, jak by se tato vlastnost měla přidat, a není jasné, která možnost bude akceptovatelná pro všechny relevantní správce. Máme tedy užitečnou vlastnost bez jasné cesty do jádra, což je pro někoho nepochybně frustrující.

Když jsme se před více než dvěma lety poprvé dívali na seccomp sandbox, Adam Langley zaslal patche, které by procesu (a jeho potomkům) umožnily omezit systémová volání, která může provést. Cílem je umožnit procesu uzavřít se do sandboxu tím, že si může zvolit, která systémová volání jsou k dispozici, místo toho, aby byl omezen na natvrdo nastavená systémová volání (read(), write(), exit() a sigreturn()), jak to umožňuje existující implementace seccomp. Podnětem pro Adamovy patche bylo poskytnout jednodušší mechanismus pro omezení procesu webového prohlížeče Chromium – a umožnit odstranění poměrně složitého sandboxu, který Chromium v Linuxu používá nyní.

V té době Ingo Molnár naznačil, že rozšířené seccomp by bylo mnohem užitečnější s filtrováním ve stylu ftrace. Nápad jako takový nebyl všeobecně přijat a seccomp nečinně leželo, dokud ho v dubnu neoživil Will Drewry. Will přijal Ingovy návrhy a implementoval verzi seccomp, která umožňovala povolit, zakázat nebo filtrovat systémová volání jednoduchými výrazy (např. sys_read: (fd == 0)).

I když Ingo byl tímto krokem potěšen, nemyslel si, že zachází dost daleko, a navrhl, aby se místo prctl(), které používá současné seccomp, použilo rozhraní podobné perfu. Měl poměrně široce zaměřené nápady, jak aktivněji použít události výkonnosti [perf events] tak, aby to vedlo k lepším bezpečnostním řešením v jádře, než jaká nabízí existující přístup s linuxovými bezpečnostními moduly [Linux Security Modules, LSM]. Ani tento nápad nebyl přijat všeobecně, zejména vývojáři LSM jím nebyli okouzleni.

Will nicméně implementoval ukázkový patch tak, jak to navrhl Ingo. To vedlo ke stížnostem z poměrně překvapující strany, protože jak Peter Zijlstra, tak Thomas Gleixner naprosto nesouhlasili s použitím perfu v aktivní roli. Jejich odpovědi nenechaly žádný prostor pro kompromisy, protože Peter, který je společně s Ingem jedním ze správců perfu, řekl, že on i Thomas dají NAK každému a všem patchům, které by rozšířily perf/ftrace kamkoliv za roli pasivního pozorovatele.

To všechno vedlo Willa, který se v tu chvíli musel cítit jako někdo polapený mezi dvěma mlýnskými kameny, k návratu k sadě patchů, která podle všeho měla největší podporu: použít filtry ve stylu Ftrace/perf, ale zachovat prctl() rozhraní, které v současnosti používá seccomp. Linus Torvalds vyjádřil svoji skepsi, že by to mělo nějaké reálné použití, ale Will naznačil, jak by ji použilo Chromium, a několik dalších vývojářů se vyslovilo pro rozšíření seccomp s tím, že QEMU, Linuxové kontejnery [Linux containers, LXC] a další věci by tuto vlastnost využily také. Tato podpora společně s vyřešením několika dalších technických záležitostí byla dostatečná k tomu, aby Linus své námitky stáhl. Jak se ale dá uhodnout, Ingo stále s tímto přístupem není spokojen.

Když koncem června Will znovu zaslal sadu patchů a zeptal se, jak dál, Ingo poznamenal, že na jeho námitky není reagováno: V současnosti tlačíš na 'filtrovací engine', nikoliv na (mnohem) jednotnější přístup s 'filtry událostí'. Will se ale snaží najít střední cestu mezi potřebami uživatelů, požadavky ostatních správců a Ingovy požadavky, což je obtížné až nemožné:

Vzhledem k podpoře od potenciálních uživatelů tohoto API věřím, že o tuto sadu patchů je zájem, a mám obavu, že stejně jako u předchozích dvou pokusů za poslední dva roky i tahle série skončí akorát v archivech lwn, kde budou očekávat, že v budoucnu vznikne řešení, které bude používat infrastrukturu, která zatím neexistuje. Snažím se k problému přistoupit způsobem, který je flexibilní a myslí i na budoucnost, místo toho, abych začal pracovat na sérii patchů pro celé jádro, o které nevím, jak ji rozumně integrovat a jestli se k tomu vůbec můžu zavázat.

Ingo je ale neústupný a tvrdí, že přístup s „filtrovacím engine“ je krátkozraký, jako důkaz citoval diffstat různých implementací:

Neděláš to dobře, protože „je to příliš mnoho práce“, obzvláště když ten triviální ukázkový prototyp přinesl něco, co vypadalo velice slibně a docela to fungovalo:

     bitová maska (2009):  6 files changed,  194 insertions(+), 22 deletions(-)
filtrovací engine (2010): 18 files changed, 1100 insertions(+), 21 deletions(-)
  filtry událostí (2011):  5 files changed,   82 insertions(+), 16 deletions(-)

Jsou to pro mě poměrně prázdné argumenty. Diffstat poměrně dobře shrnuje to, co tvrdím o správné struktuře já.

Jak ale Will upozornil, na ukázkovém prototypu je potřeba odvést ještě mnoho práce, než bude všechno kompletně vyřešené. Vzhledem k tomu, že daný přístup dostal několik NAK, odvedení veškeré práce nemá moc dobré vyhlídky. Will by chtěl, aby daná vlastnost byla k dispozici brzy a má obavy z toho, že práce na širších záležitostí ji významně zdrží, pokud se vůbec někdy dostane přes námitky: Pokud bude všechna ta ostatní práce předpokladem pro omezení systémových volání, bude velké štěstí, když něco uvidíme tento kalendářní rok, pokud vůbec za tu dobu dokážu napsat patche.

Inga to ale neodradilo a navrhl, aby se patch do jádra dostal přes strom, který spravuje:

Udělej to správně generalizované – jak ukazuje patch s prototypem. Můžu ti s tím pomoci: mezikroky můžeme hostovat v -tip a můžeme je do upstreamu tlačit krok za krokem. Nebudeš muset udržovat nějaké velké sady patchů. 95 % práce, kterou jsi identifikoval, bude vřele přijato všemi a bude se to používat i mimo sandbox! To není špatná pozice pro to dostat něco kontroverzního do upstreamu: většina bláznivých stromů je bláznivá z 95 %

Problém je v tom, že těch 5 % (tj. omezení systémových volání a sandbox) je ten kus, který by Will a ostatní rádi viděli v jádře. Ingo tedy nabízí poměrně velký kus práce, který by nakonec mohl tu „zajímavou“ část ponechat venku na mraze. Ingo možná věří, že může překonat námitky Petera Zijlstry a Thomase Gleixnera, ale Will takovým optimistou může být jenom těžko. Problém popsal tak, jak ho vidí on:

Přijde mi to jako Hlava 22. Není žádná jasná cesta kupředu a cokoliv, co vypadá jako prototyp ve stylu perfu, bude odmítnuto ostatními správci. I když věřím, že bychom mohli perf vyzvednout z jeho základů a vytvořit sdílené umístění pro události, které by pak bylo možné zdědit (v současnosti nack od Linuse) a (nějak) procházet, rozhraní syscallů v současnosti sdílet nelze (nack od perfu). Vytvořit nové podobné tomu od perfu je možné, ale také není jasné, jaké ABI by měl mít obecný filtrovací systém.

Peter i Thomas se této diskuze neúčastnili, takže je těžké říci, co si myslí. Dokud se ale neobjeví žádné náznaky, že mírní svůj odmítavý přístup, není dobrý nápad věřit, že si něco rozmysleli.

Je to problém, který jsme již dříve viděli, nová vlastnost je do určité míry držena jako rukojmí s požadavkem, aby byl vyřešen větší problém. To bylo diskutováno na Jaderném summitu 2009, kde došlo ke shodě že takové požadavky by pro příště měly být pouze doporučením a ne nutností. V tomto případě Ingo požaduje odvedení větší práce jenom tím, že nemá zájem přijmout kód přes strom -tip, pokud nevyřeší větší problém.

Není jasné, kudy se věci budou ubírat dál. Will řekl, že se to zkusí udělat tak, jak požaduje Ingo (ale jestli moje jediná šance, jak zařídit, aby to bylo přijato, je sdílet kód s perfem a vytvořit nové ABI, pak tuto práci odložím do doby, kdy se s něčím takovým budu schopen vypořádat), ale to může trvat ještě dlouho. V současnosti má několik projektů zájem tuto vlastnost používat.

Pokud návrat k verzi s bitovou masku těmto projektům bude stačit, je možné pokusit se dostat ji do jádra přes jiný strom (např. strom security). Ingo by bezpochyby měl námitky, ale pokud se za tento požadavek postaví dost uživatelů, může to být rozumný přístup. Vzniklo by tím ABI, které by bylo nutné do budoucna udržovat, což je jednou z Ingových námitek, ale pro Chromium a ostatní by to vyřešilo problémy.

Steven Rostedt navrhl prodiskutovat rozšíření seccomp v říjnu na Jaderném summitu, z čehož by mohla vzejít cesta kupředu. Je pravděpodobné, že všechny zainteresované strany budou přítomny, na rozdíl od Linux Security summitu, který se bude konat společně s Linux Plumbers Conference v září a který byl navržen jako alternativa. I když diskuze z očí do očí může pomoci, těžko věřit tomu, že vyřeší neshodu o aktivním vs. pasivním perfu. Na druhou stranu by mohl nějaké stanovisko zaujmout Linus – to by k vyřešení této záležitosti mohlo pomoci hodně.

       

Komentáře

[kernel]

Pěkný seriál a tentokrát zcela přesně přeložený díl seriálu.

[geebranz]

Honestly amazing

Recognize

[frr]

Pokud by někoho zajímalo "co je sakra ISCI", tak je to ovladač pro intelský SAS6Gb řadič v nově uváděném serverovém south bridgi (Patsburg, C600 series). Odkaz byl o jeden klik dál.

[m;)]

http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/