Jaderné noviny - 11. 2. 2016: Napište si vlastní bezpečnostní modul

18. 2. 2016 | Redakce | Jaderné noviny | 2733×

Stav vydání jádra. Napište si vlastní bezpečnostní modul.

Stav vývoje jádra

Současný vývojový kernel nese označení 4.5-rc3 a vydán byl 7. února. Linus k tomu řekl: „Vydání je trochu větší, než bych chtěl, ale ne o moc (a není to nic výjimečného). Většina patchů je celkem malá; mezi změnami dominuje odstranění (velkých) rdma ovladačů ve staging fázi, které se nijak nevyvíjely. Tyto patche představují 90 % objemu změn.“

Stabilní aktualizace: Minulý týden nebyly vydány.

Napište si vlastní bezpečnostní modul

Casey Schaufler zahájil svou řeč na letošním linux.conf.au poznámkou, že případný autor bezpečnostního modulu by mohl slyšet něco jako, že psaní nového bezpečnostního modulu není nutně dobrý nápad. Bylo by mu řečeno, že již máme k dispozici dobrý výběr bezpečnostních modulů nebo že je vše možné udělat v SELinux a že programování pro kernel je beztak těžké. Přesto pro psaní nových bezpečnostních modulů existují dobré důvody. Přednáška byla věnována právě těmto důvodům a seznámení s příslušnou stránkou jádra.

Takže proč psát nový bezpečnostní modul? Současné moduly jsou zastaralé – odpovídají modelu z dob, kdy uživatelé při práci na počítači fyzicky přítomni v příslušné místnosti. Tyto moduly se nehodí k řešení současných problémů; nebyly navrhovány s ohledem na systémy, jako jsou smartphony. Je nejvyšší čas věnovat se metodice, která nepochází z dob děrných štítků. A ne všechno se dá udělat pomocí SELinuxu.

Musíme si uvědomit, k čemu bezpečnostní moduly slouží. Představují způsob, jak přidávat nová omezení k operacím, které se procesy mohly pokusit provést. Nemohou nahradit stávající mechanismy kontroly přístupu, které pracují tak jako tak. Nabízejí tedy nový způsob, jak zabránit operaci, ale nemohou povolit akci, kterou by jinak uživatel vykonat nemohl.

Při přemýšlení o novém bezpečnostním modulu je nutné vzít v potaz několik základních pravidel. Za prvé se chceme vyhnout duplikování existujících modulů. Pokud SELinux dokáže to, co potřebujete, bude lepší, když se připojíte ke komunitě a pokusíte se protlačit svůj zájem. Dalším pravidlem je nespoléhat na pomoc ze strany uživatelského prostoru. Existuje proprietární modul, který požádá uživatelský prostor, aby učinil konkrétní bezpečnostní rozhodnutí. Toto řešení je neefektivní a poskytuje vazbu na proprietární kód – kterýkoli z těchto důvodů by měl postačit k tomu, aby se tento kód nikdy nedostal do upstreamu. Pamatujte, že pracujete na úrovni jádra a že nechcete naštvat jaderné vývojáře. podle Schauflera je to hlavně Al Viro, kterého není radno dráždit.

Nejdůležitějším pravidlem je však volné kopírování ostatních bezpečnostních modulů. Nevymýšlejte znovu kolo. Když Schaufler napsal Smack, vypůjčil si řadu věcí právě ze SELinuxu. Takhle se to dělá v linuxové komunitě.

Jak bezpečnostní moduly fungují

Casey začal o mechanice bezpečnostních modulů povídáním o háčcích (hooks), na které spoléhají. V kernelu se nacházejí funkce, které bezpečnostním modulům umožňují rozhodovat o konkrétních akcích; jejich názvy začínají na „security_“. Moduly používají tyto háčky ke kontrole přístupů a ke všeobecné správě dat; je však nutné psát háčky tak, aby byly relevantní pro daný úkol. Podle běžné praxe vracejí háčky při úspěchu nulu (čímž běžně umožňují provedení požadované operace), EACCES by se měl používat k označení odmítnutí pravidla, zatímco EPERM znamená, že požadované oprávnění chybí.

