Zabezpečení SELinuxu: Ovládejte svůj linuxový systém s přesností na milimetr

Informatec Digital » Zdroje » Zabezpečení SELinuxu: Ovládejte svůj linuxový systém s přesností na milimetr

SELinux může znít jako technologie vyhrazená pro kernel geeky, ale ve skutečnosti je to jeden z nejvýkonnějších bezpečnostních nástrojů, které jsou dnes v Linuxu k dispozici . Pokud spravujete servery, zabezpečení kontejnerů Dockeru , cloudovou infrastrukturu nebo i mírně citlivé stolní počítače, pochopení fungování SELinuxu představuje zásadní rozdíl mezi systémem, který je jednoduše „dobře nakonfigurovaný“, a systémem, který je obtížné kompromitovat, a to i s zranitelnostmi typu zero-day.

Navzdory své pověsti „komplikovaného“ systému nabízí SELinux velmi logický model: definuje, co každý proces může dělat a s jakými objekty může komunikovat, a pokud se cokoli odchýlí od tohoto skriptu, jádro to okamžitě zastaví . Místo slepé důvěry v to, že se root bude chovat správně nebo že vaši démoni nebudou mít chyby, SELinux vynucuje povinnou kontrolu přístupu, která platí i pro superuživatele, a to pomocí velmi podrobných popisků a zásad.

Co je SELinux a jaké problémy řeší?

Security-Enhanced Linux (SELinux) je bezpečnostní modul linuxového jádra založený na LSM (Linux Security Modules). Původně byl vyvinut NSA ve spolupráci se společností Red Hat a dalšími partnery a od verze jádra 2.6 je oficiální součástí jádra. Nejedná se o samostatnou aplikaci, ale spíše o rozšíření jádra, které přidává systém povinného řízení přístupu (MAC) a řízení přístupu na základě rolí (RBAC).

Na rozdíl od klasického unixového diskrečního řízení přístupu (DAC) – oprávnění vlastníka, skupiny, ostatních a rwx – v SELinuxu nejsou rozhodnutí o přístupu založena na volbě vlastníka souboru, ale spíše na globálních zásadách stanovených správcem zabezpečení. DAC je stále přítomno a má přednost: pokud DAC zamítne, SELinux nezasáhne; ale i když DAC povolí, SELinux může operaci stále blokovat podle svých zásad.

Architektura SELinuxu jasně odděluje jednotlivé komponenty: na jedné straně kód jádra, který provádí bezpečnostní rozhodnutí , a na druhé straně moduly politik, které definují, co je povoleno a co ne. Toto oddělení umožňuje úpravu pravidel bez nutnosti překompilace jádra a zefektivňuje počet komponent, které mohou ovlivnit bezpečnost systému.

SELinux byl standardně přijat v distribucích jako Fedora, Red Hat Enterprise Linux, CentOS a Scientific Linux a je také hluboce integrován do systémů, jako je Android, kde se používá k omezení systémových procesů a aplikací na velmi specifické domény. Ve světě BSD a GNU/Linuxu existují alternativy jako AppArmor, TOMOYO a TrustedBSD (na macOS/FreeBSD), ale SELinux vyniká úrovní granularity, kterou nabízí nad všemi systémovými objekty.

Od DAC k MAC: proč klasický model už nestačí

V tradičním unixovém systému je model doména-objekt spravován pomocí DAC: každý soubor nebo zdroj má vlastníka a oprávnění a jakýkoli proces spuštěný pod tímto uživatelem si s těmito zdroji může dělat, co chce . To znamená, že pokud démon běží pod root oprávněním, jakákoli zneužitelná chyba může otevřít dveře k ovládání poloviny systému pomocí jeho root kontextu.

Mezi typické příklady patří databáze, jejichž datové soubory by měly být manipulovány pouze prostřednictvím SŘBD, ale které jsou ve skutečnosti čitelné a modifikovatelné procesy s kořenovým UID ; nebo kritické démony běžící s nadměrnými oprávněními. Programovací chyba, přetečení vyrovnávací paměti nebo špatná validace vstupu mohou službu proměnit v dálnici vedoucí k celému systému.

