Portál AbcLinuxu, 13. května 2024 14:21
Jednoho dne mi došlo, že se v oblasti bezpečnosti počítačů bez praktické znalosti SELinuxu (nebo jiného MAC) neobejdu. Kolem SELinuxu se šíří oblak strachu a nejistoty, který bych chtěl tímto článkem trochu pročistit.
Nejprve krátké shrnutí základních principů. SELinux je systém implementující bezpečnost nad rámec klasického zabezpečení UNIXu. Co je na UNIXovém přístupu špatného? Za prvé, přístupová práva jsou definována příliš široce. Jako příklad si můžeme vzít práva k souborům. V UNIXu můžeme rozlišit pouze přístup pro vlastníka, skupinu a ostatní. Nelze mít přístupy pro deset skupin pro čtení, dvě pro zápis, jednoho dalšího uživatele pro čtení a zbytek světa žádný přístup. POSIXové ACL také definují pouze práva rwx – nelze rozlišit operaci append od obecného write nebo mkdir od creat. Druhým průšvihem je možnost libovůle vlastníka nad právy (např. opět zase k souboru). Neexistuje způsob, jak by administrátor mohl znemožnit vlastníkovi souboru měnit jeho práva, neboli problém DAC versus MAC.
SELinux řeší oba problémy – jednak dovoluje administrátorovi stanovit bezpečnostní pravidla, která jsou až do změny politiky neměnná, například, že k privátním SSH klíčům uživatele má přístup pouze aplikace SSH, ale už ne Firefox, a neexistuje způsob, jak by si Firefox mohl tyto klíče „zpřístupnit“. A jednak lze pomocí politiky ošetřit obrovský počet akcí, například povolit démonovi pouze připisovat do souboru s logem, ale už ne jej přepsat, nebo povolit web serveru naslouchání na portu 80, ale už ne libovolnou jinou komunikaci. Navíc lze použít vymoženosti jako secmark, čímž spojíme možnosti iptables a SELinuxu, případně labeled ipsec, čímž můžeme rozšířit naši bezpečnostní politiku na celou síť.
Namísto zabití celého článku teorií (která není zas tak triviální) si zkusíme rovnou SELinux v praxi a teorii se doučíme cestou. Pro začátek je vhodné si vybrat distribuci Linuxu, která již nějakou podporu pro SELinux má, tj. Red Hat (RHEL, CentOS, Fedora, deriváty jako Mandriva Linux by mohly být OK, …), Gentoo a Debian (Lenny nebo Sid). Já jsem při svém snažení zvolil Debian, ačkoliv se ukazuje, že podpora je ze všech vyjmenovaných spíše slabší. Neznamená to, že by to nefungovalo, pouze to není tak na špici vývoje [bleeding edge] jako u Fedory. U jiných distribucí můžete dopadnout úplně jinak [YMMV], jelikož podstatnou část v předdefinované politice hraje umístění souborů – binárky, konfiguráky, init soubory a podobně. Samozřejmě je vhodné experimentovat na neprodukčním stroji, kde můžete vždy začít odznova.
Pro instalaci na Debianu (Lenny) je dobré rámcově postupovat podle návodu na Debian wiki a podle dodatečných informací od Rusella Cokera.
Největším „antitahákem“ SELinuxu je složitost bezpečnostní politiky a strach, že se systém po aktivaci SELinuxu ani nerozběhne. Ukážeme si, že to není tak hrozné. Jediné, co je skutečně potřeba, je znalost toho, jak systém funguje. Bohužel bez toho nelze dost dobře stanovit, co se děje správně, a co ne. První krůčky může také pomoct překonat Gentoo Linux SELinux handbook, konkrétně Dissecting a Denial.
Po instalaci balíků, autorelabel, atd. se systém rebootuje do tzv. permissive [uvolněného] režimu. V tomto režimu se sice vše kontroluje dle zadané politiky, ale přístupy nejsou zakázány, pouze logovány. To nám dává příležitost ověřit, zda politika funguje správně, aniž bychom museli křísit nepoužitelný systém. Po přihlášení spusťte příkaz dmesg a nevyhnutelně uvidíte (doufejme, že jen několik) hlášek typu avc: denied. V tuhle chvíli není úplně důležíté porozumět celé hlášce, pouze je potřeba určit, zda zamítnutí dané akce ohrozí start systému, nebo ne. V nejhorším to lze otestovat přepnutím do enforcing [vynucovacího] režimu na jeden boot a pozorováním.
Příkladně v mém případě to byl problém u hotplug skriptu pro síťovku, který neměl práva číst konfigurační soubory v /etc/network či něco takového. Asi by mělo smysl takovou akci povolit, bylo však mnohem jednodušší upravit konfigurační soubory tak, aby se síťovka inicializovala automaticky při startu počítače a ne jako hotplug (stejně tam vždy je). Jelikož init skript běží s jinými pravomocemi než hotplug skript, fungovalo vše správně. Pokud je těch hlášek pouze několik, můžete je směle předat programu audit2allow -M local. Výsledkem bude soubor local.pp, který nakopírujete do adresáře /etc/selinux/default/modules/active/modules a opakujete start systému.
Po několika iteracích dospějete do stavu, kde už žádná hláška od AVC neohrožuje start systému, a je tedy čas přikročit k aktivaci enforcing režimu natrvalo. Tím je prvotní instalace dokončena a my se můžeme kochat zabezepečením. Ve výchozí politice je toto zabezpečení poměrně jednoduché: Existují vybrané procesy, kterým přístup omezen je (nad rámec UNIXových opatření), a zbytek systému je SELinuxem témeř neomezen, tj. platí pouze klasická UNIXová pravidla.
Pomocí příkazu ps xaZ (zapamatujte si to Z) se můžeme podívat, jak to vypadá. Pravděpodobně uvidíte, že například procesy typu getty, sshd, crond beží ve vlastním kontextu (getty_t, apod.), tj. mají omezená práva, i když běží pod rootem. Příkladně takové getty nemůže otevírat internetové spojení nebo se hrabat v domovských adresářích. Na druhou stranu shell uživatele bude mít u sebe něco jako unconfined_t, což znamená, že omezení je minimální. Navíc také vše, co z tohoto shellu spustíte, bude mít „právo unconfined“. V první fázi jsme tedy dospěli do stavu, kde vše funguje jako dříve, ale nemusíme se bát, že se nám zotročené getty (nebo jiný démon) bude hrabat v $HOME. A ani to tak nebolelo.
Další díl se bude hlouběji zabývat filosofií SELinuxové politiky (jak pravidla fungují, proč jsou zrovna takto a kde sehnat další informace).
Článek vznikl za podpory ČVUT FEL, Katedra kybernetiky, kde jsou k dispozici, mimo jiné, studijní programy Otevřená informatika a Kybernetika a robotika.
Poznámka: Článek původně vyšel v blogu pht.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.