Jaderné noviny – 19. 1. 2012: Pořádný sandbox v jádře blíž k realitě

30. 1. 2012 | Luboš Doležel | Jaderné noviny | 3723×

Aktuální verze jádra: 3.2. Citáty týdne: Casey Schaufler, Linus Torvalds, Steven Rostedt, Robert Morell. Druhá část začleňovacího okna verze 3.3. Filtrování systémových volání a no_new_privs.

Obsah

• Aktuální verze jádra: 3.2
• Citáty týdne: Casey Schaufler, Linus Torvalds, Steven Rostedt, Robert Morell
• Druhá část začleňovacího okna verze 3.3
• Filtrování systémových volání a no_new_privs

Aktuální verze jádra: 3.2

Nejaktuálnější verzí je verze 3.2 vydaná 4. ledna. Začleňovací okno verze 3.3 je stále otevřené, více o tom, co bylo v uplynulém týdnu začleněno, se dozvíte níže. Verzi 3.3-rc1 pravděpodobně můžeme očekávat brzy.

Stabilní vydání: Stabilní jádro 3.1.10 vyšlo 18. ledna. Toto je poslední stabilní aktualizace v řadě 3.1.x, takže uživatelé by měli přejít na řadu 3.2.

Kromě toho vyšly 12. ledna stabilní verze 2.6.32.54, 3.0.17, 3.1.9 a 3.2.1.

Citáty týdne: Casey Schaufler, Linus Torvalds, Steven Rostedt, Robert Morell

Ani na vteřinu si nemyslete, že někdo něco neudělá jen proto, že je to evidentně nevhodné.

-- Casey Schaufler

Myslím si, že tento řádek by tam neměl být vůbec. Nemá žádný smysl... uvědomuji si, že jsem jej napsal, a že tedy musí být bezchybný, ale myslím si, že odstranění tohoto řádku je ještě *více* bezchybné.

-- Linus Torvalds

Sledovací body [tracepoints] se kupí jako dluh USA. Musíme stanovit nějaká pravidla. Buď vytvořením knihovny, která je schopná ošetřit drobné změny (jako jsou ty, co tu diskutujeme, i když memcpy by se s tím mělo vyrovnat), nebo musíme zarazit přidávání nových sledovacích bodů, protože je to novodobá móda. Snad bychom mohli sledovacím bodům dát stejná pravidla jako systémovým voláním.

-- Steven Rostedt

Práce na dma-buf původně začaly s cílem sjednotit několikero soupeřících systémů „pro správu paměti“, které byly vyvinuty s ohledem na různé ARM SoC. Bylo by nemilé, kdyby vyhrazení použití dma-buf pro moduly licencované pod GPL, omezilo jeho rozšíření.

-- Robert Morell z NVIDIA

Druhá část začleňovacího okna verze 3.3

V době psaní textu bylo do hlavní řady přetaženo téměř 8800 neslučovacích změn pro vývojový cyklus 3.3 – 2900 od souhrnu z minulého týdne. V druhém týdnu se tempo začleňování změn jednoznačně snížilo, ale i tak byla začleněna řada zajímavostí.

Změny viditelné uživatelům od posledního týdne zahrnují:

• Jádro získalo schopnost ověřovat digitální podpisy RSA. Této schopnosti využívá rozšířený ověřovací modul (extended verification module; EVM).
• Slab alokátor podporuje nový bootovací parametr slab_max_order=, který nastavuje maximální velikost slabu. Nastavením na větší číslo můžete zvýšit efektivitu paměti s následkem zvýšení pravděpodobnosti selhání alokací.
• ALSA získala podporu komprimovaného zvuku u zařízení, která to podporují.
• Byly učiněny velké změny v kódu pro kompakci paměti, aby se zabránilo dlouhým zásekům, na které naráží někteří uživatelé při zápisu na pomalá zařízení (například USB flashky). Problém byl popisován ve starších Jaderných novinách, ale řešení se od té doby znatelně posunulo dál. Tím, že byla učiněna řada změn v tom, jak kompakce funguje, se hackerům přes správu paměti (a hlavně Melu Gormanovi) podařilo vyhnout se zákazu synchronní kompakce, který má nežádoucí dopad na používání velkých stránek. Více informací o tom, jak byl problém vyřešen, najdete v tomto commitu.
• Přibyl subsystém „správy nabíječky“ určený pro použití s bateriemi, které se musí občasně hlídat, a to i když je systém uspaný. Správce nabíječky pak může dle potřeby částečně systém probudit, aby se dotázal baterie a následně opět uspal systém. Více informací naleznete v dokumentaci.
• Kód Btrfs pro vyvažování/restriping byl přepracován, aby byl přizpůsobitelnější v tom, jak je jednotka přeskládána. Operace restriping může nyní být pozastavena, zrušena nebo obnovena po pádu.
• Na architektuře ARM je nyní podporován subsystém auditu.

