bezpieczeństwo

SELinux – bardziej bezpieczny Linux

52

luty 2007

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

53

www.lpmagazine.org

a

ut

or

zy

@

lpm

ag

az

ine

.o

rg

SELinux – bardziej

bezpieczny Linux

Czy system Linux oraz inne systemy uniksowe są bezpiecznymi systemami. Jeśli w odpowiedzi,
uwzględnimy np.: tylko samo jadro systemu to istotnie tak jest. Jest to bezpośrednia konsekwencja
faktu iż, wielu programistów szczególnie, w przypadku systemów o otwartym kodzie źródłowym,
każdego dnia stara sie naprawiać istniejące błędy, a liczna społeczność użytkowników owe błędy
wyłapuje. Co ogólnie poprawia szeroko rozumiane bezpieczeństwo.

Marek Sawerwain

Z

teoretycznego punktu widzenia może sie wy-
dawać, że trzy podstawowe prawa systemów
uniksowych: prawo czytania, zapisywania
oraz prawo wykonywania (tzw. prawa rwx)

odpowiednio zastosowane, mogą wystarczyć do stwo-
rzenia środowiska, które będzie bezpieczne i nie narazi
na utratę danych użytkowników tego środowiska.

Jednak z drugiej strony, system operacyjny dla zwy-

kłego użytkownika to nie tylko jadro systemu, lecz cały ze-
staw aplikacji stosowanych w codziennej pracy. Niestety,
wiele aplikacji posiada istotne uchybienia, co może naru-
szać bezpieczeństwo całego systemu. Źle napisana aplika-
cja sieciowa, uruchomiona nawet na poziomie konta zwy-
kłego użytkownika, może być źródłem wielu kłopotów.
I niestety, nie pomogą tu prawa dostępu bądź odpowied-
nia hierarchia użytkowników. Czy istnieje zatem sposób,
aby np.: zablokować uruchamianie pewnych programów,
jednak nie odbierając samych praw. Odpowiedź jest natu-
ralnie twierdząca, a jest nim zestaw specjalnych rozszerzeń
o nazwie SELinux. Sposób działania tego systemu można
porównać do ściany ogniowej, lecz tym razem jest to zapo-
ra dla aplikacji.

Czym jest SELinux ?

Najkrócej o projekcie SELinux można powiedzieć iż jest
to „łatka” na standardowe jądro Linuxa. W jądrze, funk-
cjonuje bowiem mechanizm o nazwie Linux Security Mo-
dule (w skrócie LSM), czyli jest to część jądra Linuxa która
oferuje możliwość implementacji różnych dodatkowych
mechanizmów bezpieczeństwa. SELinux jest elementem
który pojawia się właśnie jako moduł LSM. Jednak, naj-
nowsze jądra z serii 2.6.x oferują już na stałe mechani-
zmy SELinuxa, toteż od tej serii jąder SELinux jest natu-
ralną częścią jądra Linuxa. Obecnie, w większości waż-
niejszych dystrybucji przedstawiane mechanizmy są już
obecne.

Jednak, oprócz samych modyfikacji jądra, istotnym

elementem są nowe wersje programów, które korzystają
z możliwości SELinuxa. Szczególnie ważne są kluczo-
we programy dla bezpieczeństwa systemu jak ssh, ls, ps
czy np: login. Te programy zostały dopasowane do no-
wych zabezpieczeń. Choć warto dopowiedzieć iż nowe
rozszerzenia zostały tak opracowane, iż nie ma potrze-
by aby modyfikować istniejące oprogramowanie. Jeśli,
dany program wymaga specjalnych uprawnień, wystar-

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

52

luty 2007

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

53

www.lpmagazine.org

czy utworzyć odpowiednie zasady. Wspom-
niane zasady (ang. policy) także są nieod-
łącznym elementem bezpieczeństwa. To one
decydują który użytkownik ma dostęp do
urządzeń czy plików. Domyślny, zbiór re-
guł zapewnia wysoki poziom bezpieczeń-
stwa. Naturalnie, administrator może zmie-
nić reguły bądź utworzyć nowe aby dopa-
sować system do własnych specyficznych
potrzeb.

Toteż zadaniem opisywanych rozsze-