Spousta (nebo většina) háčků patří k objektově založeným (object-based), to znamená, že se vztahují ke konkrétním objektům v jaderném prostoru. Háčky často pracují se strukturami inode – tyto struktury reprezentují v jádře soubory. Avšak některé háčky pracují s názvy cest. Cesty jsou uživatelsky přívětivější, protože takto uživatelé se soubory pracují, ale nemusí jednoznačně identifikovat odpovídající objekt (např. soubory mohou mít více než jedno jméno).

„Bezpečnostní bloby“ jsou datové struktury připojené k objektům prostřednictvím bezpečnostního modulu. Často se setkáme s pojmy secctx, které odkazují na textový řetězec spojený s blobem, a secid, který představuje 32bitové identifikační číslo pro daný blob. Existují dva typy modulů, označované jako „velké“ (major) a „malé“ (minor) – rozlišuje je skutečnost, že velké moduly používají bloby. V jádře může být aktivní pouze jeden velký modul a je spuštěn po jakémkoli jiném modulu. Zatím neexistuje mechanismus pro sdílení ukazatelů bezpečnostních blobů mezi moduly, Casey se snaží toto napravit doslova křížovou výpravou. Malé moduly proto nemají žádné bloby a neudržují si žádný stav pro každý objekt. K jejich spuštění dochází po příslušné kontrole, ale před spuštěním velkého modulu (pokud existuje).

Před návrhem nového bezpečnostního modulu je třeba odpovědět na několik otázek. První z nich je: Který zdroj má modul chránit? Jestliže nedokážete odpovědět, říká Casey, nemyslíte na bezpečnost. Odpovědí by mohly být soubory vytvořené konkrétním uživatelem či konkrétní cesty v rámci souborového systému nebo může jít o ochranu specifických procesů mezi sebou.

Což vede k druhé otázce, před čím musí být tento zdroj chráněn? Obvykle je bezpečnost založena na uživatelích, ale nyní máme na mysli škodlivé aplikace. Takže než abychom chránili uživatele před sebou samými, musíme se zabývat ochranou dat Facebooku před Netflixem.

A konečně, vývojář bezpečnostního modulu musí také vědět, jak bude ochrana probíhat. Tradiční odpovědí je zkrátka zamítnutí přístupu neautorizovaným uživatelům, ale jsou možné i jiné přístupy. Často se takové pokusy samozřejmě logují. Za zvážení stojí také rozsáhlejší změny, například změna vlastníka souboru tak, aby odpovídal poslednímu uživateli, který provedl zápis skrze skupinový přístup.

Různé detaily

Bezpečnostní moduly zpřístupňují informace přes /proc. Je ovšem dobré vyhnout se pokušení použít názvy atributů podle SELinuxu. Nový bezpečnostní modul by měl mít svá vlastní jména.

Objekty obsahují velké množství různých atributů, které mohou bezpečnostní moduly použít. Patří k nim vlastnictví, režim přístupu, typy objektů a velikosti atd. Moduly je mohou používat dle libosti, ale neměly by měnit jejich základní význam. Uživatelské ID by nemělo identifikovat aplikaci, jako to udělal „jistý systém“. Bezpečnostní moduly mohou činit rozhodnutí na základě názvu cest, pokud to funguje nejlépe, přestože rozhraní k cestám nepatří v kernelu k těm nejlépe použitelným.

Co se týče sítí, nemá toho vývojář bezpečnostních modulů už tolik na práci. Linux obsahuje subsystém netfilter, který může vykonávat všechny druhy rozhodnutí ohledně přístupu, a tento přístup by měl být vždy první na řadě. Jestliže je skutečně třeba napsat nový modul, existují háčky pro různé socketové operace, a také pro doručování paketů. Operace SO_PEERSEC se dá použít k předání bezpečnostních atributů jinému procesu. Práce s unixovými sockety je jednoduchá, protože bezpečnostní moduly mají přístup k oběma koncům připojení. Internetové sockety jsou horší, k dispozici je pouze jeden. K posílání atributů po spojení se dá použít mechanismus CIPSO. Podpora pro IPv6 pro CALIPSO je na cestě.

