Nebojte se SELinuxu (část první)

4.8.2009 12:03 | Přečteno: 2724× |

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 zápiskem trochu pročistit. Jedná se ale o "work in progress", takže námitky jsou vítány.

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 takový 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. redhat a jeho knaci (RHEL, centos, fedora, deriváty jako mandriva 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 zde je ze všech vyjmenovaných spíše slabší. Neznamená to, že by to nefungovalo, pouze že to není tak bleeding edge jako u fedory. U jiných distribucí je to 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 Cokra.

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 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 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 napastovat do 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, jí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 zotročené getty (nebo jiný démon) se nám bude hrabat v $HOME. A ani to tak nebolelo.

       

Komentáře

[Ilfirin]

článek!

[rADOn]

+1

[xxxs]

tiez suhlasim.

[Shadow]

Seriál!

[ss]

je to skutecne parada!

[xindl]

Ty krávo v blozích začnou vycházet seriály zajímavější než v oficiálním abíčku! ))

[michich]

Dalším zdrojem informací může být SELinuxová uživatelská příručka Fedory.

[Mrkva]

Osobně používám Grsecurity, ale abych řekl, po SELinuxu pokukuju - nikdy neuškodí naučit se něco nového. Ale zajímalo by mne nějaké srovnání - pro mě největší nevýhoda grsecurity je, že není začleněné do jádra, bohužel do hloubky už nevidím. Poradí někdo?

[Nicky726]

Pokud vím tak Jirka Brunclík dělal letos na VŠE bakalářku, kde se mimo jiné zabýval srovnáním SELinuxu a dalších technologií. Zkus se podívat tam.

[Radek Hladik]

Nedá se než souhlasit, že toto by mělo vyjít jako článek.

Osobně mám s SELinuxem takový aproximační vztah, postupně k sobě aproximujeme, ale pořád to ještě není úplně ono. Dokonce se z toho vyvrbila taková moje interní poučka "když se to chová podezřele divně, vypni SELinux ".

Když jsem kdysi SELinux poprvé nainstaloval, tak nefungovalo vůbec nic a já jsem usoudil, že toto používat nepůjde, protože těch denialů bylo na každém kroku padesát. Abych řešil, kam všude potřebuje mc zapsat a kde číst... Nakonec tak zřejmě usoudili i u RedHatů a udělali targeted policy, která se zaměřuje jen na démony a jinou havěť. I tak tam zůstalo práce habaděj. I tak je to dost složité vychytat všechny vztahy, které můžou nastat a tak vzniknul systém booleanů, kterými může admin povolit, co se smí, a co ne. Takže například, když mi nechodilo FTP a chrootování, našel jsem v konferenci, že je potřeba povolit patřičný boolean (něco jako  ftp_server_může_lézt_lidem_do_houmů). Tehdy byla práce s booleany docela magic, protože nebylo moc jejich popisů atd... Dneska je situace o poznání lepší, dokonce jsou grafická klikátka, kde si jednotlivé booleany admin proleze a zakliká jak potřebuje... (drsnější admini si jejich seznam vyexporují do vimu/emacsu/pythonu/haskelu/... tam to upraví a naimportují zpátky - proti gustu žádný dišputát)

V poslední době se mi ovšem divné chování SELinux začíná stávat v divnějších případech a občas nejsem schopen řešení najít. Takže nakonec to většinou dojde k vypnutí SELinuxu (z ekonomických důvodů), což docela škoda.

[pht]

Abych se přiznal, tak moc nevím jak se to vydá jako článek, pokud se to někomu chce zařídit, tak prosím, dávám tímto práva (ale ne exkluzivní) na zveřejnění jako článek ;)

S tou historií máte trochu pravdu, ale jak jste řekl, dnes je to už mnohem dostupnější a proto o tom také píšu.

Vypínání není úplně nejlepší alternativa, lze to udělat šetrněji přes ten permisivní režim.

[Radek Hladik]

Předpokládám, že email na adresu redakce je dobrý začátek    Dále například viz www.abclinuxu.cz/clanky/novinky/pojdte-psat-pro-abclinuxu.cz .

K tomu SELinuxu. Dobře vím, že vypínání SELinuxu není dobré. Bohužel hledání, co zlobí je časově náročné a to mi v současné době nikdo nezaplati A permissive režim beru pouze jako ladící nástroj pro tento účel, takže pokud nemám (bohužel) v plánu to řešit, tak nemá význam. A bohužel problémy začínají být v poslední době značně "divné" a občas bych až řekl, že za to SELinux nemůže moct... Ale pokaždé si říkám, že se na to budu muset podívat, že je to skoro až ostuda