SELinux přidává nad DAC vrstvu povinné kontroly přístupu (MAC) . „Povinná“ znamená, že řízení přístupu je centrálně definováno administrátorem prostřednictvím politik a ani uživatelé, ani procesy nemohou tato pravidla sami uvolnit. Operační systém vynucuje dodržování těchto politik vyhodnocením každé relevantní operace jádra před jejím povolením.

Jádro pomocí LSM hooků dotazuje SELinux na každé citlivé systémové volání (otevírání souborů, vytváření socketů, připojování souborových systémů, komunikace přes IPC atd.). V každém bodě rozhodování SELinux vyhodnocuje operaci na základě načtené politiky a bezpečnostního kontextu subjektu a objektu . Pokud politika explicitně neuděluje oprávnění, akce je zamítnuta bez ohledu na to, zda je proces root či nikoli.

Provozní režimy: vynucovací, permisivní a zakázaný

SELinux může fungovat ve třech jasně odlišených provozních stavech, které je důležité pochopit, aby se v produkčním prostředí nestalo, že by se systém zbláznil:

• VynucováníSELinux je povolen a plně vynucuje pravidla. Všechny akce, které pravidla nepovolují, jsou blokovány a protokolovány.
• PovolnýSELinux je aktivní, načítá zásady a označuje souborový systém, ale neblokuje Zaznamenává transakce pouze tak, jako by byly odmítnuty. To je ideální pro ladění a úpravu zásad.
• invalidníSELinux je zakázán. Nejsou aplikovány žádné zásady ani se neprovádí žádné označování. Systém se spoléhá na klasický model DAC.

Pro rychlé a dočasné změny mezi vynucovacím a permisivním režimem se používá příkaz `setenforce` , kde je režim zadán jako 0 (permisivní) nebo 1 (vynucovací). Je důležité vědět, že tato změna je nestálá: po dalším restartu se režim vrátí k režimu definovanému v konfiguraci.

Pokud potřebujete trvalou změnu, musíte soubor upravit. /etc/selinux/config (nebo /etc/sysconfig/selinux v některých distribucích) a upravte hodnotu direktivy SELINUX=disabled|permissive|enforcingZměny se projeví při dalším spuštění a v mnoha případech budou zahrnovat přejmenování souborového systému.

Aktivní režim můžete zkontrolovat pomocí příkazů jako getenforce nebo sestatus . První z nich jednoduše vrátí hodnotu Enforcing (Vynucování), Permissive (Povolení) nebo Disabled (Zakázáno); druhý poskytuje úplnější souhrn stavu SELinuxu, načtených politik a aktivních modulů.

Bezpečnostní kontexty a systém označování

Srdcem SELinuxu je jeho systém bezpečnostních štítků neboli kontextů . Každý soubor, proces, síťový port, socket, zařízení atd. má přidružený kontext, který popisuje, jak jej lze použít. Tento kontext se skládá z několika polí, která dohromady tvoří pohled SELinuxu na daný objekt.

Obecný formát kontextu je user_u:role_r:type_t:level s určitými nuancemi v závislosti na politice (zejména pokud se používá MLS/MCS). Každé pole má specifický účel: uživatele SELinuxu, roli, typ (také nazývaný doména, když se odkazuje na procesy) a úroveň citlivosti nebo kategorii.

V praxi je nejdůležitějším prvkem typ (třetí pole), protože drtivá většina pravidel politik je formulována jako vztahy mezi typy . Například povolení procesům typu httpd_t přístupu k souborům označeným httpd_sys_content_t nebo povolení komunikace určité domény se sockety označenými http_port_t.