rzeń jest zwiększenie bezpieczeństwa, po-
przez wprowadzenie nowych ograniczeń
bardziej szczegółowych niż typowe prawa
rwx. Użytkownicy są przypisywani do wcześ-
niej określonych ról. Pozwala to na wpro-
wadzanie ograniczeń w dostępie do urzą-
dzeń i plików. Co ważne SELinux rozsze-
rza istniejące prawa dostępu, co oznacza iż
w przypadku złej konfiguracji nowych roz-
szerzeń, nie naruszamy istniejących typo-
wych mechanizmów bezpieczeństwa. Dla-
czego tak jest? Jak już to zostało powiedzia-
no, nowe prawa ograniczają istniejące, nie
są to bowiem zupełnie nowe prawa. To-
też, jeśli nastąpi naruszenie praw SELinu-
x'a, nadal w mocy pozostaną aktualne stan-
dardowe prawa Linuxa.

Nieco teorii o nowych

rozszerzeniach

Najważniejszym elementem SELinuxa jest
wprowadzenie bardzo silnej kontroli dostę-
pu (ang. Mandatory Access Control – MAC).
Ogólnie mówiąc, jest to rozszerzenie stan-
dardowych mechanizmów praw dostępu do
plików oraz grup i użytkowników. Kontro-
la odbywa się na poziomie procesu który po-
wstał w wyniku działań użytkownika. Pro-
ces otrzymuje tzw. kontekst bezpieczeństwa,
Mechanizmy kontroli MAC sprawdzają rów-
nież kontekst bezpieczeństwa obiektu na
którym dany proces ma pracować. Po wery-
fikacji, czy dany proces z otrzymanym kon-
tekstem może wykonać czynności do któ-
rych został powołany następuje odmowa
lub zgoda na wykonanie zadania jakie re-
alizuje proces.

Istnieje jedna zasadnicza różnica pomię-

dzy mechanizmami MAC, a standardowy-
mi rozwiązaniami dostępnymi w Linuxie.

W przypadku SELinuxa tylko administra-
tor systemu może określać nowe prawa do-
stępu. Jest to zupełnie odmienne podejście
w porównaniu do tradycyjnego rozwiązania,
gdzie każdy użytkownik może zarządzać
prawami, choć tylko we własnym otoczeniu.
W przypadku SELinuxa, tak nie jest, gdyż
prawa są przydzielane tylko przez admini-
stratora.

Drugim, wbrew pozorom nie zupełnie

nowym mechanizmem jest wprowadzenie
systemu kontroli opartego o role. System RB-
AC (jest to skrót od ang. Role Based Access Con-
trol) oferuje możliwość przypisywania specy-
ficznej roli poszczególnym użytkowników.
W taki sposób funkcjonuje standardowy me-
chanizm użytkowników, mamy przecież użyt-
kowników systemowych, standardowych czy
wręcz dedykowanych do pewnym wybra-
nych zadań np.: do obsługi serwera WWW.
Jednak, RBAC zmienia nieco ten schemat,
ponieważ prawa nie są przydzielane bezpo-
średnio do użytkowników lecz do ról. Co wię-
cej, w jednej chwili użytkownik, może peł-
nić tylko jedną rolę, co ogranicza potencjal-
ne szkody. Jest to naturalnie mniej wygod-
nie, ponieważ należy się przełączać pomię-
dzy rolami ale podnosi w znaczący sposób
bezpieczeństwo.

Uzyskanie dostępu do pewnej roli ozna-

cza iż użytkownik będzie korzystać z pew-
nych obiektów, czyli z plików, katalogów
oraz innych urządzeń. W roli, prawa są przy-
dzielone, jednak do pewnych typów. Naj-
ważniejszym ograniczeniem jest fakt iż tyl-
ko administrator może tworzyć nowe typy
i przydzielać je do obiektów. Ten mecha-
nizm nazywany jest najczęściej jako system
kontroli dostępu w ramach domeny. (ang.
Dynamically Typed Access Control – DTAC),
lepiej jednak mówić o tym systemie jako

o mechanizmie definiowania reguł dostępo-
wych.

Choć ilość typów jest nieograniczona to

jednak nadmierna ilość różnych typów
wprowadza tylko dodatkowe zmieszanie,
więc najlepiej nie przesadzać z ilością ty-
pów. Tym bardziej iż w typowej instalacji
SELinux, istnieją nie setki ale tysiące tego
rodzaju reguł (zwykle około 100 000). Regu-
ły te pozwalają na bardzo precyzyjne okre-
ślanie, jakie szczegółowe prawa są przy-
dzielane do obiektów.

Odrobina szczegółów

