Řekneme si:
- proč používat SELinux
- o historii SELinuxu
- rozdíl mezi diskrétním a povinném řízení přístupu
- o politice a jádře systému
- o instalaci SELinuxu
- bezpečnostním kontextu
- identitě (SELinux uživateli)
- roli
- typu
- MLS a MCS
Proč SELinux?
Přes všechnu snahu vývojářů vyvinout bezchybný a bezpečný systém je jisté, že se jim to prozatím nepodaří. Programování je v porovnání s ostatními vědami v počátcích. Systémy jsou natolik složité, že se v nich vždy najde taková část, která umožní znalému útočníkovi do systému vniknout. Těchto pokusů příbývá každoročně asi o 85%, nezbývá tedy nic jiného, než si pomoci nějakými podpůrnými prostředky. Jedním z nich je i NSA Security-Enhanced Linux, známý spíše pod zkratkou SELinux. SELinux je implementací tzv. povinného řízení přístupu (anglicky Mandatory Access Control, neboli MAC). SELinux vynucuje administrátorem definovanou bezpečnostní politiku nad všemi subjekty a objekty v systému. Umožňuje tak nastavit jemnější práva přístupu k datům a zamezit jejich změnám, ať úmyslným, či neúmyslným.
Historie
Během devadesátých let dnes již minulého století spolupracovaly NSA (National Security Agency) s Secure Computing System na vývoji silné a flexibilní architektury s povinným řízením přístupu. Zaměřily se na teoretické základy a charakteristiku této architektury. Společně s Univerzitou v Utahu poté vytvořily prototyp nazvaný Flask. Po další spolupráci se společnostmi Network Associates a MITRE implementovaly tuto architekturu do operačních systémů Linux. Jejich práce byla uveřejněna v prosinci roku 2000 a byla poskytnuta jako open source produkt.
Několik dalších distributorů Linuxu poté projevilo zájem o podporu SELinuxu v jejich distribucích. Mezi ně patří Red Hat (v Red Hat Enterprise Linuxu) a SUSE v komerčních distribucích Linuxu. SELinux je již standardní součástí nekomerčních distribucí Debian GNU/Linux, Gentoo Linux a Fedora Core (sponzorované společností Red Hat).
Porovnání s tradičním unixovým modelem
Operační systémy používají některý z mechanismů řízení přístupu. Mezi dva nejznámější patří diskrétní (volitelné) řízení přístupu (DAC, Discretionary Access Control), které je použito v klasickém Linuxu, a povinné řízení přístupu (MAC, Mandatory Access Control), které je předmětem SELinuxu. Oba mechanismy mohou být v systému implementovány zároveň.