[pht]

Budu o tom přemýšlet. Jaká je přesně výhoda článku oproti blogu, kromě malého honoráře?

SELinux obecně nemůže za nic, co neprodukuje aspoň jednu AVC hlášku. Pokud jedete nějakou dobu bez SELinuxu tak pak musíte provést relabel. K tomu se dostanu v dalších dílech.

[progdan]

Predevsim asi to, ze se k tomu clovek snaze dostane. Ja kdyz tu hledam neco odbornejsiho tak take vetsinou prohledavam jen clanky, abych vyloucil ne tak odborne, ale fulltextove relevantni zapisky v blozich.

[Radek Hladik]

Článkem získá člověk větší slávu a informace se povznesou z běžné blogové šedi do výšin úvodní stránky, do RSS a buhvíkam ještě  Ale od lidi z redakce určitě dostanete lepší vysvětlení.

Já vím, že SELinux nemůže za nic, pokud neudělá AVC hlášku. Teď už si nevzpomenu, co přesně to zlobilo, samozřejmě, že tam různé deny byly, ale na první pohled se vůbec nevztahovaly k tomu, co zlobilo... Až něco podobného potkám příště, zkusím si to zapsat

 

[pht]

Tak to vypadá, že se toho dočkáte.

[ss]

Ja predpokladam, ze vykrik "Clanek!" neznamena abyste nekomu zverejnoval prava na svuj clanek, ani abyste ho vy sam zverejnoval jako clanek pod zastitou externi znacky, ale napriklad ja jsem s timto vykrikem souhlasil, protoze ma znamenat "Vyborny clanek", "Skvely Clanek" apod. proste takove to kdyz zakricite "Clanek!" (ve smyslu "Takhle ma vypadat clanek!" )

[trekker.dk]

Největším "antitahákem" SELinuxu je složitost bezpečnostní politiky a strach, že se systém po aktivaci SELinuxu ani nerozběhne.

Jo, to se mi stalo, když se selinux s upgradem jádra zapnul sám. selinux = 0 a mám klid.

[Radek Hladik]

To je především otázka distribuce. U RedHatu SELinux mají rádi a hodně ho tlačí. Proto při instalaci Fedory/RHELu dostane člověk tolik konfigurace, že ohromná spousta věcí funguje bez problému (někdy by mě zajímalo, kolik člověkohodin práce to je). Samozřejmě pokud se SELinux jenom zapne a není pro něj pořádná konfigurace, tak člověk dopadne, jak když si patchne kernel, že UID a GID roota je 666, a nezmění práva na souborech

[maleprase]

(někdy by mě zajímalo, kolik člověkohodin práce to je)

pro predstavu tohle je vysledek hledani v bugzille Fedory vsech chyb selinux-policy a selinux-policy-targeted na kterych se aspon neco udelalo, v lepsim pripade bylo opraveno - 2000 bugs found 8-O.

[Libor Chocholaty]

Prava na souborech netreba menit. Kernel normalne kontroluje if uid == 0 then povoleno. Po patchi holt bude kontrolovat if uid == 666... nevidim potrebu jakkoli menit prava souborum. rootovi je to stejne sumak.

[pht]

To je otázka, co je pro Vás klid.

[trekker.dk]

Stroj nastartoval a dalo se na něm dělat

Každopádně se SELinuxem ještě nějakej čas počkám. Pokud vím, o bezpečnostních modulech nedávno probíhala nějaká diskuze, ze které jsem získal dojem, že není kam chvátat.

[pht]

Zapoměl jsem dodat, že některé návody zmiňují, že při instalaci SELinuxu na XFS je potřeba zvýšit prostor pro inody při mkfs.xfs na 512 bajtů; to už dnes neplatí.

[pht]

Přesněji řečeno stačí, aby se při xfs_info oddíl objevilo attr>=2.

[tezkatlipoka]

selinux, to je jedna z veci kvuli ktere jsem si koupil knihu Mistrovstvi s REDHAT, za nemale penize, ocekavaje, ze kdyz vas v necem udelaji mistrem, aspon se zmini o SELinuxu, ale bylo tam o nem akorant nekolik radek, popisujich jak ho vypnout.

[Begleiter]

Už se těším na 2. část. Taky se přimlouvám za to, aby to vyšlo jako článek (seriál).

[-]

Jisty Jan Horak z FI MUNI mel bakalarku na tema "Česká dokumentace pro SELinux"
link ;)

[pht]

To jsem četl, bohužel musím konstatovat, že se mi ten styl úplně nelíbí. Nimrá se ve zbytečnostech a důležité věci přechází jednou větou nebo nevysvětluje vůbec.

[Good_one]

Můžu mít nesmělý dotaz, proč sis z existujících řešení vybral SELinux?

Teda za předpokladu, že se nejedná o poznávání a hraní si s touto technologií. Pak by můj dotaz neměl smysl

[pht]

Zdálo se mi, že ostatním řešením vždy nějaká část chybí. Neměl jsem moc času na experimenty a bál jsem se, že by mě to časem začalo omezovat a nasírat. Časem si je ale projdu všechny.

[pushkin]

Jenom takový dotaz ... Novell v (open)SUSE nabízí jakýsi AppArmor - to je alternativa k SELinuxu nebo jde o něco jiného? Sice (open)SUSE provozuji čtvrtým rokem, ale k experimentům s těmihle věcmi jsem se ještě nedostal...

[Good_one]

Ano. SELinux a Apparmor jsou alternativy.

[Good_one]

SELinux, Apparmor, GrSecurity comparison

[Good_one]

Redhat SELinux vs. Novell Apparmor discussion.

[pushkin]

OK, díky moc, omrknu to.

[pht]

A další jsou tomoyo a snack.

[Sinuhet]

Ramcove dobry, ale s dovolenim bych pripojil dve poznamky.

Kdyz uz jste jednou vypustil slovo kontext, tak proc o kus dal mluvite o pravu unconfined? Bud budem veci nazyvat pravymi jmeny, nebo se ze zacatku vyhneme neznamym a komplikovanym termitum, abychom nedesili novacky. Kombinovat oba pristupy mi prijde znacne matouci.

Odrazoval bych od pouzivani audit2allow tak bezstarostnym zpusobem, jakym to predvadite vy. Dnes uz jsou politiky vcelku funkcni a odladene, takze nejcastejsi pricinou problemu je, stejne jako ve vasem priklade, spatne oznackovany konfigurak ci soubor/adresar s daty, protoze prebyva na nestandardnim miste. V takovem pripade je mnohem lepsi reseni soubor preznackovat (a zanest tuto informaci do systemu, aby se pri pristim automatickem preznackovani neztratila), nez nahodne rozdavat obvykle velmi siroka prava tak, jak mi to tupe naporouci audit2allow.

[pht]

Nebojte, všechno se uvede na pravou míru až na to přijde čas. Chci aby to čtenář nejprve pochopil rámcově, a detaily pak doplním.

To "právo unconfined" je v uvozovkách a to právě proto, že je to nesprávný termín. Stejné je to s audit2allow. Není to perfektní, ale pro teď to funguje. Pointa je udělat to nejprve funkční, a až pak perfektní.

Pokud bych měl vše detailně rozpitvávat systémem "všechno souvisí se vším" tak se do toho zamotám tak, jak většina návodů - kupa teorie, ale nikdo nic nechápe. Tomu se chci vyhnout.

[xvasek]

Správně, tak do nás, sprosté masy...

[vaše jméno]

Rámcově špatný. Teda vlastně víc než to, úplně nebezpečné, lidi by si to mohli přečíst a nedej bože to brát vážně.

Výklad ve stylu "to neva, že nevíš, která páčka, několik iterací generování vlastní politiky s audit2allow je super cesta k vytvoření zabezpečeného systému" je bez nadsázky stejně dobrá rada jako pobídka "tu máš sirky, jdi si hrát do stohu".

Kdyby někdo chtěl vytvořit skutečně prakticky orientovaný úvod do selinuxu, měl by se omezit na tvrzení selinux = kontext souboru. Kdyby někdo chtěl napsat stejně praktické pokračování, držel by stále stejného zjednodušení. A kdyby někdo chtěl napsat třetí část s podtitulem "Ovládněte selinux tady a teď", nijak by se od původního zjednodušení selinuxu na výklad o kontextech souborů neodchýlil (v příkazech: ls -Z, ausearch, chcon, semanage, sesearch). Nejdřív tak po šesti letech aktivní správy systému s aktivovaným selinuxem je člověk zralý na pokročilejší kapitoly.

Tohle ale začíná "zábavnou" příhodou, kdy autor místo toho, aby se se selinuxem férově utkal, raději stáhl ocas a utekl z bojiště (viz hotplug story), pokračuje nepopsatelně otřesnou pobídkou k použití audit2allow (jak jinak, autor se pravděpodobně nikdy nepokusil skutečně vyřešit problém způsobený selinuxem) a vše je korunováno závěrečným, že snad to ani nebolelo (ale ono to bolí docela dost).

Malý námět k zamyšlení. Autor říká, že vybrané procesy mají omezený přístup narozdíl od zbytku systému, který není selinuxem omezený. Pokud použiju audit2allow, rozšířím tak práva některého procesu. Vzhledem k tomu, že "zbytek systému" už neomezený je, nebude žádné hlášky typu avc: denied, dojde k rozšíření práv některého "vybraného procesu". Nabízí se naprosto zřejmá otázka. Je potom systém plný takových rozšíření oprávnění opravdu lépe zabezpečený?

Snaha navodit dojem, že selinux není komplikovaný nástroj, zatím nikomu nevyšla, je to stejně snadné, jako snaha navodit dojem, že prase létá.

Jestli to vypadá, že si myslím, že se měl autor raději věnovat nějakému jinému tématu, pak je to proto, že si to skutečně myslím. Vážně, čerpat informace z tohoto zápisku je hodně, ale hodně nebezpečné. Sám autor se bude jistě za čas stydět za to, co dnes napsal.

[vencour]

Možná se bude stydět, ale povzbudí ostatní. Rozproudí diskusi, i Váš příspěvek by bez tohoto blogpostu asi nevznikl.

[thingie]

Furt lepší než to vypnout.

[pht]

Zase jeden anonymní chytrák? Sedněte si a napište článek po svém, pak se třeba začnu věnovat jiným tématům.

[trekker.dk]

Třetí odstavec je typický příklad důvodu, proč lidé SELinux raději vypnou, než aby se v něm vrtali. Že to je špatně přitom přiznali sami jeho vývojáři.

[pht]

A není to náhodou to samé, jako když v dřevních dobách musela každá kravina běžet s právy roota, jen proto, že lidé neuměli používat nic jiného?

[Ladicek]

Snaha navodit dojem, že selinux není komplikovaný nástroj, zatím nikomu nevyšla

Složité nástroje jsou špatné. Univerzálně, bez výjimky. Díky za potvrzení, že SELinuxem nemá smysl se zabývat

[pht]

Jen se v tom utvrzujte, koneckonců je to jednodušší než myslet a pracovat :)

[Ladicek]

Jsou tisíce lepších věcí, o kterých stojí za to přemýšlet, než hypersložité bezpečnostní řešení

[pht]

To řešení je samo o sobě jednoduché. Je to systém, který je složitý. Jen se podívejte na tu spoustu věcí které se dají nacpat na jeden server. Je jen logickým důsledkem, že popis jejich interakcí nebude na tři řádky.

Jak jsem řekl, nejdřív musíte rozumět tomu, co se děje v systému. Začněte tedy nejprv přemýšlet o tom.

[xvasek]

Hele, "vaše jméno" - kdyby autor napsal "použijte audit2allow a máte nastavený selinux", tak by to bylo určitě na pováženou. Ale on IMHO celkem pěkně vysvětlil, že "takto to prozatím obejdeme, později to zkusíme opravit" - to je trochu rozdíl.

[Sinuhet]

Kde to tam vysvetlil? Je pravda, ze nikde explicitne nenapsal, ze audit2allow je konecne reseni v nastaveni selinuxu a s jim vygenerovanymi pravidly muzu jit na produkcni server, ale presne takhle clanek vyzniva. Ze to je vlastne spatne se snad dozvime v nasledujicich dilech serialu, ale z tohodle to jasne neni.

[pht]

V článku je pouze

Pokud je těch hlášek pouze několik

což není explicitně ani jedno ani druhé. Každopádně pak můj další komentář hovoří jasně.

[pht]

Článková verze tohoto textu včetně případných pokračování:

http://www.abclinuxu.cz/clanky/bezpecnost/nebojte-se-selinuxu-1-uvod-prvni-spusteni