Mezi změny viditelné vývojářům patří:

• Byly začleněny patche pro paměťové řídící skupiny. Tyto patche odstraňují dvojité sledování paměti a tudíž značně snižují režii spojenou s řadičem paměti.
• Subsystém zařízení framebufferu má nové konfigurační API na bázi FOURCC, pro více podrobností vizte dokumentaci.
• Souborový systém Btrfs získal nástroj pro kontrolu integrity, který sleduje provoz jdoucí k úložišti a vyhledává operace, které by mohly souborový systém ponechat poškozený, pokud by v nevhodném čase došlo k selhání systému. Pro více informací vizte fs/btrfs/check-integrity.c.

Vydání 3.3-rc1 se může objevit každou chvíli, poté bude zahájen proces stabilizace. Pokud bude platit obvyklé načasování, pak můžeme konečnou verzi 3.3 očekávat v druhé polovině března.

Filtrování systémových volání a no_new_privs

Už 12. ledna se zběžně psalo o návrhu na omezování systémových volání pomocí jaderného mechanismu filtrování paketů, ale v té době ještě tento návrh nekomentoval. Od té doby proběhlo několik kol komentování a revidování patchů spolu s oživením původní myšlenky dát procesu možnost omezit sebe sama a své potomky na aktuální úroveň oprávnění. Zatím byla odezva celkově pozitivní, a to natolik, že to vypadá, že se obecné filtrování systémových volání může dostat do hlavní řady v dohledné budoucnosti.

Už nějakou dobu se Will Drewry snaží najít přijatelný způsob, jak rozšířit funkčnosti seccomp v jádře do podoby, kdy je možné dělat flexibilnější filtrování systémových volání. Jde mu o prohlížeč Chrome/Chromium a umístění nedůvěryhodného kódu do sandboxu, ale i jiné projekty (včetně QEMU, openssh, vsftpd a další) projevily o tuto funkci zájem. On (a jiní) zkusili v posledních několika letech různé způsoby, aniž by se našel nějaký, který by vyhověl požadavkům. Jeho poslední pokus používající BPF (Berkeley Packet Filter) pro filtrování systémových volání vypadá, že se vyhýbá mnoha problémům, na které bylo při dřívějších pokusech poukázáno.

Hlavní myšlenkou je to, že namísto zkoumání obsahu paketů budou filtry zkoumat systémová volání a všechny argumenty předané v registrech (což znamená, že nebude následovat ukazatele, aby nedocházelo k race situacím kvůli odlišnému času kontroly a použití). Kód povolí jen ta volání, která projdou filtrem. Všechna volání, která nejsou na seznamu filtru nebo jejichž argumenty neodpovídají pravidlům ve filtru, vrátí chybu EACCES. Syntaxe vytváření filtru popsaná v dokumentaci je dosti nepříjemná, ale Eric Paris už začal pracovat na překladači, který převede čitelnější formu na pravidla BPF.

Aby se obešel dlouhotrvající problém s interakcí mezi binárkami, která mohou měnit svá práva (např. setuid), a mechanismy omezujícími práva procesů, Drewrův původní patch omezuje schopnost procesu učinit volání execve(), jakmile je nastaven filtr. Problém je v tom, že binárky měnící práva mohou být zmateny, když jsou v prostředí, kde mají méně práv, než očekávají. Toto zmatení může vést k eskalaci práv nebo bezpečnostním chybám. To je ten důvod, proč jsou chroot(), bind mounty a ve výsledku i uživatelské jmenné prostory omezeny na procesy s právem roota.