Tyto kontexty jsou uloženy jako rozšířené atributy souborového systémuProto je nezbytné používat souborové systémy, které podporují xattrs (například ext4, XFS atd.). V případě procesů je aktuální kontext a další související kontexty zpřístupněny prostřednictvím pseudo-souborového systému. /proc/<pid>/attr/ v souborech jako current, exec, fscreate, prev, sockcreate nebo keycreate.

Typickými příklady kontextů v systému s cílenou politikou by byly:

• system_u:object_r:httpd_sys_content_t:s0 pro webový obsah poskytovaný Apache nebo Nginx.
• system_u:object_r:home_user_t:s0 pro domovské adresáře uživatelů.
• system_u:system_r:httpd_t:s0 pro spouštěcí doménu samotného webového serveru.

Rozdělení komponent kontextu SELinuxu

Když narazíte na kontext jako unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , může se to jevit jako hieroglyfy, ale každý kus odpovídá specifickému konceptu v rámci SELinuxu a jeho referenční politiky.

El Uživatel SELinuxu (podle konvence s příponou) _uToto není totéž jako uživatel Unixu v /etc/passwd. SELinux si udržuje vlastní databázi uživatelů a mapuje je na uživatele Linuxu. Uživatel SELinuxu může seskupit několik uživatelů Unixu, protože myšlenkou je, aby vrstva MAC byla nezávislá na DAC.

