- SELinux vynucuje povinné řízení přístupu na základě politik a kontextů, čímž přidává kritickou vrstvu zabezpečení oproti tradičním oprávněním Unixu.
- Efektivní konfigurace vyžaduje správné označení souborového systému, výběr vhodného režimu (povolující/vynucující) a úpravu booleovských hodnot a modulů bez oslabení základní politiky.
- Integrace SELinuxu s RHEL, Fedorou, SUSE a openSUSE umožňuje zmírnit dopad mnoha CVE a omezujících služeb, jako jsou webové servery, kontejnery a síťové démony.
- Automatizace zabezpečení a systematické používání protokolů a nástrojů, jako je audit2allow, usnadňuje udržování provozuschopnosti SELinuxu v produkčním prostředí bez obětování stability.
Když nastavujete linuxový server pro produkční provoz, jeho výchozí konfigurace je obvykle poměrně otevřená. Je navržen tak, aby fungoval perfektně ihned po instalaci, ne jako pevnost . A právě zde přichází na řadu SELinux jako klíčová součást pro posílení ochrany: přidává vrstvu kontroly, která funguje i v případě selhání typické obrany (souborová oprávnění, firewall, aktualizace ).
SELinux se může zpočátku zdát skličující, ale jakmile pochopíte jeho základy, stane se neuvěřitelně mocným nástrojem pro omezování exploitů, omezení škod a splnění bezpečnostních standardů, jako jsou CIS, PCI DSS nebo jiné vysoce kritické standardy. Místo toho, aby se systém spoléhal na to, že se aplikace budou chovat normálně, nutí každý proces fungovat v rámci velmi specifických hranic.
Co je SELinux a proč je důležitý pro zabezpečení Linuxu?
Security-Enhanced Linux je rozšíření zabezpečení linuxového jádra založené na povinném řízení přístupu (MAC). Na rozdíl od klasického unixového diskrečního řízení přístupu (DAC), kde vlastník souboru rozhoduje, kdo má k souboru přístup, jsou v SELinuxu pravidla diktována centrální politikou, kterou ani uživatelé root nemohou přepsat bez její explicitní změny.
Tento model zajišťuje, že rozhodnutí o přístupu jsou založena na bezpečnostních štítcích (kontextech) a předdefinovaných pravidlech , nikoli pouze na oprávněních rwx. I když byla služba napadena nebo má nadměrná oprávnění, SELinux jí může zabránit v přístupu k citlivým souborům, spouštění jiných procesů nebo pohybu po síti za její autorizované hranice.
SELinux nenahrazuje tradiční DAC, ale doplňuje ho. Nejprve se kontrolují standardní oprávnění Unixu a pouze pokud DAC operaci povolí, SELinux zasáhne a ověří svá pravidla . Pokud DAC již přístup blokuje, SELinux nezasahuje ani nic nezaznamenává, což pomáhá snižovat šum v protokolech a udržovat výkon.
Tento vrstvený přístup je obzvláště patrný v podnikových prostředích , jako jsou Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise nebo openSUSE Leap , kde je SELinux integrován se zbytkem bezpečnostních mechanismů systému a s moderními technologiemi, jako jsou kontejnery a virtuální počítače.
Klíčové koncepty: Zásady, kontexty a domény SELinuxu
Základem SELinuxu jsou bezpečnostní zásady, které popisují, kdo co může dělat, proti čemu a jak . V tomto jazyce jsou procesy považovány za subjekty a systémové prostředky (soubory, adresáře, sockety, porty, zařízení atd.) za objekty.
Místo toho, aby SELinux vnímal uživatele jako „root“ nebo „www-data“, pracuje s domény a typyNapříklad proces webového serveru Apache běží v doméně httpd_t, zatímco soubory poskytované klientovi mají typ jako httpd_sys_content_tTato politika definuje, které domény mohou přistupovat ke kterým typům, pro které třídy objektů (soubor, adresář, socket, port…) a s jakými specifickými oprávněními (čtení, zápis, spouštění, getattr, přidávání atd.).
Každý objekt má přidružený kontext SELinuxu , návěstí ve tvaru:
usuario:rol:tipo:nivel
Například soubor by mohl být označen jako system_u:object_r:httpd_sys_content_t:s0Kde Nejdůležitější oblastí pro každodenní administrativu je obvykle typ (httpd_sys_content_t), který určuje, kterým procesním doménám bude povolen přístup.
V praxi SELinux pracuje s tisíci pravidel. Aby se zabránilo tomu, aby se tato situace stala nezvládnutelnou, jsou zásady rozděleny do nezávislých modulů, které lze povolit, zakázat nebo aktualizovat bez nutnosti rekompilace obrovského monolitické bloku. To je klíčové v RHEL, SUSE a openSUSE, kde každá relevantní služba obvykle má svůj vlastní modul zásad.
Provozní režimy SELinuxu: vynucovací, permisivní a zakázaný
SELinux může fungovat ve třech odlišných režimech, které určují rozsah, v jakém jsou jeho pravidla aplikována na systém v reálném čase :
V režimu vynucení jádro striktně vynucuje pravidla. Jakákoli akce, která porušuje pravidla, je blokována a protokolována . Toto je doporučený režim pro produkční prostředí, když jsou pravidla dobře vyladěna, protože právě zde SELinux poskytuje skutečnou ochranu.
V permisivním režimu SELinux pokračuje ve vyhodnocování zásad, ale nic neblokuje . Všechna porušení jsou zaznamenávána jako varování. Tento režim je ideální pro testování, nasazování nových aplikací nebo doladění pravidel, protože umožňuje detekovat, co by mohlo narušit vynucování, aniž by to přerušilo služby.
V zakázaném režimu je SELinux zcela zakázán. Nejsou vynucovány žádné zásady ani nejsou generovány žádné protokoly související se SELinuxem. Přepínání mezi zakázaným a aktivním režimem (povolujícím nebo vynucujícím) vyžaduje restart, protože jádro se musí spustit s inicializovanou podporou SELinuxu, aby bylo možné označit souborový systém.
Velmi rozumným postupem v jakékoli distribuci je nejprve začít s permisivním nastavením , zkontrolovat a opravit problémy s tagy a zásadami a přejít k vynucování nastavení, až když je vše stabilní . Trvalé vypnutí této funkce odstraní jednu z nejúčinnějších vrstev ochrany, které máte k dispozici.
Integrace SELinuxu do RHEL, Fedory, SUSE a openSUSE
Distribuce jako Red Hat Enterprise Linux, Fedora a odvozené verze standardně povolují SELinux , obvykle pomocí cílené politiky, která omezuje systémové služby spouštěné systemd a některými uživateli.
V RHEL je kromě předkonfigurovaných zásad k dispozici řada nástrojů, které administrátorovi zabrání v neustálém boji s nízkoúrovňovými pravidly. Vyniká SELinux Troubleshooter, který analyzuje události odmítnutí a navrhuje konkrétní změny (například aktivaci booleovské hodnoty, opravu kontextu nebo generování dalšího modulu).
SELinux se dále rozšiřuje na kontejnery (například s Podmanem) a virtualizovaná prostředí. S vhodnými tagy je každý kontejner nebo virtuální stroj izolován od ostatních na úrovni jádra, a to i v případě, že je ohrožena zranitelnost v běhovém prostředí nebo hypervisoru.
V ekosystému SUSE obsahuje SUSE Linux Enterprise Server framework SELinux ve svém jádře a nástrojích , ale ne komplexní oficiální zásady. Doporučeným přístupem je vytvořit si vlastní zásady přizpůsobené vašemu prostředí nebo použít řešení jako slemicro, pokud chcete minimalistický hostitel pro kontejnery nebo virtualizaci s plnou podporou SELinuxu.
V openSUSE Leap je běžné spoléhat se pro testování na zásady dostupné v repozitářích, jako je security:/SELinux_legacy , s vědomím, že pro kritické prostředí je ideální stále zásada zkontrolovaná a upravená specificky pro dané nasazení.
Modely politik SELinuxu: cílené, MLS a minimální
SELinux může pracovat s různými modely politik, které určují šířku a hloubku kontroly. Tři nejběžnější jsou:
Cílená politika je navržena pro obecná prostředí. Zaměřuje se na omezení specifických služeb (zejména síťových démonů) a ponechává ostatní procesy v permisivnějších doménách nebo dokonce bez omezení. Je to výchozí možnost ve většině distribucí, protože dosahuje dobré rovnováhy mezi zabezpečením a kompatibilitou.
La Zásady víceúrovňového zabezpečení (MLS) Přidejte do kontextu pole úrovně citlivosti (s0, s1, s2, kategorie atd.) a umožňuje klasifikovat informace a procesy do úrovníJe určen pro organizace s velmi přísnými požadavky (obrana, zpravodajství, utajované prostředí), kde záleží na tom, kdo může vidět nebo upravovat jakou úroveň dat.
Minimální politika je redukovaná varianta s menším počtem pravidel a kontrol. Používá se v systémech s omezenými bezpečnostními požadavky nebo tam, kde je požadován minimální dopad na kompatibilitu , čímž se obětují některé z funkcí SELinuxu v oblasti omezení.
V reálných nasazeních je obvykle vhodnější pracovat s cílenými modulárními politikami , modul po modulu upravovat, co je chráněno a jak, než se snažit spravovat jeden obrovský monolitický soubor, jehož údržba je mnohem obtížnější.
Správa kontextu: zobrazení, změna a obnovení tagů SELinux
Jedním z klíčových úkolů při správě SELinuxu je zajistit, aby soubory, adresáře, procesy a porty měly správný kontext v souladu s pravidly. Nesprávně přiřazený kontext může způsobit, že služba přestane fungovat, nebo že zdroj bude příliš exponovaný.
Pro kontrolu kontextu souborů a adresářů v SELinuxu mnoho standardních příkazů akceptuje volbu -Z. Například s ls -Z /ruta můžete vidět uživatel, role, typ a úroveň každé položky, as ps Zaux Získáte kontext aktivních procesů.
Když je nainstalována politika a souborový systém je označen (například pomocí setfiles o fixfiles se soubory file_contexts), každá trasa obdrží výchozí typ dle zásadPokud vytvoříte nový soubor v již označeném adresáři, zdědí typ adresáře, ale pokud jej přesunete z jiného umístění, zachová si původní označení, což může způsobit nekonzistence.
Pokud má strom souborů nebo adresářů nesprávné popisky, můžete je opravit pomocí restoreconŽe obnovuje kontexty na hodnoty definované v zásadách. S možnostmi jako -R (rekurzivní) a -v (podrobný) Je snadné vidět, co se mění. Je to téměř povinný krok před přechodem z permisivního do vynucovacího režimu na systémech, které jsou již nějakou dobu v testování.
Pro deklaraci nových vzorů popisování se používá semanage fcontextS tímto nástrojem si do zásad zapíšete, co Typ SELinux musí být přiřazen ke konkrétním cestám nebo regulárním výrazům.a poté tyto změny aplikujete na souborový systém pomocí restoreconNapříklad můžete označit nový DocumentRoot z Apache s httpd_sys_content_t aby jej webový server mohl číst pod svou omezenou doménou.
Základní konfigurace: povolení SELinuxu a výběr režimu
Chování SELinuxu na globální úrovni je řízeno z /etc/selinux/config, kde je definován mód (enforcing, permissive o disabled) a použitá politika (cílená, mls, minimální…).
V systémech jako RHEL nebo Fedora cílená politika obvykle přichází povoleno ve výchozím nastavení a v režimu vynuceníV SUSE nebo openSUSE je nutné upravit parametry jádra v GRUB2 tak, aby se načítal SELinux místo AppArmoru. To zahrnuje přidání možností, jako například security=selinux y selinux=1 do bootovacího řádku a regenerovat konfiguraci GRUBu.
Po povolení SELinuxu při spuštění a výběru zásad je důležité provést počáteční kompletní označení souborového systému pomocí setfiles nebo ekvivalentní nástroje. Tento krok Může to chvíli trvat a je nejlepší to udělat v období nízké poptávky.Ale je to základ pro to, aby systém bez překvapení startoval v režimu vynucení.
V prostředích, kde migrujete z AppArmoru, je zásadní velmi pečlivě zkontrolujte soubory file_contexts a jejich lokální variantyprotože jakákoli závažná nesrovnalost může zabránit spuštění systému. Předem si vytvořte zálohu a pracujte s ní. semanage fcontext Sladění politiky s realitou systému je téměř povinné.
SELinux a CVE: jak pomáhají zmírňovat zranitelnosti
Dodavatelé jako Red Hat zahrnují SELinux jako faktor ve svém hodnocení dopadu CVE . Jejich model závažnosti (kritická, důležitá, střední, nízká) zohledňuje, zda lze zranitelnost zmírnit nebo alespoň omezit dobře nakonfigurovanými omezeními SELinuxu.
V kritické zranitelnosti umožňující vzdálené spuštění kódu zadejte Log4Shell (CVE-2021-44228)Útočník by mohl vložit kód do služby přístupné z internetu. Pokud tato služba běží pod vysoce omezenou doménou SELinux, je potenciál poškození snížen, protože nebude mít oprávnění ke čtení /etc/shadowmanipulovat s citlivými databázemi nebo se v systému pohybovat mimo rámec toho, co je nezbytně nutné pro jeho funkci.
U zranitelností s eskalací oprávnění, jako je CVE-2023-4911 (Looney Tunables) , i když se exploitu podaří udělit uživateli přístup s vyššími oprávněními na úrovni DAC, může politika stále bránit klíčovým akcím, jako je načítání modulů jádra, zápis do systémových adresářů nebo otevírání určitých síťových socketů . Výsledkem je omezení toho, co lze s nově získaným přístupem dělat.
V případech středně závažných zranitelností (například určité problémy v Grafaně), které vyžadují neobvyklé konfigurace nebo je obtížné zneužít, funguje SELinux jako dodatečná bariéra, která zabraňuje tomu, aby se drobná chyba rozrostla do vážného incidentu. Tato politika často přímo blokuje přístup, který by zneužití potřebovalo k ohrožení systému.
U zranitelností s nízkým dopadem, jako jsou chyby způsobující pády uživatelských aplikací (například v editorech jako vim) , SELinux obvykle není rozhodující v prevenci samotného problému, ale stále si zachovává svou roli ochrany a zajišťuje, aby chybný proces neopustil svůj koncepční sandbox.
SELinux v akci: reálný příklad omezení webového serveru
Představte si webový server s RHEL nebo Fedorou, který zpřístupňuje několik aplikací a přestože je chráněn záplatami, je zranitelný vůči zneužití vzdáleného spuštění v jedné ze svých komponent. Bez SELinuxu by útočník spouštějící kód jako uživatel webového serveru mohl instalovat zadní vrátka, číst přihlašovací údaje nebo se přepnout na jiné systémy.
S SELinuxem v režimu vynucení a dobře vyladěnou cílenou politikou běží Apache, Nginx nebo podobné procesy pod doménou. httpd_t, který má oprávnění omezená na soubory označené typy jako například httpd_sys_content_t o httpd_sys_rw_content_ta řízený přístup k definovaným portům také s příslušným kontextem.
To znamená, že ačkoliv exploit umožňuje provádění příkazů, napadený proces Nemůže číst soubory jako /etc/shadow ani se nedotýkat adresářů databáze označené konkrétními typy (například mysqld_db_t), ani otevírat libovolná připojení k jiným interním službám, pokud to síťová politika omezuje.
Místo úplného narušení systému je narušení omezeno na hranice webové domény . Ano, stále se bude jednat o incident k vyšetřování, ale potenciální dopad je mnohem nižší a útočník má mnohem obtížnější operace.
Booleovské hodnoty, moduly a nástroje pro úpravu zásad
Kromě správného označování se každodenní práce se SELinuxem obvykle točí kolem drobných úprav základní politiky, aniž by bylo nutné ji kompletně přepisovat . Zde přicházejí na řadu booleovské hodnoty a vlastní moduly.
L booleovské hodnoty SELinux Jedná se o přepínače, které mění části chování již zkompilované zásady. Například boolean může povolit nebo zakázat FTP serveru zápis do určitých adresářů (v případě allow_ftpd_anon_write), nebo že webový server iniciuje odchozí připojení k síti.
s getsebool -a o semanage boolean -l Tyto přepínače si můžete zobrazit v seznamu a zobrazit jejich popisy. Chcete-li je trvale změnit, použijte setsebool -P nombre_booleano on|offkde je možnost -P zajistí, že změna bude uložena na disk a přežije restartování.Je to velmi pohodlný způsob, jak přizpůsobit „oficiální“ zásady specifickým potřebám vašeho serveru.
Na druhou stranu použití moduly politik Umožňuje vám rozšířit nebo upravit pravidla, aniž byste se museli dotknout základní zásady. Aktivní moduly si můžete prohlédnout pomocí semodule -lzakázat jeden pomocí semodule -d nombre nebo jej znovu aktivujte pomocí semodule -e nombreV SUSE/openSUSE je to obzvláště užitečné pro doladění, na které části systému se má SELinux zaměřit, zatímco stabilizujete své nasazení.
Pokud potřebujete udělit velmi specifická dodatečná oprávnění, kombinace audit2allow y semodule To výrazně usnadňuje život. Na základě záznamů z /var/log/audit/audit.log, audit2allow vám ukáže, které pravidlo bylo blokováno, a vygeneruje modul který, pokud si ho nainstalujete, umožňuje přesně to, co bylo dříve zakázáno.
Protokolování, auditování a řešení problémů se SELinuxem
Pokaždé, když SELinux zabrání akci, kterou politika nepovoluje, Zamítnutí AVC (odmítnutí mezipaměti Access Vector Cache), které je obvykle zaznamenáno v /var/log/audit/audit.logza předpokladu, že služba auditd je funkční.
Tyto záznamy obsahují mnoho informací: co se pokoušelo udělat (avc: denied { append }, write, getattratd.), který proces o to požádal (pid, comm=), o kterém souboru nebo zdroji (name=, dev=, ino=), jaký kontext měl původní proces (scontext) a v jakém kontextu cíl (tcontext)Zpočátku se zdají být jako záhadné hlášky, ale s trochou cviku jsou ryzím zlatem pro pochopení toho, co se děje.
Abyste se vyhnuli zdlouhavému ručnímu čtení protokolů, použijte nástroje jako ausearch umožnit filtrování podle typu zprávy (například -m AVC) nebo dočasným oknem (-ts recent). A především, audit2allow a utility, jako například sealert pomoci přeložit tyto události do téměř lidského jazyka a zobrazit návrhy.
Typický pracovní postup pro řešení problémů by byl použití audit2allow -w -a Chcete-li zobrazit vysvětlení k nejnovějším oznámením, audit2allow -a o -i fichero prozkoumat konkrétní pravidla a nakonec rozhodnout, zda má smysl vytvořit modul, který toto oprávnění odemkne Nebo pokud je naopak blok v bezpečí a je nejlepší se ho nedotýkat.
Kdykoli jsou moduly generovány pomocí audit2allow -M nombre a jsou instalovány s semodule -iStojí za to si tato nastavení prohlédnout, protože nástroj bývá štědrý a mohl by udělit více přístupu, než je nezbytně nutné. SELinux nabízí velkou flexibilitu pro posílení přístupu, ale neopatrné používání může vést k vytvoření mezer v samotných zásadách.
SELinux v rámci strategie posílení Linuxu
SELinux neexistuje ve vakuu: je integrován do širší strategie zabezpečení, která zahrnuje uživatele s omezenými oprávněními, firewally, zabezpečení SSH, mechanismy proti hrubé síle a automatizaci konfigurace.
Velmi častým postupem po instalaci serveru je vytvoření uživatele s omezenými oprávněními sudo , aby nikdy nefungoval jako přímý root, aktivace síťového firewallu (například ufw nebo iptables/nftables) , instalace nástrojů jako Fail2ban pro blokování opakovaných pokusů o přístup a konfigurace SSH s osvědčenými postupy (nestandardní port, zakázání přístupu root, ověřování klíčem, limity pokusů, robustní šifrování atd.).
Na tomto základě SELinux přidává vrstvu MAC: i když útočník získá přístup k uživateli s nesprávně nakonfigurovanými oprávněními sudo nebo heslem SSH, politika může stále omezit, ke kterým procesům a souborům má daný uživatel přístup . Není to sice spolehlivé, ale odstraňuje mnoho zranitelností, které obvykle zneužívají automatizované útoky popsané v matricích, jako je MITRE ATT&CK.
S rostoucím počtem serverů se ruční aplikace všech těchto opatření pro posílení zabezpečení stává nepraktickou. Zde přicházejí na řadu nástroje pro automatizaci a orchestraci (Ansible, Puppet, Chef, komerční automatizovaná řešení pro posílení zabezpečení atd.), které umožňují nasazení konzistentních politik SELinuxu, úpravu booleovských hodnot, označování cest a údržbu požadovaných stavů bez nutnosti trávit hodiny práce na každém počítači.
V organizacích se stovkami uzlů může být tato automatizace rozdílem mezi relativně homogenním a bezpečným prostředím a džunglí nekonzistentních konfigurací, kde je SELinux na polovině serverů vypnutý, „aby nikoho neobtěžoval“.
Když je SELinux dobře implementován – s vynucovacím režimem, konzistentními kontexty, revidovanými politikami, vyladěnými moduly a monitorovanými protokoly – stává se z něj jakási bezpečnostní síť, která drží podivné chování na uzdě, omezuje vniknutí a pomáhá demonstrovat, že se pro audity, předpisy a osvědčené bezpečnostní postupy uplatňují robustní kontroly přístupu .
