Jak na SELinux: zpřísnění přístupů ke zdrojům

Podíváme se na:

• constraints
• MLS
• MCS

Constraints (omezení)

Constraints pravidla se mohou rozhodovat podle všech částí kontextů:

honza → root
user_r → user_r

user_t → user_t

Constraints jsou dodatečné zpřísnění TE a RBAC přístupových pravidel, implementované pomocí neverallow pravidel. V podstatě se jedná o jednoduché if-then-else konstrukce, kde se na základě dvojice (brány jako source a target stejně jako v TE) identit, rolí nebo typů (převážně jejich atributů) rozhoduje, má-li být oprávnění provádět danou akci skutečně uděleno. Identity jsou reprezentovány jako u1 a u2, role jako r1 a r2 a typy jako t1 a t2.

u1:r1:t1 a u2:r2:t2 jsou kontexty, které se pomocí contstraints kontrolují.

Poznámka: Kvůli jednoznačnosti byl ponechán původní název constraints místo českého překladu omezení.

Než se povolí doméně s typem sendmail_t číst (read) soubor (file) s typem tmp_t, zkontrolují se constraints pravidla a ty povolí nebo zakáží operaci. Tato omezení mají v SELinuxu zásadní roli. Těmito pravidly zamezíme, aby se například doména snažila přejít do typu, který nepředstavuje doménu, přepnutí do libovolné identity, role nebo typu a nebo aby vytvořený soubor měl typ, který je pro proces.

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.

Zapisují se tvaru (třída i operace může být zadána makrem):

# constrain { množina_tříd } { množina_operací } ( podmínky );
 constrain process transition
    ( u1 == u2
    or (t1 == privuser and t2 == userdomain )
    or (t1 == crond_t and t2 == user_crond_domain)
    or (t1 == userhelper_t)
    or (t1 == priv_system_role and u2 == system_u ) );

Procesu je povoleno změnit doménu, pokud je splněna alespoň jedna z podmínek:

• zůstane zachována identita
• source typ má atribut privuser (atribut opravňující změnit identitu) a target typ má atribut userdomain (atribut pro uživatelské domény, např. user_t nebo staff_t)
• source typ je crond_t a target typ má atribut user_crond_domain (tento atribut mají pouze typy user_crond_t a sysadm_crond_t)
• source typ je userhelper_t
• source typ má atribut priv_system_role (atribut umožňující změnit identitu na system_u a roli na system_r) a target identita je system_u

Pokud není splněna žádná z těchto podmínek, procesu není povoleno změnit doménu.

MLS

Zde napsaná pravidla pracují s touto částí kontextu:

system_u:system_r:sshd_t­:s0-s15:c0.c255

Během vývoje Fedora Core 5 a Red Hat Enterprise Linuxu byla vyvinuta nová bezpečnostní politika, hlavně pro použití na serverech, kombinující Type Enforcement mechanismus, Bell-LaPadula model (principy no-read-up a no-write-down). Politika zachovává předchozí principy, ale přidává další komponentu bezpečnostního kontextu, a to bezpečnostní úroveň (security level) – skládající se z citlivosti (sensitivity) a kategorie (category).

Citlivost nabývá hodnot mezi s0-s15 a je hierarchicky uspořádaná s tím, že s0 (např. nezařazená data) představuje nejnižší a s15 (přísně tajná data) nejvyšší citlivost. Kategorie je v rozmezí c0-c1023 (např. chemie, fyzika, lékařství). Jedné bezpečnostní úrovni může být přiřazena jedna citlivost a žádná nebo více kategorií. Bezpečnostní úroveň přiřazená objektu je brána jako klasifikace a úroveň subjektu jako oprávnění. Hlavní myšlenkou MLS tedy je povolit či zamítnout subjektu běžícímu s nějakým oprávněním přístup k objektu s určitou klasifikací.

Rozhodování o přístupech na základě MLS je prováděno pomocí constraints pravidel. Jsou sice zachovány dvojice identit, rolí i typů, ale rozhoduje se převážně podle přibývající dvojice l1, l2 (jako low) a h1, h2 (jako high). Pokud si vezmeme například MLS část s0-s3:c0.c15, tak s0:c0.c15 je low část a s3:c0.c15 je high část oprávnění (pomlčka a tečka značí rozsah).

Constraints pravidla (v případě MLS psáno jako mlsconstrain):

mlsconstrain { dir file lnk_file chr_file blk_file sock_file \
               fifo_file } { read getattr execute }
     (( l1 dom l2 ) or
      (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
      ( t1 == mlsfileread ) or
      ( t2 == mlstrustedobject ));

mlsconstrain { file lnk_file fifo_file dir chr_file blk_file \
               sock_file } { write create setattr relabelfrom \
               append unlink link rename mounton }
     (( l1 eq l2 ) or
      (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) \
         and ( l1 domby l2 )) or
      ( t1 == mlsfilewrite ) or
      ( t2 == mlstrustedobject ));

