Hlavní navigace

Jak na SELinux: Role Based Access Control

Jan Horák

Pokračování seriálu o bezpečnějším počítači se subsystémem SELinux. Dnes se podrobněji podíváme na druhý z mechanizmů SELinuxu, a to Role Based Access Control, což je přesně to, co bychom asi z překladu očekávali, tedy přístup založený na rolích. A ukážeme si první kroky při konfiguraci SELinuxu.

Ř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:

system_u:system_r:sshd_t

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.

knihy

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

Našli jste v článku chybu?

12. 1. 2008 19:31

Zdravim, priste bude jeste neco z teorie, pak uz konfiguraky

12. 1. 2008 0:23

dozvieme sa niekedy konecne aj to, kam sa tie zahadne pravidla pisu, ci sa nejako kompiluju, a kto ich vlastne spracovava? (kernel, alebo nejaka utilita?)... proste nejaky nadhlad + priklad ucelenej jednoduchej konfiguracie s popisom, co robi (alebo skor.. vela prikladov :))
Vitalia.cz: Taky věříte na pravidlo 5 sekund?

Taky věříte na pravidlo 5 sekund?

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

DigiZone.cz: Dreambox DM900 Ultra HD přichází

Dreambox DM900 Ultra HD přichází

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

Vitalia.cz: I církev dnes vyrábí potraviny

I církev dnes vyrábí potraviny

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Vitalia.cz: Proč vás každý zubař posílá na dentální hygienu

Proč vás každý zubař posílá na dentální hygienu

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla