Portál AbcLinuxu, 20. května 2024 05:22
Máme-li nainstalovaný aspoň základní systém s běžícím SELinuxem (viz minulý díl), můžeme začít zkoumat principy, na kterých tento systém stojí. V dnešním díle si povíme hlavně o principu TE, který je pro SELinux stěžejní.
Minulý díl jsme zakončili krátkým průzkumem instalované politiky. Zjistili jsme, že příkazem ps xaZ lze vypsat bezpečnostní kontext, ve kterém běží procesy. Pod pojmem „bezpečnostní kontext“ si můžeme představit nějakou nálepku, která říká systému, co je daný objekt (soubor, proces, …) zač. V klasickém UNIXu tuto úlohu přebírají UID a GID, v případě procesu se ještě rozlišuje EUID, FSUID, atd. U SELinuxu se tento kontext rozšiřuje o další pole a typicky se zapisuje ve formátu user:role:type:sensitivity:category. Jelikož jsou jednotlivé části kontextu z pohledu uživatele pouze řetězce, používá se pro lepší orientaci něco jako maďarská notace, tj. píšeme mujuser_u, mojerole_r, mujtyp_t. Pro pole sensitivity a category se používají pouze čísla, např. s3, nebo c42.
Proč je v bezpečnostním kontextu tolik polí? Protože v SELinuxu tvoří bezpečnost dohromady několik principů: „Type enforcement“ (TE) pracuje s polem type a stará se o to, který proces smí dělat nějakou činnost, „role based access control“ (RBAC) pracuje s user a role a řeší, kdo (míněno uživatel člověk) smí co dělat, a konečně „multi level/category secutity“ (MLS/MCS) pracuje se sensitivity a category a určuje, jakým způsobem smí proudit v systému data. Při tom všem samozřejmě stále funguje původní UNIXová bezpečnost.
Pod pojmem „bezpečnostní politka“ si představme sadu pravidel, která říkají, co je povoleno, a co ne. V klasickém UNIXu jsou částí politiky například práva k souborům; třeba výpis z klasického ls -l říká:
-rw-r--r-- pht users 2.html
…neboli „proces s FSUID=pht smí číst a zapisovat, proces s FSGID=users smí číst, a každý jiný proces smí číst“. Tato pravidla se dále trochu komplikují pravidly k nadřazenému adresáři a faktem, že root smí všechno, ale v podstatě je toto celá politika, co se týče tohoto souboru. Všimněme si, že nelze specifikovat, který proces s danými FSUID, FSGID může k souboru přistupovat.
SELinux tento princip rozšiřuje několika směry. V pravidlech se samozřejmě vyskytují SELinuxové bezpečnostní kontexty. Dále je možno specifikovat mnohem podrobnější práva, než jen „číst“ a „psát“. Nejdůležitější ale je, že pravidlo vždy specifikuje zdrojový a cílový kontext. Například u souboru se soukromým PGP klíčem lze definovat, že jej může otevřít pouze proces gpg, který má typovou část bezpečnostního kontextu gpg_t, ale už ne firefox, který běží s typem firefox_t, ačkoliv oba procesy běží se stejným FSUID. Tím lze účinně zabránit javascript/flash/… exploitům, aby se hrabaly v soukromých datech. Podobně lze omezit přístup pomocí kategorie souboru nebo úrovně citlivosti v MLS systému.
Nejprve se budeme zabývat mechanismem TE, jelikož kolem něj se soustřeďuje většina pravidel i problémů. Budeme tedy zatím z celého kontextu potřebovat pouze typ. Typem objektu říkáme systému „tento proces plní funkci démona cron“ nebo „tento soubor obsahuje hesla uživatelů (shadow)“. Někdy se také typu u běžícího procesu říká doména, což je odborný název pro české slovo chlívek. Důvod je jasný: Proces běží ve svém chlívku.
Podíváme-li se na soubor /etc/shadow na SELinuxovém
systému, uvidíme něco jako:
# ls -lZ /etc/shadow -rw-r----- 1 root shadow system_u:object_r:shadow_t:s0 739 2009-07-24 10:03 /etc/shadow
Soubor shadow má tedy kromě obvyklých UID a GID navíc typ shadow_t. Pokud bychom se chtěli podívat, jak současná politika zachází s tímto typem, budeme potřebovat balíček setools a programy sesearch nebo apol.
Pomocí programu sesearch vyhledáme všechna pravidla, která povolují (--allow) někomu něco dělat s cílovým typem shadow_t (-t shadow_t):
sesearch --allow -t shadow_t
Výsledek závisí samozřejmě na konkrétní instalaci systému. Na mém serveru je výstupem 46 pravidel. Například
allow passwd_t shadow_t : file { ioctl read write create getattr setattr
lock relabelfrom relabelto append unlink link rename open } ;
určuje, že proces s typem passwd_t (což je obvykle instance programu /usr/bin/passwd) smí provádět nad soubory (file) typu shadow_t (což je náš /etc/shadow) zmíněné operace. Vidíme, že proces smí mj. zapisovat, ale to je vzhledem k jeho funkci nezbytné. Na druhou stranu takový program chkpwd má práva podstatně užší:
allow user_chkpwd_t shadow_t : file { read getattr } ;
Některé verze programu sesearch neumí pracovat s takzvanými atributy, což jsou v principu zástupné symboly pro určitou množinu typů. Ve výpisu pak tedy můžeme vidět něco jako @ttr0164. Expanzi těchto skupin umí provádět program apol. Je to sice GUI program, ale v některých ohledech je chytřejší než sesearch.
Do programu apol je nejprve nutné nahrát politiku příkazem File → Open, kde zaškrtneme modular (detaily jindy), a do base filename vyplníme /etc/selinux/default/modules/active/base.pp. Část default (jméno politiky) se může na různých systémech lišit. Dále pokračujeme do záložky Policy rules a TE rules, kde si naklikáme požadovaný filtr a dáme New Search (viz obrázek).
Pokud se podíváme na výpis pravidel detailněji, uvidíme, že některá zdánlivě nedávají smysl, např.
allow mount_t file_type : filesystem mount
znamená, že pokud existuje někde nějaký adresář s kontextem shadow_t, je možno do něj pomocí programu mount připojit souborový systém. Toto je jeden z projevů „targeted“ politiky, kterou ještě zmíníme podrobněji, kde je hlavním cílem omezit nebezpečné akce, na rozdíl od snahy definovat co nejmenší množinu práv. Všimněme si totiž, že tentýž mount nemá možnost z /etc/shadow číst.
Mohlo by se také zdát, že 46 pravidel kvůli jednomu souboru je docela hodně. Je to ale jeden z nejdůležitějších souborů a navíc 46 interakcí pro celý systém, ve kterém jsou stovky programů, není zas tak mnoho.
Dnešní článek uzavřeme praktickým prověřením teorie z minulého dílu, že proces getty, který má v klasickém UNIXu neomezená práva, jelikož se spouští pod rootem, nemůže napáchat v SELinuxu nějakou větší škodu, například přepsat /etc/passwd. Nejprve zjistíme, že typ souboru passwd je etc_t, pak se podíváme na
sesearch --allow -s getty_t -t etc_t
abychom se ujistili, že opravdu tato interakce mezi těmito dvěma typy není povolena. Dále napíšeme „zákeřné getty“, které se pokusíme propašovat do systému a spustit ho pomocí initu tak, jak se spouští normální getty.
# cat >getty.c
#include <stdio.h>
#include <string.h>
#include <unistd.h>
const char my_line[] =
"hacker:$1$fOgX0B7X$EX0sidhlIcxTcqzvxGZqa0:0:0::/:/bin/sh\n";
int main()
{
FILE *f = fopen("/etc/passwd", "a");
if (f) {
fwrite(my_line, sizeof(*my_line), strlen(my_line), f);
fclose(f);
}
while (1) {
pause();
}
return 0;
}
^D
# gcc -O2 -Wall -o /sbin/evil_getty getty.c
(Co se skrývá pod hashem nechám na zvědavosti a výpočetní síle čtenářů.)
Nyní nastavíme na našem programu správný kontext. Pomocí ls -lZ zjistíme, že /sbin/getty má typ getty_exec_t a pak použijeme chcon:
# chcon -t getty_exec_t /sbin/evil_getty
A nakonec nainstalujeme program do inittabu:
# echo 'ev:2345:respawn:/sbin/evil_getty' >> /etc/inittab # kill -1 1
…a vidíme, že se s passwd nic nestalo a v logu přibyla hláška
type=1400 audit(1249904379.731:40): avc: denied { append } for
pid=9701 comm="evil_getty" name="passwd" dev=sda2 ino=449902
scontext=system_u:system_r:getty_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file
(Pokud systém neběží v enforcing režimu, tak kromě hlášky přibude
i ten řádek v passwd.)
Takže, až na nás zase někdo vyběhne s otázkou, zda je SELinux k něčemu dobrý, můžeme mu ukázat naše zákeřné getty a poprosit ho, zda by si ho nezavedl do inittabu na svém ne-SELinuxovém systému!
V dalším díle uzavřeme výklad principů TE a RBAC, čímž si vydláždíme cestu k bližšímu zkoumání principů politiky, která je distribuována v balíčcích (tzv. referenční politika).
Článek vznikl za podpory ČVUT FEL, Katedra kybernetiky, kde jsou k dispozici, mimo jiné, studijní programy Otevřená informatika a Kybernetika a robotika.
Zaujímalo by ma ako táto bezpečnostná politika žerie strojový čas, napr. si skúšal porovnávať vylistovanie adresára, presun, vymazávanie súborov, zápis, čítanie so suborov a tiež ako je to s bugmi, lebo pri takto sofistikovanej kontrole môže nastať nespočetne veľa chýb, aby to s bezpečnosťou neskončilo horšie ako pri klasickom unixom systéme.
Co se týče bezpečnosti, každý kód může s sebou přinést další chyby, ale za ty roky co je SELinux v mainstream jádře, bude určitě ten kód dost dobře odladěn.Jj, například byla dobře odladěná ta chyba, kdy SELinux zrušil mmap_min_addr, takže umožnil exploit chyby s NULL ukazatelem Btw. - unreal režim?
Já si vždycky vzpomenu na poučku ze školy, že bezpečnost není stav, ale proces 
Co se týče výkonu, tak mám pocit, že SELinux dělá poměrně chytré cachování. Kdysi jsem dělal srovnání 32bit/64bit, PAE/nePAE a i SELinux/NeSELinux. Bohužel hlavní důraz byl na výpočetní výkon a ne souboroové operace, ale i těch tam pár bylo a vliv SELinuxu byl naprosto zanedbatelný až splývající s chybou měření.
Jasně, je chyba v jádře, ale proti té Vám nepomůže SELinux ani nic jiného.No pozor, ta chyba sice byla v jádře, ale přímo v SELinuxu (taky). SELinux tam něco povoloval, přestože bezpečnostní moduly mají jenom omezovat.
Ta chyba tam byla nezávisle na SELinuxu...
ale za ty roky co je SELinux v mainstream jádře, bude určitě ten kód dost dobře odladěn.Že tohle není tak úplně pravda.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.