První pravidlo povolí číst a spustit soubory, pokud je splněna alespoň jedna z podmínek:

• oprávnění subjektu je nadmnožinou objektu (to znamená: l1 > l2, například vyhovuje s1-s2:c1 a s0-s2:c1)
• typ subjektu má atribut mlsfilereadtoclr a h1 je nadmnožinou l2 (s2-s15:c5 a s5:c5)
• typ subjektu má atribut mlsfileread (subjekt s tímto atributem smí číst i soubory s vyšší citlivostí)
• typ objektu má atribut mlstrustedobject (do objektů s tímto atributem smí zapisovat všechny subjekty bez ohledu na své oprávnění)

Druhé pravidlo povolí subjektu zapisovat, vytvářet, nastavovat atributy, přeznačkovat a další operace na souborech nebo adresářích, pokud je splněna alespoň jedna z podmínek:

• low hranice oprávnění subjektu je stejná jako low hranice citlivosti objektu (s0 a s0, s1 a s1 atd.)
• typ subjektu má atribut mlsfilewritetoclr a high hranice subjektu je nadmnožinou low hranice objektu a low hranice subjektu je podmnožinou low hranice objektu (kupříkladu s2-s5:c0.c6 a s3:c3)
• typ subjektu má atribut mlsfilewrite (subjekt s tímto typem smí zapisovat do souborů s nižší citlivostí)
• typ objektu má atribut mlstrustedobject

Pro konfiguraci MLS částí použijeme nástroj semanage, pomocí kterého nadefinujeme rozsahy pro jednotlivé uživatele nebo SELinux identity a přeznačkujeme jejich domovské adresáře. Například

 [root@noutec ~]# semanage user -m -r s0-s3:c0.c25 staff_u
 [root@noutec ~]# chcon -l s0-s3:c0.c25 /home/

Změníme oprávnění pro SELinux identity staff_u na s0-s3:c0.c25. K datům, které nespadnou do tohoto rozsahu, nebudou tito uživatelé oprávněni přistupovat. Posléze mohou staff_u uživatelé libovolně přeznačkovat své soubory a rozdělit tak svá data.

MCS

Odstavec zaměřený na tuto část kontextu:

system_u:system_r:sshd_t­:s0-s15:c0.c255

MCS politika vznikla úpravou MLS politiky využívající základní kostru MLS, včetně označkování a MLS kódu v jádře, ale odstraňuje některé části z MLS. MCS v podstatě ignoruje citlivost dat, vše je označkováno s citlivostí s0. Nepoužívá Bell-LaPadula model, neřeší se tedy pronikání ukládaných dat s vyšší citlivostí do nižší citlivosti, viditelné třeba tehdy, pokud administrátor ukládal data do /tmp/.

Uživatel svým datům přiřazuje kategorii a pouze subjekty, které mají stejnou kategorii, mohou k těmto datům přistupovat. MCS politika se podobá diskrétnímu přístupu, při rozhodování o přístupu či zamítnutí přístupu k datům se nejprve kontroluje DAC a TE přístup a až poté MCS. Implicitně jsou uživatelé oprávněni přistupovat ke všem kategoriím, což administrátor může samozřejmě změnit.

Konfigurace rozsahů MCS politiky se provádí stejným způsobem jako v MLS politice, s jediným rozdílem, že je použita citlivost s0.

 mlsconstrain file { read }
    (( h1 dom h2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));

 mlsconstrain file { create relabelto }
    (( h1 dom h2 ) and ( l2 eq h2 ));

První pravidlo povoluje subjektu číst soubor, jestliže je splněna jedna z podmínek:

• oprávnění subjektu (h1) je nadmnožinou klasifikace souboru (pokud má h1 oprávnění c0, c6, c9 a klasifikace souboru je například c6, soubor může přečíst)
• target typ má atribut domain
• typ subjektu má atribut mlsfileread

Druhé pravidlo povoluje subjektu vytvořit nebo přeznačkovat soubor, pokud jsou splněny obě tyto podmínky zároveň:

• oprávnění subjektu je nadmnožinou klasifikace souboru (s0:c0.c15 a s0:c7)
• citlivost dat je zachována (tzn. s0 a s0).

Závěr

Dnes byla řeč o poslední části bezpečnostního kontextu, a to MLC/MCS. Tímto jsme dokončili způsoby, jak a podle čeho může SELinux omezovat přístupy do systému. Tedy na základě SELinux uživatele, jeho roli, typu a na úrovni oprávnění a kategoriích. Po těchto přavážně teoretických částech se přeneseme k částem spíše praktických, konfiguračním.

Použité zdroje:

Česká dokumentace pro SELinux
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