Jak na SELinux: Role Based Access Control

Řekneme si:

• o RBAC a pravidlech
• jak vytvořit novou roli

Role Based Access Control, RBAC

Teď se věnujeme následující části kontextu:

RBAC je přístup založený na rolích. Pomocí RBAC docílíme ještě dalšího rozdělení oprávnění v systému. Vytvoříme novou roli nebo upravíme dříve definovanou a povolíme, k jakým typům (doménám) smí přistupovat a jaké operace s nimi může provádět. Tento způsob přístupu se v praxi příliš nepoužívá. Většina systémů si vystačí se zabezpečením pomocí jiného zabezpečeni, a to Type Enforcementem, o kterém bude řeč příště. Typickým příkladem by mohla být například role webmaster, ve které by měl uživatel přístup ke konfiguračním souborům apache a mohl je upravovat, ale neměl přístup nikam jinam, nebo role updater zodpovědná za aktualizace systému. Uživatel, pokud je mu povoleno, může vstupovat do několika rolí, ale stejně jako u TE domén smí v jeden okamžik vystupovat pouze v jedné roli.

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.

S RBAC budeme typicky pracovat pomocí tří typů pravidel:

• přístup identity k roli
• přístup role k typu
• přechod z jedné role do jiné

Pravidly tohoto typu

# user identita roles { množina rolí }
user staff_u roles { staff_r };

povolíme identitám staff_u vystupovat v roli staff_r.

Následujícím typem pravidel

# role naše_role types { množina_typů }
role sysadm_r types { sysadm_t run_init_t };

povolujeme přístupy role sysadm_r k typům sysadm_t a run_init_t.

A konečně, takto povolujeme přechod jedné role do jiné, z role staff_r do role sysadm_r.

# allow naše_role { množina_rolí }
allow staff_r { sysadm_r };

Změnu role provedem příkazem newrole

[honza@noutec ~]$ newrole -r nová_role

a autentizujeme se svým přihlašovacím heslem.

Nová role

Podíváme se jak bychom asi postupovali, kdybychom chtěli udělat novou roli, kterou bychom chtěli použít (oprávnit) jen k tomu, aby si v ní uživatel mohl zahrát některou z her, ale nemohl například brouzdat po internetu nebo spouštět jiné aplikace. Z prvního dílu víme, že na základě typu, můžeme rozhodnout u přístupu nebo zamítnutí k nějakému typu. A jelikož se SELinux drží hesla: „Co není explicitně povoleno, je zakázáno“, a bude se jednat v systému o novou roli, ke které žádná pravidla nejsou, bude mít tato role vše zakázáno, až na to, co si sami povolíme. Tím nám tedy zákazy jiných přístupů odpadají.

Řekněme, že už takovou roli máme vytvořenou (první nekomentář kódu níže), musíme však i vytvořit nějakou doménu, ve které poběží hry spuštěné naším hráčem (2. řádek). Máme roli a doménu, ale SELinux ještě neví, který SELinux uživatel se může do této role přejít (3. řádek) a jaký má přiřadit kontext (4. řádek). Teď už by se šlo v podstatě do této role přepnout (pomocí příkazu newrole), ale tato role by v praxi byla zatím nepoužitelná, jelikož nemá nic povoleno. Označkovali bychom hry typem games_t, a našemu hrači přístup k tomuto typu povolili. Nadále bychom museli přidat například přístup k domovským adresářům, přístup ke sdíleným knihovnám atp.

Až tedy nadefinujeme novou roli (player_r), musíme povolit některým identitám (SELinux uživatelům) se do této role přepnout, musíme vytvořit novou doménu (player_t) pro roli (player_r), povolit roli přístup k typu (player_t) a upravit konfigurační soubor default_type.

 # definujeme novou roli player_r
 role player_r;
 # vytvoříme jí doménu player_t
 type player_t, domain;

 # user identita roles { množina_rolí } \
   level lvl range rng;
 # povolíme identitě user_u vystupovat v roli \
   player_r, level s0 udává oprávnění a range \
   kategorii pro roli player_r
 # pravidlo sice požaduje specifikaci levelu a rozsahu, \
   které se týká MLS politiky, ale SELinux implicitně \
   používá s0, a tímto nám stačí jeden typ pravidel pro \
   všechny politiky
 user user_u roles player_r level s0 range s0;

 # editujeme soubor default_type a připíšeme řádek
 # po příkazu newrole -r player_r bude uživateli \
   přiřazen kontext user_u:player_r:player_t
 player_r:player_t

 # povolíme roli player_r přistupovat k typům player_t
 role player_r types { player_t };

Po zkompilování a zavedení modulu do jádra by se v systému objevila nová role player_r, která by zatím neměla povolen přístup k jinému typu než player_t.

Závěr

Nastínili jsme si přístup založený na rolích, ačkoliv je asi pravděpodobné, že většina uživatelů k tomuto typu přístupu nepřistoupí. Sice jsme si ukázali, jak RBAC chápat a jak s ním pracovat, ale celou konfiguraci jsme si neukázali. K postupu, která pravidla musíme napsat, aby naše role dobře fungovala, se dostaneme později. Bude je jednat o AVC zprávy.

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