Użytkownik który pracuje w danym sys-
temie, naraz może korzystać z tylko jednej
roli, naturalnie istnieje rola domyślna. W ra-
mach każdej roli, mamy dostęp tylko do wcześ-
niej określonych obiektów poprzez dome-
ny. Podobnie jak w przypadku roli możemy
znajdować się naraz tylko w jednej domenie.
Jednak, nasze rzeczywiste możliwości są wy-
znaczanie na podstawie typu obiektu na któ-
rym działamy, bowiem reguły o których była
mowa w poprzednim punkcie określą nam
możliwe interakcje pomiędzy domeną a ty-
pem obiektu. Najczęściej tworzone są nastę-
pujące reguły:

• określanie dopuszczalnych operacji jak

czytanie, pisanie, tworzenie,

• dopuszczalne zmiany roli,
• możliwe zmiany domeny,
• określenie automatycznych zmian do-

meny oraz roli w przypadku zajścia jakiś
konkretnych okoliczności.

W SELinuxie każdy proces oraz użytkownik
posiada tzw. kontekst bezpieczeństwa. Ogól-
nie na kontekst składają się trzy elemen-
ty a są to:

użytkownik:rola:domena

. Jeśli,

Rysunek 1.

Ogólny schemat systemu SELinux,

przedstawia podział na trzy części, użytkowników,
role i typy

Rysunek 2.

Dokładniejsze przedstawienie struktury nowych rozwiązań dostępnych w SELinuxie

54

luty 2007

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

55

www.lpmagazine.org

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

użytkownik o nazwie np.: dorota zaloguje
się do typowego systemu, gdzie istnieje SE-
Linux, to dorota zazwyczaj otrzyma nastę-
pujący kontekst:

dorota:user_r:user_t

,

gdzie

user_r

to domyślna rola a

user_t

to

domyślna domena. Aktualny kontekst mo-
żemy sprawdzić za pomocą polecenia

id

a jeszcze lepiej

id -Z

. W efekcie otrzymamy

następującą odpowiedź (np.: dla dystrybu-
cji Fedora Core 6):

user_u:system_r:unconfined_t

Jak widać mamy tu jeszcze większe ograni-
czenie, gdyż domyślnym określeniem użyt-
kownika dorota jest

user_r

.

Inne przykłady kontekstów są następu-

jące dla plików wykonywalnych po wykona-
niu

ls -alZ

:

-rwxr-xr-x root root system_u:
object_r:bin_t /usr/bin/gcalctool
-rwxr-xr-x root root system_u:
object_r:bin_t /usr/bin/gcc
-rwxr-xr-x root root system_u:
object_r:java_exec_t /usr/bin/
gcj-dbtool

Na przykładzie tych plików widać iż kon-
tekst dla zwykłych typów kończy się typem

bin_t

lecz program dla Javy jest specjalnie

traktowany

java_exec_t

. W podobny spo-

sób możemy sprawdzić kontekst bezpieczeń-
stwa dla procesów poleceniem

ps -eZ

:

system_u:system_r:init_t 1 ?
00:00:00 init
system_u:system_r:kernel_t 2 ?
00:00:00 migration/0
system_u:system_r:udev_t:System
Low-SystemHigh 441 ? 00:00:00 udevd
system_u:system_r:xfs_t 2190 ?
00:00:00 xfs
system_u:system_r:getty_t 2368
tty4 00:00:00 mingetty
user_u:system_r:unconfined_t 2515
tty2 00:00:00 bash
root:system_r:unconfined_t:System
Low-SystemHigh 2544 tty1 00:00:00 ps

Tym razem poszczególne usługi systemowe
mają przydzielone różne typy, mamy spe-
cjalny typ

init_t

dla pierwszego procesu

w systemie, a usługi działające na poziomie
jądra posiadają własne typy. Typowe proce-
sy użytkownika posiadają kontekst:

user_u:

system_r:unconfined_t

.

Przykład typu dla Javy pokazuje iż od-

powiednie określenie typów i praw daje na
wiele możliwości w ochronie systemu. Przy-
kładem który zazwyczaj się pokazuje jest do-
mena

user_irc_t

. Stowarzyszona jak poda-

je nazwa z klientami do sieci IRC. Plik wyko-
nywalny klienta IRC posiada także swój typ o
nazwie

irc_exec_t

, po uruchomieniu przez

użytkownika klienta IRC następuje zmiana
domeny w następujący sposób:

user:user_r:user_t

zmiana do

user:user_r:user_irc_t

Domena

user_irc_t

posiada liczne ogranicze-

nia, domyślnie w jej ramach program może za-
pisywać informacje do logów bądź korzystać
z podstawowych plików konfiguracyjnych.
Ewentualne włamanie się przez klienta, nie za-
grozi nawet jego własnym plikom, ponieważ
klient IRC jest uruchamiany w innej domenie.

