Jak na SELinux: konfigurace a makra

Povíme si o:

• adresáři /selinux/
• adresáři /usr/share/selinux
• makrech m4
• kompilaci pravidel a zavedení do jádra
• přeznačkování souborů
• nastavení ve Fedoře

/selinux/

Zde je nejdůležitějším adresářem booleans, kde jsou konfigurační soubory zabezpečených prvků systému. Booleans je mechanismus, jak za běhu zapnout/vypnout nějakou službu, aniž by musela být politika jakkoliv upravována.

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.

Například httpd_enable_cgi je implicitně nastaven jako pravda (1, on). Tímto umožníme uživateli spouštějícímu cgi skript přejít do nové domény, získat správný kontext a další oprávnění. Pokud bychom chtěli spouštění cgi skriptů zakázat, nastavili bychom httpd_enable_cgi na nepravda (0, off), a to bez nutnosti měnit politiku nebo restartovat počítač. Každý z těchto souborů by měl obsahovat právě dvě nuly nebo jedničky. První hodnota určuje momentální stav, druhá hodnota je čekající, změna na tuto hodnotu se provede až po potvrzení. Jsou dva způsoby, jak booleans nastavovat: pomocí setsebool nebo ručně. Příkazem

[root@noutec ~]# setsebool httpd_enable_cgi 1

změníme obě čísla na 1, tudíž nastavení se ihned provede.

Ruční konfigurace se provádí unixovým příkazem echo, pro lepší představu berme za to, že soubor obsahuje dvě nuly.

[root@noutec ~]# echo 1 > /selinux/booleans/httpd_enable_cgi

Změní obsah httpd_enable_cgi na hodnoty 0 1, to znamená, že tato boolean je stále vypnutá, čeká na potvrzení. Pokud takto nastavíme několik různých booleans, jednotně provedeme jejich aktivaci opět pomocí echo

[root@noutec ~]# echo 1 > /selinux/commit_pending_bools

Abychom přesně věděli, co boolean povoluje, můžeme se podívat do zdrojových souborů, konkrétně .if souborů části systému, která nás zajímá (zde apache.if), kde hledáme část, která začíná