El Role SELinuxu (s příponou _rToto definuje, jaké role může uživatel nebo doména zaujmout. Pokud se používá striktně, nazývá se to plný RBAC. Většina souborových objektů používá roli object_r, zatímco role jako system_r, user_r, staff_r nebo sysadm_r se používají k procesům v závislosti na bezpečnostním kontextu, který musí zaujmout.

El Typ nebo doména SELinuxu (přípona _tV praxi je typ klíčovým prvkem. Typ popisuje třídu objektu nebo doménu provádění procesu. Zásady specifikují, které interakce jsou mezi typy povoleny: které domény mohou číst, zapisovat, provádět nebo komunikovat s kterými dalšími typy objektů.

Úrovně a kategorie se používají, když jsou povoleny zásady víceúrovňového zabezpečení (MLS) nebo vícekategoriového zabezpečení (MCS). Citlivosti jsou hierarchické (např. s0, s1 atd.), zatímco kategorie nikoli (c0, c1, c2, ...). Ve vysoce kritických prostředích – například v některých vládních organizacích – se používají k zajištění toho, aby data bylo možné číst a zapisovat pouze směrem dolů na stejnou úroveň nebo směrem nahoru , a k izolaci dat podle velmi specifických oddílů.

Zásady SELinuxu: cílené, striktní, MLS/MCS a modularita

Zabezpečení vynucované SELinuxem je určeno načtenou politikou . Politika je jednoduše rozsáhlá sada pravidel, která popisují, které domény mohou co dělat s kterými typy, a také další prvky (přechody, pravidla označování atd.). Distribuce obvykle obsahují standardní politiky, takže nemusíte psát vše od nuly.

Nejběžnější politika se nazývá cílená . V tomto režimu běží v rámci omezených domén pouze specifické procesy – zejména síťové služby a vysoce rizikové démony, jako je Apache, Nginx, DNS, proxy, SNMP, syslog atd. Všechny ostatní uživatelské procesy běží v „neomezených“ doménách, kde se v podstatě používá standardní zabezpečení Linuxu spolu s protokolováním určitých akcí.

Existuje také striktní politika , ve které jsou prakticky všechny procesy omezeny na specifickou politiku. Je mnohem bezpečnější, ale může být také podstatně obtížnější ji udržovat, pokud model není dobře pochopen, protože jakýkoli rozpor v označování nebo pravidlech může narušit standardní pracovní postupy.

Pro prostředí s vysokým stupněm zabezpečení existují zásady MLS/MCS (Multi-Level/Multi-Category Security) , které využívají citlivosti a kategorie k zavedení ještě jemnějších kontrol. Tyto zásady jsou typické pro velmi rigidní vojenská nebo administrativní prostředí a kvůli své vysoké provozní složitosti se mimo specifické kontexty používají jen zřídka.

Moderní zásady jsou distribuovány modulárním způsobem . Místo jednoho monolitického souboru zásad se pro specifické služby používají samostatné moduly, což výrazně zjednodušuje správu a aktualizace. Tyto moduly se spravují pomocí nástrojů, jako jsou semodule a semanage module , které umožňují instalovat, odebírat, povolit nebo zakázat části zásad, aniž byste museli pokaždé znovu kompilovat celou zásadu.

Jak SELinux rozhoduje: subjekty, objekty, třídy a oprávnění

Když se proces (subjekt) pokusí o přístup k prostředku (objektu), SELinux koncepčně klade otázku: „Může doména typu X provést operaci Y na objektu typu Z patřícím do třídy C?“ . Odpověď se pak hledá v politice prostřednictvím definovaných pravidel.

V zásadách vynucení typů (TE), které používá většina distribucí a Android, patří každý objekt do třídy (file, dir, fifo_file, tcp_socket, process atd.) a zásada definuje, jaká oprávnění jsou pro každou třídu možná: čtení, zápis, spouštění, bind, připojení, getattr, otevírání a mnoho dalších.

Pravidla TE jsou vyjádřena velmi přímo. Základní příklad by mohl být:

povolit httpd_t http_port_t:tcp_socket name_bind;

Toto pravidlo určuje, že procesy v doméně httpd_t mohou provádět operaci name_bind na TCP socketech označených http_port_t. Tento přístup se zaměřuje na typy a třídy objektů, nikoli na konkrétní cesty , což zabraňuje překvapením při přesouvání souborů nebo změně adresářových struktur.

Například v systému Android se atributy SELinux používají ke seskupování typů pod obecnějšími štítky, jako je `appdomain` , takže jedno pravidlo se může vztahovat na více domén (`untrusted_app`, `isolated_app` atd.) bez opakování definic. Makra jako `rw_file_perms` se také používají ke seskupení několika běžných oprávnění k souborům a ke snížení chyb způsobených přehlédnutím.

Interní stavy, AVC a registr zamítnutí

Když dojde k požadavku na přístup, SELinux nejprve konzultuje mezipaměť Access Vector Cache (AVC) , což je mezipaměť, která ukládá nedávná rozhodnutí o přístupu, aby se proces urychlil. Pokud je rozhodnutí již v mezipaměti, použije se přímo; v opačném případě se dotazuje firewall (vnitřní součást SELinuxu v jádře), který vyhodnotí operaci na základě politiky a kontextu subjektu a objektu.

Pokud neexistuje žádné pravidlo, které by explicitně povolovalo požadovanou akci, výchozím rozhodnutím je deny (zakázat) . Tato filozofie „deny ve výchozím nastavení“ je jedním z pilířů SELinuxu a to, co mu dává robustnost vůči permisivním chybám konfigurace.

Když dojde k odmítnutí v režimu vynucení, jádro zaznamená zprávu typu avc: zamítnuto v systémových protokolech. V závislosti na distribuci se může zobrazit v /var/log/audit/audit.logv /var/log/messages nebo zachyceny démonem auditd. Tyto zprávy zahrnují kontext procesu (scontext), kontext objektu (tcontext), třídu, požadovanou operaci a další data velmi užitečná pro ladění.

V permisivním režimu je operace povolena, ale stále se generuje událost avc: denied označená permissive=1. To je ryzí zlato pro vytváření a úpravy politik, protože umožňuje vidět, co by narušilo systém, pokud by bylo vynucení implementováno bez přerušení normálního provozu.

Integrace SELinuxu do distribucí a Androidu

V ekosystému linuxových serverů a desktopů je SELinux ve výchozím nastavení povolen v... Fedora, RHEL, CentOS a derivátyDebian a Ubuntu poskytují plnou podporu ve svých jádrech a balíčcích, ačkoli aktivace je obvykle volitelná a vyžaduje instalaci balíčků jako selinux-basics, selinux-policy-default a auditd, následovanou globálním přeznačením pomocí fixfiles relabel.

Android původně začlenil SELinux ve verzi 4.3 v permisivním režimu, na částečné použití přešel ve verzi 4.4 (pouze pro kritické domény, jako jsou installd, netd, vold a zygote) a plně integrován je od verze Android 5.0 . Zásady Androidu se zaměřují na izolaci aplikací, systémových služeb a citlivých procesů pomocí typů a atributů s cílem minimalizovat dopad kompromitace na kteroukoli z těchto komponent.

Android používá koncepty jako typ untrusted_app pro běžné aplikační procesy, atributy appdomain pro seskupování aplikačních domén a kategorie MLS/MCS pro izolaci dat mezi aplikacemi a mezi fyzickými uživateli. To vše dohromady zabraňuje tomu, aby napadená aplikace unikla ze svého sandboxu, a to i v případě, že získá velmi široká uživatelská oprávnění.

Důležité: Android zjednodušuje model SELinux ignorováním uživatelů, rolí a pokročilých citlivostí. Existuje pouze jeden uživatel SELinuxu (u), dvě základní role (r pro subjekty a object_r pro objekty) a citlivost je vždy s0. Kategorie jsou to, co rozhoduje o izolaci dat.

Srovnání s AppArmor a dalšími LSM

V mnoha diskusích se nevyhnutelně objevuje srovnání mezi SELinuxem a AppArmorem , protože oba jsou bezpečnostní moduly Linuxu a nabízejí MAC adresy. Jejich přístupy se však značně liší a je vhodné si to uvědomit, než si jeden nebo druhý vyberete pro své prostředí.

SELinux definuje zásady zaměřené na objekty a jejich typy: každému objektu v systému (soubory, procesy, sockety, porty, zařízení, IPC atd.) je přiřazen štítek. Rozhodnutí o přístupu se provádějí na základě kontextu subjektu a objektu, bez závislosti na přesné cestě k souboru. Díky tomu je systém stabilnější tváří v tvář změnám adresářové struktury nebo alternativním zobrazením souborového systému (chroot, kontejnery, bind mounty atd.).

AppArmor na druhou stranu používá zásady zaměřené na úlohy a založené na cestách. Definuje profily pro každý program a určuje, ke kterým cestám k souborům, portům atd. má přístup a s jakými oprávněními. Jeho konfigurace je intuitivnější a obecně uživatelsky přívětivější pro administrátory, kteří se nechtějí stát experty na SELinux, ale jeho ovládání je poněkud méně granulární a více závislé na struktuře souborového systému.

Oba sdílejí princip implicitního odmítání, ale aplikují ho odlišně: AppArmor implicitně odmítá pouze úlohy, které pokrývá profily, zatímco SELinux v striktním režimu jej rozšiřuje na celý systém a všechny označené objekty. V důsledku toho SELinux obvykle nabízí hlubší úroveň omezení , ale za cenu rozsáhlejší a komplexnější politiky.

Praktické nástroje pro správu SELinuxu

Práce se SELinuxem se opírá o řadu nástrojů příkazového řádku, které zjednodušují správu režimů, tagování, booleovských hodnot a modulů politik. I když se to na první pohled může zdát jako ohromující arzenál, několik utilit pokrývá většinu každodenních úkolů.

Chcete-li zobrazit kontext zabezpečení souborů a procesů, můžete použít možnost -Z v běžných příkazech jako ls, ps nebo id. Například ls -Z Kromě oprávnění DAC zobrazí kontext SELinuxu každého souboru, což vám umožní rychle zkontrolovat, zda je označení podle očekávání.

Příkaz `chcon` („změnit kontext“) umožňuje ručně upravit celý kontext souboru nebo pouze jeho určité části (roli, typ, rozsah) pomocí voleb jako `-r`, `-to` a `-l`. Je užitečný pro jednorázové opravy, ale je důležité si uvědomit, že vaše změny mohou být ztraceny, pokud je označení znovu použito podle zásad pomocí nástrojů jako `restorecon` nebo `fixfiles`.

Nástroj semanage je švýcarský nůž pro správu běhových politik. Pomocí různých dílčích příkazů můžete spravovat perzistentní kontexty souborů (fcontext), mapování přihlášení mezi uživateli Linuxu a SELinuxu (login), uživatele SELinuxu a jejich role (user), označené porty (port), booleovské hodnoty a dokonce i moduly politik. To vše bez nutnosti překompilovat celou politiku ze zdrojového kódu.

Pro kontrolu a změnu stavu booleovských proměnných – malých přepínačů, které povolují nebo zakazují bloky pravidel v rámci politiky – se kromě samotné booleovské proměnné setsebool používají také proměnné getsebool a setsebool . Typickou booleovskou proměnnou je httpd_enable_homedirs, která, když je aktivní, umožňuje webovému serveru přístup k domovským adresářům uživatelů (užitečné pro ~user/public_html/).

Konečně, příkazy jako fixfiles umožňují vynutit úplné přejmenování souborového systému podle definovaných pravidel a semodule se postará o instalaci, výpis, povolení nebo zakázání modulů zásad (.pp) zabalených a distribuovaných referenční zásadou nebo administrátorem.

Vytváření a úprava vlastních zásad

Pokud aplikace nemá vlastní modul SELinux nebo potřebujete specifičtější omezení, je čas pustit se do práce a vytvořit si vlastní zásady . Může to znít složitě, ale pracovní postup je docela dobře definovaný, pokud pečlivě dodržíte určité kroky.

Prvním krokem je zajistit, aby relevantní objekty (spustitelné soubory, datové adresáře, sockety atd.) byly označeny příslušnými typy. Toho lze dosáhnout definováním pravidel kontextu souborů pomocí ` semanage fcontext` a jejich aplikací pomocí `restorecon`, přičemž regulární výrazy zahrnují celé adresářové stromy.

Systém je poté obvykle přepnut do permisivního režimu pro daný počítač (nebo v některých případech pro konkrétní doménu) a aplikace může běžet normálně, zatímco SELinux zaznamenává všechny příkazy `avc: denied` , které by mohly nastat. Tyto protokoly, obvykle analyzované nástroji jako audit2allow , se používají k extrakci kandidátských pravidel.

Referenční zásady jsou obvykle strukturovány do tří souborů na aplikaci: soubor .te obsahující pravidla TE (allow, type, domain_type atd.), soubor .fc obsahující pravidla kontextu souborů a soubor .if obsahující veřejná rozhraní, která mohou ostatní moduly znovu použít. To vše je zkompilováno do modulů .pp ​​pomocí make a načteno pomocí semodule.

Je zásadní nevěřit slepě všemu, co audit2allow navrhuje: má tendenci být více tolerantní, než je nezbytně nutné . V ideálním případě byste měli ručně zkontrolovat navrhovaná pravidla, v případě potřeby vytvořit nové typy pro oddělení citlivých dat od irelevantních a pokud zamítnutá operace není kritická, zvážit použití pravidel dontaudit k zastavení nahrávání šumu bez udělení oprávnění.

V prostředích jako SUSE Linux Micro nebo Android jsou k dispozici další nástroje (například Udica pro generování politik kontejnerů z popisů JSON), které automatizují část procesu rychlým přizpůsobením politiky konkrétním kontejnerům, aniž by se bylo nutné učit celý jazyk politik od nuly.

Celý tento ekosystém kontextů, modulárních politik, booleovských hodnot a nástrojů pro správu dělá ze SELinuxu extrémně robustní a flexibilní bezpečnostní platformu . S určitou počáteční investicí do učení umožňuje velmi přesné omezení toho, co může každá služba nebo aplikace dělat, a drasticky tak posiluje útočnou plochu systému proti exploitům, malwaru a lidským chybám.