Odrobina praktyki

Gdy chcemy wprowadzić do systemu nadzo-
rowanego przez SELinux nowego użytkowni-
ka, to pierwszą czynnością jaką trzeba wyko-
nać, jest zmiana aktualnej roli użytkownika za
pomocą polecenia newrole. Ponieważ chcemy

Rysunek 3.

Konfiguracja SELinuxa za pomocą narzędzia graficznego w dystrybucji Fedora Core 6

Pierwsze rozwiązania jakie stały się podsta-
wą dla SELinux powstały już w roku 1992
dla jądra MACH, gdzie pojawiły się bardzo
rozbudowane mechanizmy kontroli dostę-
pu. Pierwsze publiczne udostępnienie kodu
nastąpiło w 2000 roku. Od roku 2003 SELi-
nux jest łączony z kodem jądra w wersji 2.6.
Dlatego, aktualnie SELinux jest silnie zin-
tegrowanym z jądrem, właśnie dla tej wer-
sji i jest rozwijany przez firmę Secure Com-
puting Corportaion którą finansowo od po-
czątku wspiera amerykańska agencja bez-
pieczeństwa narodowego (NSA – Natio-
nal Security Agency). SELinux jest dostęp-
ny w najnowszych dystrybucjach Fedo-
ra Core, specjalnej dystrybucji dla serwe-
rów Gentoo Hardend. SELinux oferuje tak-
że Debian oraz SuSE, istnieje także port dla
FreeBSD.

Choć można się doszukiwać w udo-

stępnieniu mechanizmów SELinuxa szero-
kiej społeczności, spiskowej teorii dziejów,
to jednak warto pamiętać iż Linux staje się
coraz bardziej popularny, i w grę wchodzą
aspekty ekonomiczne. Liczba strat jakie
powstają w wyniku błędnych zabezpieczeń
systemów komputerowych jest coraz więk-
sza, więc to ostatecznie zwykły rachunek
ekonomiczny przemawia za udostępnie-
niem SELinux społeczności OpenSource,
jak przecież wiadomo siła leży w grupie.

Historia projektu SELinux

54

luty 2007

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

55

www.lpmagazine.org

bezpieczeństwo

SELinux – bardziej bezpieczny Linux

wykonywać czynności administracyjne, więc
przełączamy się do roli o nazwie

sysadm_r

:

newrole -r sysadm_r

Zostaniemy poproszeni o podanie hasła dla
administratora. Następnie za pomocą dwóch
typowych poleceń adduser oraz passwd, two-
rzymy nowego użytkownika oraz określamy
jego domyślne hasło. W ten sposób, do syste-
mu został dodany nowy użytkownik. Jednak,
nie posiada on żadnych praw w SELinux'ie.
Dlatego, w pierwszej kolejności trzeba okre-
ślić jego rolę. Pliki związane z regułami mo-
gą znajdować się w wielu miejscach choć naj-
częściej są to katalogi /etc/security/selinux albo
/etc/selinux. Plik z informacjami o użytkow-
nikach może znajdować się np.: w katalogu
/etc/selinux/users. Należy, na samym końcu
dodać nową regułę np.:

user dorota roles { user_r };

W ten sposób użytkownik dorota przez nowe
mechanizmy bezpieczeństwa będzie postrze-
gany jako typowy użytkownik. Jeśli chcemy
zwiększyć prawa użytkownika, poprzez do-
pisanie go do różnych ról pomiędzy którymi
może się on przełączać np.: chcemy dać możli-
wość administracji systemem to reguła przed-
stawia się bardzo prosto:

user dorota roles { user_r sysadm_r };

Użytkownik dorota może korzystać z dwóch
ról

user_r

bądź

sysadm_r

. Niestety, po wpro-

wadzeniu zmian do pliku /etc/selinux/users nie
są one domyślnie wprowadzane do systemu.
Należy za pomocą dodatkowego polecenia do-
konać kompilacji wszystkich reguł. W przy-
padku typowej instalacji nowych rozszerzeń
wykonujemy polecenie:

make -C /etc/selinux load

Ponieważ reguł jest wiele, więc kompilacja mo-
że zabrać sporo czasu. Możemy teraz dokład-
nie określić jakie programy mogą być urucha-
miane przez poszczególnych użytkowników,
definiując w szczegółowy sposób rolę dla użyt-
kownika:

role user_r types { user_t
user_firefox_t user_irc_t };

Przydzielona rola

user_r

oznacza iż użyt-

kownik z tej roli może korzystać z obiektów
ogólnego typu