Chcete vědět o SELinux víc?
Chcete-li vědět víc, stáhněte si příručku nazvanou Česká dokumentace pro SELinux, kterou naleznete v naší elektronické knihovně na knihy.root.cz.
Diskrétní řízení přístupu
Princip diskrétního řízení přístupu je založen na ACL (Access Control List). Každý soubor nebo program má k sobě asociován jeden ACL, kde jsou definována jeho přístupová práva pro uživatele (vlastníka), skupinu a ostatní. Na základě ACL je tedy povolen či zamítnut přístup k objektu.
DAC neposkytuje žádnou ochranu před použitím poškozeného nebo upraveného softwaru. Každý spuštěný program nebo proces běží pod právy uživatele, který jej spustil. Proces má tedy plnou kontrolu nad všemi daty daného uživatele a má možnost je měnit a zapisovat do nich. Například program na prohlížení pošty nepotřebuje mít plný přístup ke všem datům uživatele. Takovými daty mohou být konfigurační nebo jiné citlivé soubory, přístup k nim je nežádoucí v případě běžného uživatele a katastrofou u superuživatele, který má neomezený přístup k celému systému. Pokud se útočníkovi podaří převzít kontrolu nad procesem, který běží pod právy superuživatele, naskýtá se mu tak možnost získat kontrolu nad celým systémem. Stejné nebezpečí hrozí, i pokud má program nastaven setuid nebo setgid bit na superuživatele. Především z těchto důvodů DAC neposkytuje dostatečnou bezpečnost.
Povinné řízení přístupu
MAC poskytuje plnou kontrolu nad všemi akcemi programů, které běží v tzv. sandboxu (česky pískoviště), jenž omezuje přístup do jiných částí systému, než je samotný prostor sandboxu. Ve spojitosti se SELinuxem se zavádí speciální sandboxy nazývané domény, znemožňující i programům pod právy superuživatele tuto doménu opustit. Pokud se útočníkovi podaří převzít kontrolu nad nějakým programem, může provádět pouze takové operace, které měl daný program povoleny, a to i v případě programů pod právy superuživatele. Veškeré programy takovéhoto systému se musí řídit administrátorem definovanou politikou a znemožní tak použití poškozeného nebo upraveného softwaru všem uživatelům i superuživateli.
Politika a jádro systému
Politika je množina pravidel, které jsou základem SELinuxu definující všem objektům v systému typ a procesům jejich domény, identitám určuje v jakých rolích mohou operovat a rolím stanovuje, do jakých domén mohou tyto role vstoupit a ke kterým typům mají přístup. Politika je administrátorsky definovatelná, což umožňuje pravidla nakonfigurovat přesně podle potřeb daného systému. Zdrojové kódy pravidel jsou zkompilovány do binární podoby a jsou poté zavedeny do jádra.
V dřívějších verzích distribucí Fedora Core byla celá politika zkompilována do jednoho modulu a jakákoliv změna politiky vedla ke znovukompilaci celého modulu. Ve verzi Fedora Core 5 se zavádí mechanismus zvaný LSM (Linux Security Modules), usnadňující práci při konfiguraci. Množiny pravidel jsou zkompilovány do modulů a tyto moduly se mohou za běhu systému libovolně nahrávat či odstraňovat z jádra, aniž by bylo nutné celou politiku opět kompilovat.
Instalace
Máme v podstatě tři způsoby, jak získat SELinux:
- jako integrovanou součást linuxové distribuce, kterou instalujeme na počítač,
- stáhnutím, zkompilováním a nainstalováním ze zdrojových kódů poskytovaných na stránkách NSA,
- nainstalováním ze zdrojových nebo binárních balíčků z domovských stránek dané linuxové distribuce (pro Debian GNU/Linux .deb balíčky, pro Fedora Core, SUSE Linux nebo Red Hat Enterprise Linux jsou to .rpm balíčky).
V případě, že budeme kompilovat SELinux ze zdrojových kódů, je nutné ověřit, zda naše jádro SELinux podporuje. Pokud ano, vše je v pořádku, jinak je potřeba překompilovat i samotné jádro, a to s podporou NSA SELinux Support.
Poznámka: Při psaní byla použita linuxová distribuce Fedora Core 6, která má podporu SELinuxu v základní instalaci.
Po instalaci stačí pouze aktualizovat jednotlivé součásti SELinuxu:
[honza@noutec ~]$ sudo yum update libselinux checkpolicy selinux-policy-targeted libsemanage policycoreutils
Budeme ještě potřebovat balíček selinux-policy-devel, kde jsou soubory nutné pro kompilaci vlastních pravidel, balíček selinux-policy-strict pro striktní politiku, balíček policycoreutils-newrole pro změnu rolí a případně selinux-policy-mls pro MLS politiku.
[honza@noutec ~]$ sudo yum install selinux-policy-devel selinux-policy-strict policycoreutils-newrole selinux-policy-mls
Řízení přístupu
Bezpečnost SELinuxu je založena na dvou základních mechanismech. Primárním je Type Enforcement (TE), sekundárním je Role Based Access Control (RBAC) a volitelným Multi-Level Security modelem (MLS). Pokud bude program provádět nějakou operaci, musí být povolena těmito mechanismy. Samozřejmě musí vyhovět i omezením, která jsou kladena diskrétním řízením přístupu, jako jsou běžná přístupová práva. SELinux omezuje jen operace, které při svém konání komunikují s jádrem. Co nejde přes jádro, SELinux neomezuje.
Bezpečnostní kontext (Security Context)
Kontext se většinou skládá z těchto částí:
identita:role:typ
Každý subjekt (proces) a objekt (například soubor, adresář, soket, paket) má přiřazen bezpečnostní kontext. Kontext se skládá ze tří nebo čtyř částí oddělených ‚:‘, a to identity, role, domény nebo typu a případným mls.
Kontext pro soubory lze vypsat příkazem ls --context
nebo ls -Z
pro uživatele příkazem id -Z
a pro proces příkazem ps -Z
Kontext se vypisuje ve tvaru identita:role:doména(typ):mls.
- system_u:system_r:sshd_t
identita (neboli SELinux uživatel) – se liší od identity v klasickém Linuxu, ačkoliv mohou mít stejnou textovou podobu. Je třeba cítit jejich rozdíl. Identita SELinuxu je součástí bezpečnostního kontextu. Jedna SELinux identita může být přiřazena více uživatelům, kteří mají podobná oprávnění v systému. Na základě identity se rozhoduje, do kterých rolí lze přejít. V targeted politice je tato položka (stejně jako role) v podstatě ignorována.
V rámci SELinuxu příkaz su
identitu nemění, můžeme ověřit následujícím výpisem:
[honza@noutec ~]$ id -Z # běžný uživatel user_u:system_r:unconfined_t [honza@noutec ~]$ su # změna uživatele [root@noutec ~]# id -Z # uživatel root user_u:system_r:unconfined_t
- system_u:system_r:sshd_t
role – na základě role lze blíže specifikovat přístupy k typům
- system_u:system_r:sshd_t
typ – jedná se o nejdůležitější část bezpečnostního kontextu. Na základě typů, na které se vztahují TE pravidla, se rozhodují téměř všechny přístupy
- system_u:system_r:sshd_t:s0-s15:c0.c255
mls – udává citlivost dat, pouze subjekty se stejnou citlivostí mohou k takovým objektům přistupovat (rozsah citlivosti je v rozmezí s0 až s15)
- system_u:system_r:sshd_t:s0-s15:c0.c255
mcs – udává kategorii (třídu) objektu (rozsah kategorie je v rozmezí c0 až c255)
Zkusíme, jaký kontext má například sshd démon:
[honza@noutec ~]$ ps -Z pid_sshd system_u:system_r:sshd_t:s0-s15:c0.c255
System_u je implicitní identita pro systémové procesy a zároveň udává roli system_r, která je rovněž implicitní. Sshd_t je doména procesu. Pokud otevřeme ssh
spojení, ukládají se dočasné soubory do /tmp/, to ale znamená, že musí existovat TE pravidla (přístupová pravidla), která povolí doméně (resp. typu) sshd_t číst adresář /tmp/, vytvářet v něm nové soubory, adresáře, zapisovat do nich, a další operace. MLS část s0-s15, pro proces zvaná oprávnění, povoluje přistupovat k objektům, které mají takovouto citlivost. MCS část c0.c255 jsou kategorie, ke kterým může sshd daemon přistupovat.
Kontext souboru vytvořeného v /tmp/ může být následující:
[honza@noutec ~]$ ls -Z /tmp user_u:object_r:user_tmp_t:s0:c0
User_u je identita uživatele, object_r je role, náležící souborům a user_tmp_t je typ pro soubor v /tmp/, který proces vytvořil. V souvislosti s TE pravidly to znamená, že proces opět smí pracovat s /tmp/ stejně jako sshd výše, ale navíc je tu pravidlo (přechodové pravidlo), že pokud proces vytvoří soubor v /tmp/ (typ tmp_t), tento soubor bude typu user_tmp_t. MLS část povoluje subjektům s oprávněním s0 přistupovat k těmto datům. MCS část udává kategorii souboru. Pouze subjekty, které mají ve své MCS části kategorii c0, mohou k souboru přistupovat.
Závěr
V prvním dílu seriálu jsme si pověděli něco z historie SELinuxu a ukázali jsme si, v čem jsou hlavní rozdíly oproti klasickému zabezpečení linuxových systémů. Nadále jsme se podívali, kde získat a jak aktualizovat SELinux. Vysvětlili jsme si části bezpečnostního kontextu a ukázali jsme si, co která část znamená a který přístup se podle této části rozhoduje. Nyní bychom měli být schopní při pohledu na kontext ho pochopit a vědět, co znamená. Ačkoliv se SELinux kontext skládá ze tří nebo čtyř částí, nejdůležitější pro nás bude část třetí, a tou je typ.
Použité zdroje:
MCCARTY Bill. SELinux. 1005 Gravenstein Highway North, Sebastopol, CA 95472: O'Reilly Media, Inc., 2004, 254s. ISBN 0–596–00716–7
Fedora SELinux Project Pages
Configuring the SELinux Policy
LOSCOCCO, Peter. Integrating Flexible Support for Security Policies into the Linux Operating System
Red Hat Enterprise Linux 4: Red Hat SELinux Guide
MORRIS, James. An Overview of Multilevel Security and LSPP under Linux
MORRIS, James. A Brief Introduction to Multi-Category Security (MCS)
CAPLAN, David, MACMILLAN, Karl, MAYER, Frank. SELinux Concepts
COKER, Faye. Writing SE Linux policy HOWTO
WALSH, Dan. danwalsh's Journal