Jakmile ale filtrovaný proces nemůže úspěšně zavolat execve(), všechny obavy o zmatení binárek mizí. Ve výsledku to ale používání filtrování systémových volání činí poněkud neohrabaným. Člověk by čekal, že rodič nastaví filtry a pak spustí potomka, který by byl těmito filtry omezen, ale to by bez možnosti udělat exec nefungovalo. Toto se dá obejít u většiny programů pomocí fíglu s LD_PRELOAD, ale v rámci diskuze se objevilo i jiné řešení.

Andrew Lutomirski poukázal na svůj návrh execve_nosecurity jako na možné řešení. To by procesům umožnilo nastavit příznak, že oni (a jejich potomci) nemohou zavolat execve() a přidala by se nová varianta (s trochu matoucím názvem execve_nosecurity()), která by mohla být použita místo toho, ale u spuštěného programu by nedošlo ke změnám v právech. To znamená, že setuid, změny kontextu LSM, změny capabilities a tak dále by nebyly povoleny. Linus Torvalds souhlasil, že přidání možnosti omezit změny oprávnění by bylo užitečné:

Mohli bychom snadno zavést příznak procesu, který znamená „nemůže zvýšit oprávnění“. To by v podstatě zakázalo execve suid/sgid programů (a možná i dalších věcí a omezilo práva aktuálního procesu na ta stávající. A pak by se udělalo pravidlo, že *pokud* je tento příznak nastaven, můžete filtrovat napříč execve nebo chroot jako obyčejný uživatel nebo něco jiného.

To vedlo Lutomirského k návrhu příznaku v struct task_struct nazvanému no_new_privs, který by byl nastaven pomocí příznaku PR_SET_NO_NEW_PRVIS přes prctl(). Byla by to jen taková jednosměrná jízdenka, protože by nebylo cesty zpět, tedy jak příznak zrušit. Pokud by byl příznak nastaven, došlo by k omezení spouštění binárek podobně jako přes příznak mountu nosuid. Navíc by bylo procesu zakázáno měnit capabilities při exec nebo přecházet mezi kontexty SELinuxu.

Lutomirského patche ale neimplementuje sandbox, protože, jak Alan Cox upozorňuje, jej stále jde ošidit přes ptrace(). Cox měl také obavy, že zamezení SELinuxu, AppArmoru nebo jiným LSM měnit práva může vést k dalším problémům, neboť tyto přechody mohou být i ve směru k nižším oprávněním. Prosté zachování předchozího kontextu, jako to dělá Lutomirského patch, může vést ke spouštění programů s více právy. Ale Eric Paris sdělil, že přinejmenším SELinux bude stále dělat stejná rozhodnutí i bez přechodu (jako to dělá u mountů s nosuid), takže spuštění tak jako tak selže, pokud má proces nesprávný kontext.

Lutomirski také poznamenal, že sandbox bude mnohem méně užitečný, pokud execve() musí selhat, jakmile dochází k jakékoliv změně práv, jak Cox navrhoval. Přítomnost pravidel u konkrétní binárky by pak učinilo binárku nepoužitelnou ze sandboxu, ať už jsou pravidla jakákoliv. Lepším řešením by podle Lutomirského bylo nastavit bit no_new_privs, pak vytvořit sandbox (například za použití filtrování systémových volání přes seccomp od Drewryho) a pak spustit binárku, což by uspělo nebo selhalo v závislosti na aktuálních pravidlech mandatory access control (MAC). To řeší problém s ptrace() a dalšími metodami, jak zabezpečení obejít, protože sandbox vyžaduje jak patch no_new_privs, tak nějaký další mechanismus pro filtrování systémových volání:

no_new_privs není vůbec zamýšleno jako sandbox – jde o způsob, jak umožnit procesu v bezpečí zacházet sám se sebou takovým způsobem, který by mu umožnil poškozovat své vlastní potomky (nebo sebe sama po execve). Takže ptrace vůbec není problém – PR_SET_NO_NEW_PRVIS + chroot + ptrace je přesně tak nebezpečné jako ptrace bez PR_SET_NO_NEW_PRVIS. Ani jedno neumožňuje povýšení práv nad to, na čem jste začali.

Pokud chcete sandbox, zavolejte PR_SET_NO_NEW_PRVIS, pak povolte seccomp (nebo něco jiného) pro zakázání ptrace, zlomyslného přístupu k souborů, připojení k unixovým soketům, které se ověřují přes uid atd.

Drewry mezitím revidoval své patche, aby využil no_new_privs. Jedna z těchto revizí vedla k dalším obavám, zda by snižování práv mělo po nastavení bitu být povoleno. Torvalds má obavy, že povolení snižování práv by mohlo nějak vést ke zmatení ostatních programů: Už jsme tu měli bezpečnostní chyby *kvůli* snížení oprávnění – někdo odebral jedno oprávnění, ale už ne jiné, čímž navedl kód k činnostem, které nebyly očekávány. Lutomirského patch neomezuje věci jako volání setuid(), protože není určen k implementaci sandboxu – to je to, co dělá stávající seccomp nebo rozšířená verze z Drewryho patchů (neboli seccomp režim 2). Lutomirski vysvětluje:

Dá se to jinak říci takto: no_new_privs není sandbox. Je to jen způsob, jak sandboxům a jiným zvláštním věcem, co si procesy mohou provést, umožnit bezpečně pracovat napříč execve. Pokud chcete sandbox, použijte seccomp režim 2, což bude vyžadovat nastavení no_new_privs.

Je jasné, že si přinejmenším Lutomirski myslí, že no_new_privs nemůže vést k problémům, jakých se Torvalds a jiní (hlavně vývojář Smacku Casey Schaufler) obávají. Ale každý program, který používá no_new_privs, si musí být vědom toho, co to dělá (a co ne). Ve spojení s mechanismy pro filtrování systémových volání to vypadá, že to může jen vést ke zvýšení bezpečnosti systému. Ale interakce mezi bezpečnostními mechanismy často mají nepředvídané následky, často vedoucí k bezpečnostním chybám, takže má smysl dávat si pozor.

Prozatím jsou tyto změny stále diskutovány a žádný ze správců subsystémů neprojevil zájem si je pod sebe vzít, ale oba návrhy získaly podporu, kterou se předchozím nápadům nepodařilo získat. Zda dokáže Lutomirski přesvědčit ostatní jaderné hackery, že no_new_privs nemůže vést k jiným problémům, nebo zda musí vymyslet, jak zabránit odebírání práv, to není jasné. Ale vypadá to, že se konečně může rozšířený seccomp dostat do hlavní řady.

       

Komentáře

[kralyk z abclinuxu]

Jádro má schopnost ověřovat RSA? A proč? Za chvilku bude v jádře fakt všechno... Userspace je potom k čemu?

[Bedňa]

To by malo byť hlavne kvoli bezpečnosti embedded zariadení, aby to fungovalo out of the box.

[A]

V roku 2025 bude samotne jadro dodavane na dvoch DVDckach

[i]

V roce 2025 budou DVD? mozna asi jako dnes diskety ?

[ynezz]

evm: digital signature verification extension

[ynezz]

The motivation for integrity protection, in general, is to protect against offline modifications. The runtime protection is ensured via access control mechanisms. Of particular importance is protecting users or owners from being sold or given tampered devices, which can do nasty things such as spying or stealing personal data. Integrity protection ensures that modifications of the system will not remain undetected. The EVM digital signature extension makes this feasible for consumerelectronics/embedded devices.

[rADOn]

Jinak receno je to k zamykani telefonu a podobnych cihel proti rootovani. Aby nahodou ovecky nespachaly nejaky jeste horsi zlocin nez "spying or stealing personal data", treba pouzivat svoje zarizeni.

[ynezz]

Jsem rad, ze ziju ve svete kde je tolik odborniku, kteri nam to dokazi tak krasne vysvetlit ve dvou vetach

[Pali]

Práce na dma-buf původně začaly s cílem sjednotit několikero soupeřících systémů „pro správu paměti“, které byly vyvinuty s ohledem na různé ARM SoC. Bylo by nemilé, kdyby vyhrazení použití dma-buf pro moduly licencované pod GPL, omezilo jeho rozšíření.

Nie je to nahodou hlavny zamer jadra, aby boli ovladace otvorene (kedze je cele jadro pod GPL)? Urcite nie je pre NVIDIU pekne, ze cele jadro je pod GPL. Najradsej by ho asi forkli, pozmenili, zatvorili a potom predavali...

Naozaj som nepochopil, co tym chce NVIDIA dosiahnut...

[Luboš Doležel (Doli)]

Nie je to nahodou hlavny zamer jadra, aby boli ovladace otvorene (kedze je cele jadro pod GPL)? Urcite nie je pre NVIDIU pekne, ze cele jadro je pod GPL. Najradsej by ho asi forkli, pozmenili, zatvorili a potom predavali...

To si nemyslím. Ovladače jen prostě nedostaly od právního oddělení zelenou a teď se jejich programátoři (kteří by jistě sami byli nejradši, kdyby jejich práce byla open source) snaží bojovat proti redundanci...

[rADOn]

Souhlas. AFAIK ovladace nvidie jsou uzavreny protoze je v nich cizi licencovany kod ktery otevrit nemuzou. A na rozdil od jinych komercnich linuxovych sracek jsou detonatory dobre podporovany. Nebrani redistribuovat ovladace jako balicky, narozdil treba od oracle. Nehrajou alibisticky hry "podporujeme pouze red hat z mladsi doby kamenne" a primerene sledujou vyvoj kernelu a X. Nelzou o tainted priznaku Otevreny ovladac by sice potesil, ale OTOH kdyby vsechen komercni shit byl aspon na teto urovni, uplne by to stacilo.

[pavlix]

AFAIK ovladace nvidie jsou uzavreny protoze je v nich cizi licencovany kod ktery otevrit nemuzou.

AFAIK se toto používá jako univerzální výmluva, podobně jako se třeba krize používá jako univerzální výmluva pro to, abys dostal za práci míň peněz a ještě pozdě.

Cizí kód, stejně jako krize, může v konkrétních případech být skutečným důvodem. Ale čím víc je ta výmluva známá, tím měnší je podíl případů, kdy je opravdu relevantní.

Otevreny ovladac by sice potesil, ale OTOH kdyby vsechen komercni shit byl aspon na teto urovni, uplne by to stacilo.

Jak komu. Ale o problému uzavřenosti driverů jsem se rozepisoval už tolikrát...

[Max]

Oj, tak ve 3.2 už by měly být nějaké optimalizace kvůli uživatelským odezvám (zásekům) při diskových operacích a ve 3.3 se chystají další. Parádička.
Zdar Max

[JS]

Cetl jsem to jen zbezne, a nejsem odbornik na bezpecnost, ale zda se mi to, nebo je opravdu tezke vymyslet opravdu neprustrelny a obecny bezpecnostni mechanimus v ramci OS, ktery by sel nad ramec privilegovany/neprivilegovany?

Nebo uz nekdo nekde vymyslel nejake tridy opravneni mezi tim, a dokazal, ze nejsou ekvivalentni ani privilegovane, ani neprivilegovane? Docela by me to zajimalo...

[mimi.vx]

jo , to je celkem problem ...

 

ono existuje dost experimentalnich systemu snazici se toto resit (treba Singularity od M$) ale kompaktibilita je s zbytkem sveta prakticky nulova. ...

[Sten]

Samozřejmě, existuje několik operačních systémů založených na oprávněních (capability-based), některé jsou i daleko lepší (třeba EROS nebo Coyotos), ale nějak se neujaly. Jaksi nejsou kompatibilní se současnými systémy.

[JS]

Aha, diky, to je zajimave. I kdyz to, ze je neco capability-based, jeste zdaleka neznamena reseni problemu, co jsem nastinil. Navic si myslim, jak na to koukam, ze duvod, proc se neujaly spis je, ze jsou velmi mlade a vlastne ani hotove. V podstate to potvrzuje muj puvodni pocit, ze je to tezky problem.

[m;)]

Capsicum: practical capabilities for UNIX -- http://www.cl.cam.ac.uk/research/security/capsicum/