Casey navrhoval, aby tyto moduly logovaly odmítnutí přístupu, což by mohlo pomoci při odstraňování chyb. Užitečné věci jsou k nalezení v linux/lsm_audit.h. Která data budou zaznamenávána, záleží na autorovi modulu; k formátování dat slouží různé nástroje dostupné v uživatelském prostoru.

Netriviální moduly pravděpodobně potřebují uživatelské rozhraní; administrátoři budou vyžadovat možnost měnit pravidla přístupu, podívat se na statistiky atd. Casey nedoporučuje přidávání nových volání ioctl() nebo systémových volání; místo toho radí vytvořit virtuální souborový systém, což ulehčuje volání sysfs_create_mount_point(). Odpovídající kód se dá vypůjčit z existujícího modulu.

Konečně, co vrstvení bezpečnostních modulů? V současnosti je vrstvení malých modulů jednoduché a doporučuje se, ovšem velký modul může být vždy pouze jeden, vzhledem k tomu, že existuje pouze jeden ukazatel na bezpečnostní blob. Na systémech, kde se kernel překládá ze zdrojových kódů, se dá podvádět – stačí přidat nový bezpečnostní blob do blobu SELinuxu. Na podpoře více velkých modulů současně se pracuje, ale momentálně nemohou být podporovány.

Nakonec Casey zdůraznil, že každý, kdo chce vytvořit vlastní bezpečnostní modul, by k tomu měl mít dobrý důvod. Některé věci opravdu patří do uživatelského prostoru. Máte-li napsat modul, udělejte to pořádně: Poskytněte dokumentaci a podporujte svůj kód. Nesnažte se znovu objevit kolo, obecné zabezpečení je tu už dlouho, vymyslete něco nového. Zatím nikdo neudělal například dobrou politiku řízení zdrojů. Pravidla vázaná na senzory současných zařízení mají velký potenciál. Bezpečnost nemusí být nudná.

Video z přednášky je dostupné na stránkách LCA.

       

Komentáře

[cronin]

Operace SO_PEERSEC se dá použít k obejití odovzdání bezpečnostních atributů k jinému procesu.

[xkucf03]

Současné moduly jsou zastaralé – odpovídají modelu z dob, kdy uživatelé při práci na počítači fyzicky přítomni v příslušné místnosti. Tyto moduly se nehodí k řešení současných problémů; nebyly navrhovány s ohledem na systémy, jako jsou smartphony. Je nejvyšší čas věnovat se metodice, která nepochází z dob děrných štítků.

Co konkrétně je na Bell–LaPadula modelu zastaralé? Neříkám, že nejde vymyslet něco lepšího, ale kdyby se používalo aspoň tohle, dost by to bezpečnosti pomohlo – uživatel by si rozdělil aplikace a soubory do několika úrovní, takže by např. WWW prohlížeč nemohl číst SSH a GPG klíče a na druhé straně, když si dešifruje nějaký tajný soubor, tak se mu nestane, že si ho omylem zapíše třeba do /tmp, odkud si ho přečte nedůvěryhodná aplikace.

[Petr Ježek]

Parádní info, díky. V inspiraci si dovolím pouze jedinou otázku: To je celý systém zabezpečení závislý na explicitní definici zdroje nebezpečí, že je v textu zmíněna specifičnost ochrany před škodlivým kódem (zvenčí, nikoli zavlečeným uživatelem)? Přece je jasné, že pro systém je každý vstup potenciální branou infekce bez ohledu na to, zda díky obyvateli či vnějšímu útoku. SElinux pochopitelně nelze použít v oblasti distant computing (mobilní HW, cloudy...), takže uvedený přístup je zcela namístě.