tunable_policy(`jméno_boolean',`
     # zde jsou pravidla
 ')

/usr/share/selinux/

Zde jsou v adresářích strict, targeted a mls uloženy všechny dostupné základní moduly (*.pp) pro jednotlivé politiky. Adresář devel obsahuje soubory potřebné pro kompilaci vlastních pravidel. V devel je i demonstrační příklad (example.[te, fc, if]), jak by mohla vypadat pravidla. Pro konfiguraci vlastních pravidel bude nejlepší použít tento adresář (devel), ve kterém si můžeme vytvořit adresář local pro identifikaci, že se jedná o lokální úpravy, a v něm vytvořit podadresáře pojmenované podle částí systému, které právě konfigurujeme. V devel najdeme i samotný Makefile, který nabízí následující operace:

• load – zkompiluje, vytvoří a nahraje do jádra novou politiku
• reload – zkompiluje, vytvoří novou politiku a pokud byla politika změněna, zavede ji do jádra
• clean – smaže pomocný tmp adresář a .pp moduly
• bez parametru – zkompiluje zdrojové soubory v aktuálním adresáři

Při psaní pravidel budeme používat celkem tři soubory s příponami .fc, .if a .te.

V souboru .fc s následujícím obsahem se udává, jak mají být označkovány soubory s novým kontextem:

cesta  [prepinac]  gen_context(novy_kontext, level)

Cesta může být zadána absolutně (soubor) nebo formou regulárního výrazu (adresář). Pokud přepínač vynecháme, budou označkovány všechny soubory a adresáře, s přepínačem – se označkují pouze soubory. S přepínačem -d se označkují pouze adresáře (soubory v takovém adresáři si ponechají svůj kontext, ale nově vytvořené soubory zdědí kontext podle nadřazeného adresáře).

Do souboru .if si můžeme nadefinovat vlastní makra. Makra jsou napsána pomocí makro procesoru m4 a slouží ke zpřehlednění pravidel. Nadefinujeme například makro, které umožnuje aplikaci, kterou konfigurujeme, číst logy. Spousta m4 maker je již přednastavena, přehled některých najdeme v adresáři /usr/share/se­linux/devel/in­clude/ v .spt souborech, několik zajímavých maker je v poslední části naší série.

Například přednastavená makra vypadájí:

 # makro all_file_perms
 define(`all_file_perms',`{ ioctl read write create
 getattr setattr lock relabelfrom relabelto append
 unlink link rename execute swapon quotaon mounton
 execute_no_trans entrypoint execmod }')

 # pravidlo
 allow typ1 typ2: file all_file_perms;

Abychom nemuseli vypisovat v pravidle všechna výše vypsaná oprávnění, použijeme makro all_file_perms, které se při překladu nahradí požadovaným (tzn. všechny operace, které lze se soubory provádět). Makra lze i zanořovat a definovat je pomocí jiných maker. Použití .if souboru není povinné a záleží na administrátorovi, jestli do něj vlastní makra nadefinuje. Ta se definují pomocí direktivy interface

 # interface(`název_makra',`
 interface(`povol_spustit',`
      gen_require(`
          # zde nadefinujeme typy použité v makru
          type bin_t;
      ')
      # zde píšeme pravidla

      allow $1 bin_t: file { read getattr execute };
 ')

Až zavoláme naše makro povol_spustit(u­ser_t), všechny výskyty $1 se v makru nahradí typem user_t. Počet částí začínající $ udává počet parametrů, které makro očekává. Při konfiguraci si v podstatě vystačíme pouze se soubory .fc a .te.

Do souboru .te budeme psát samotná TE pravidla SELinuxu. Zde můžeme při psaní pravidel použít přednastavená makra a naše makra v .if souboru. Obsah souboru by měl vypadat následovně:

 policy_module(jmeno,verze); # nebo module jmeno verze;

 require{
 # tuto sekci lze přirovnat k deklaraci proměnných
 # definují se zde použité třídy objektů, atributy a \
   typy, které už jsou v systému známy

 # atribut pro proces
 atrribute domain;

 # typ jmeno;
 type bin_t, user_t;

 # class třída { množina_operací_dané_třídy };
 class file { read getattr execute };
 };

 # deklarace našich nových typů
 # typ, který bude přiřazen procesu
 type můj_typ_t, domain;

 # naše pravidla
 # povol doméně s typem můj_typ_t spustit nebo číst \
   soubory s typem bin_t (soubory v /bin/)
 allow můj_typ_t bin_t: file { read getattr execute };

 # makro(parametry)
 # po spuštění souboru s typem bin_t povol přechod \
   z domény user_t do domény můj_typ_t
 domain_auto_trans(user_t, bin_t, můj_typ_t)

Seznam několika maker.

Další makra je možné najít v dokumentaci.

Kompilace pravidel a zavedení do jádra

Kompilaci pravidel a zavedení politiky do jádra si můžeme vyzkoušet na výše zmiňovaném demonstračním příkladu example.[te, fc, if]. Výsledkem bude modul example.pp.

Abychom se vyhnuli nějakým potížím při psaní a kompilaci pravidel, shrneme si náš postup:

• Zkontrolujeme, jestli máme nainstalovaný balíček selinux-policy-devel (obsahuje nástroje nutné ke kompilaci), případně ho doninstalujeme.

  [root@noutec ~]# rpm -q selinux-policy-devel
  selinux-policy-devel-verze

• Vytvoříme si adresář v /usr/share/se­linux/devel/ (například podle jména aplikace, pro kterou píšeme pravidla) a v něm vytvoříme soubor s příponou .te.
• Do souboru .te napíšeme svá pravidla. Nesmíme zapomenout na sekci require { }, do které zapíšeme všechny použité typy, jinak by kompilace pravidel skončila chybou.
• Přeložíme naše pravidla pomocí makefilu z balíčku selinux-policy-devel uloženého v /usr/share/se­linux/devel/. Makefile implicitně překládá soubory s pravidly v tomto adresáři, proto budeme pravidla překládat takto (z adresáře, ve kterém máme soubory s pravidly):

  [root@noutec ~]# make -f /usr/share/selinux/devel/Makefile

• Pravidla se zkompilují, ale nezavedou se do jádra. Ruční zavedení (i odstranění, výpis modulů v jádře a další) politiky (.pp) do jádra se provádí příkazem semodule.

  Zavedení modulu náš_modul.pp do jádra:

  [root@noutec ~]# semodule -i náš_modul.pp

  Nyní se můžeme podívat, že kontext z našeho souboru .fc se opravdu objevil v souboru /etc/selinux/tar­geted/contexts/fi­les/file_contex­ts, o kterém jsme si řekli, že se podle něj značkují soubory.

  Odstranění modulu náš_modul z jádra:

  [root@noutec ~]# semodule -r náš_modul

  Výpis všech modulů zavedených v jádře:

  [root@noutec ~]# semodule -l

Jestliže zavedeme modul do jádra, bude při každém startu systému automaticky nahráván.

Přeznačkování souborů

Jestliže vytvoříme nový kontext pro soubory nebo adresáře v domovských adresářích, aktualizuje se kontextový soubor homedir_template, ale změna se prozatím neprojevila v souboru file_contexts­.homedirs, podle kterého se už soubory nebo adresáře značkují. Aktualizaci provedeme příkazem genhomedircon. Následně lze již přeznačkovat domovské adresáře novým kontextem. K tomu slouží příkaz fixfiles, který dostane jako parametr  relabel.

Pokud spustíme

[root@noutec ~]# fixfiles relabel

přeznačkuje se celý systém, což je v tomto případě zbytečné. Vystačíme si s

[root@noutec ~]# fixfiles relabel /home/

a přeznačkuje se pouze adresář /home/ nebo jiný adresář, který dostane fixfiles za parametr. Když budeme chtít přeznačkovat pouze jeden soubor, například spustitelný program, který jsme nadefinovali jako vstupní bod do nové domény, vystačíme i s příkazem

[root@noutec ~]# restorecon /usr/bin/firefox

Implicitní nastavení ve Fedoře

V základní konfiguraci Fedora používá kontexty user_u:user_r:u­ser_t, staff_u:staff_r:staf­f_t pro uživatele, kontext root:sysadm_r:sy­sadm_t pro superuživatele a kontexty system_u:system_r:* a system_u:object_r:* pro systémové procesy a soubory.

SELinux identity:

• user_u – identita pro běžné uživatele
• staff_u – identita pro administrativní uživatele
• system_u – identita pro systémové procesy a soubory
• root – identita superuživatele

SELinux role:

• user_r – je role pro běžné uživatele bez možnosti provádět jakékoliv administrativní operace. Jejich bezpečnostní kontext je zpravidla user_u:user_r:u­ser_t (striktní politika), se kterým mohou spouštět běžné aplikace a mají přístup ke svým domovským adresářům.
• staff_r – je role pro uživatele, kteří mají v podstatě stejná oprávnění jako běžní uživatelé, ale mohou z ní přejít do role sysadm_r, což je role pro administrativ­ní účely
• sysadm_r – role pro administrativní operace
• secadm_r – role pro konfiguraci zabezpečení systému, může spouštět všechny SELinux nástroje, nesmí instalovat software a provádět jiné administrativní operace
• auditadm_r – role pro přístup k logům auditovacího daemona, může měnit nastavení auditovacího subsystému
• system_r – role pro systémové procesy
• object_r – role používaná pro soubory

Ve striktní police se secadm_r a auditadm_r role nepoužívají. Operace, které jsou oprávněny tyto role provádět, přísluší sysadm_r roli. Tyto role jsou uplatněny až v MLS politice a jejich oprávnění jsou roli sysadm_r odebrány.

V targeted politice dostává uživatel kontext user_u:system_r:un­cofined_t a může přistupovat ke všem typům. Doména unconfined_t je vytvořena jako alias množiny typů sysadm_t, secadm_t, sshd_t a auditadm_t.

Změny rolí

Jestliže zachováme implicitní kontexty, to znamená, že user_u je v roli user_r a staff_u v roli staff_r, jsou povoleny následující změny rolí (ve striktní politice).

• user_r – není povolena žádná změna role
• staff_r – povolen přechod do sysadm_r
• system_r – není povolena žádná změna role
• root – povoleny přechody do system_r, sysadm_r a staff_r

Závěr

Tímto bychom uzavřeli asi vše nutné o SELinux, abychom ho mohli bez větších problémů konfigurovat. I když se nám ze začátku třeba nebude dařit, později se to určitě zlepší. V příštím díle si krok za krokem projdeme, jak ten náš postup v praxi asi postupuje.

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
COKER, Faye. Writing SE Linux policy HOWTO
WALSH, Dan. danwalsh's Journal