user_t

np.: pliki z doku-

mentami, ale z drugiej strony może urucha-

miać tylko obiekty związane z przeglądarką
internetową

user_firefox_t

oraz omawiany

już klient do sieci IRC

user_irc_t

. Tworząc

własne role, może ściśle przydzielać dostęp
do odpowiednich programów definiując od-
powiednie typy.

Informacje o typach plików są zgromadzo-

ne w pliku file_context oraz w plikach o rozsze-
rzeniu *.fc. Dobrym przykładem może być opis
katalogu domowego np.:

/home system_u:object_r:home_root_t

Natomiast poszczególne pliki mogą być okre-
ślone jako:

/home/[^/]+/.+ system_u:object_r:
user_home_t

Jeśli administratorowi systemu zależy na
większej prywatności może jawnie rozdzielić
typy na poszczególnych użytkowników:

/home/dorota/[^/]+/.+ system_u:
object_r:user_dorota_home_t

Powracając do przykładu z klientem do sieci
irc możemy określić zachowanie się obiektów
które są plikami tymczasowymi:

allow user_irc_t irc_tmp_t:file {
create read write getattr setattr
link unlink rename };

Taka deklaracja nazywana jest także wek-
torem dostępu, ponieważ określamy jakie
czynności mogą być wykonywane na danym
pliku. Oczywiście SELinux, pozwoli na przy-
dzielenie określonych praw jednemu określo-
nemu plikowi, które może działać w jednej
domenie. Nie ma przeszkód aby istniał tylko
jeden użytkownik który może modyfikować
ten plik. Jednak, jak to już wcześniej powie-
dziono regułami zarządza administrator i to
tylko on może podjąć decyzję o takim postę-
powaniu.

Można przytoczyć jeszcze wiele przykła-

dów reguł np.: dla serwera Apache dostęp do
gniazdka sieciowego jest określony w nastę-
pujący sposób:

allow httpd_suexec_t self:unix_stream_
socket create_socket_perms;

Ponieważ, obostrzenia na pliki są mimo
wszystko dodatkowym elementem w syste-
mie plików, wymienione rodzaje praw nie
są nadawane za pomocą standardowego po-
lecenia chmod, toteż niezbędne jest etykieto-

wanie systemy pliku za pomocą polecenia
o postaci np.:

make -C /etc/selinux/policy relabel

W ten sposób, poszczególne pliki w systemie
otrzymają zdefiniowane przez nas nowe ty-
py. To polecenie, podobnie jak load również
może zabrać sporo czasu.

Podsumowanie

Mam nadzieję iż udało się mi zachęcić do dal-
szych poszukiwań informacji na temat SE-
Linuxa. Projekt ten jest świetnym przykła-
dem iż Linux może być systemem o wyso-
kim stopniu bezpieczeństwa. Naturalnie, ten
artykuł to tylko wprowadzenie do tematyki
systemu SELinux. I wiele elementów zostało
pominiętych. Jednakże, w ramach uzupełnie-
nia, warto wspomnieć o teście, jaki przepro-
wadził jakiś czas temu Russel Coker. Udostęp-
nił on komputer z zainstalowanym SELinu-
xem, wraz ze standardowymi ustawieniami.
Udostępnił także hasło roota do tej maszyny,
jak się okazało nikt nic istotnego nie zdołał
zepsuć. Co jest znakomitym przykładem jako-
ści SELinuxa. Jego zaletą jest także zgodność
z normą POSIX.6 (system MAC jest przykła-
dem techniki zgodnej z tą normą). Wadą jest
niewątpliwie problematyczna konfiguracja
szczególnie dla początkujących użytkowni-
ków, sprawia wiele kłopotów. Drugą istotną
wadą jest także obniżenie wydajności syste-
mu, szczególnie, jeśli zbiór reguł jest bardzo
rozbudowany. Jednak zalet jest więcej, dlatego
warto sprawdzić, czy nasza ulubiona dystry-
bucja zawiera wsparcie dla SELinuxa?

Autor zajmuje się tworzeniem oprogramo-
wania dla Linuksa oraz WIN32. Zaintereso-
wania: teoria języków programowania oraz
dobra literatura.
Kontakt z autorem: [e-mail]

O Autorze

• Strona domowa NSA poświęcona

projektowi SELinux:

http://www.nsa.gov/selinux

• Lista najczęściej zadawanych pytań:

http://www.nsa.gov/selinux/info/
faq.cfm

• Podstawowe informacje o SELinuxie:

http://en.wikipedia.org/wiki/Selinux

W Sieci