Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.02.2020

Koszty w górę

Zmiany w licencjach VMware
24.02.2020

VPN na nowo

WireGuard w Linuksie
24.02.2020

Wydajność pod kontrolą

Citrix Analytics for Performance
24.02.2020

Zaawansowany backup

Veeam Availability Suite v10
20.02.2020

Serwery Enterprise

OVHCloud stawia na Ryzeny
20.02.2020

Monitory dla biznesu

Newline IP
20.02.2020

Przemysłowe SSD

Dyski Transcend M.2 NVMe
23.01.2020

Google Project Zero

Inicjatywa Google Project Zero
23.01.2020

Ochrona tylko w chmurze

Kaspersky Security Cloud Free

Zmiany w polityce SELinux

Data publikacji: 21-09-2015 Autor: Grzegorz Kuczyński

Skuteczność modułu bezpieczeństwa systemu Linux, jakim jest SELinux, bezpośrednio zależy od jego polityki. Pomimo że deweloperzy systemu starają się jak najlepiej przystosować dostarczaną politykę do sprawnego działania, nie są w stanie przewidzieć wszystkich zmiennych. Prędzej czy później, w miarę konfiguracji kolejnych usług systemowych, administrator systemu staje przed koniecznością wprowadzania zmian w istniejącej polityce SELinux.

Deweloperzy SELinux mają przed sobą dość karkołomne zadanie – jego polityka musi opisywać zachowanie każdego obiektu i procesu w systemie, czymkolwiek on by był. Język jądra służący do opisywania reguł z biegiem czasu rozszerza swoje możliwość, dzięki czemu również reguły polityki stają się coraz bardziej szczegółowe. Z każdym wydaniem systemu Fedora przybywa nowych domen. W początkowej fazie wdrożenia SELinux do RHEL firma Red Hat zdecydowała się zastosować politykę, którą nazwała targeted. Jej założenie było proste, mimo że mechanizm SELinux wymusza kontrolowanie absolutnie wszystkiego – polityka opisuje tylko wybrane usługi istotne z punktu widzenia bezpieczeństwa systemu operacyjnego, natomiast cała reszta operacji została opisana w ogólnych regułach, dzięki czemu zmniejszono ich liczbę.

Doskonałym przykładem jest domyślny typ plików wykonywalnych, jakim jest bin_t. Dla przykładu ponad 90% poleceń systemowych znajdujących się w lokalizacji /bin/ ma przypisany właśnie typ bin_t. Głównym celem takiego podejścia było uproszczenie sposobu administrowania systemem z włączonym mechanizmem SELinux. Oczywiście mimo tak dużego kompromisu poziom bezpieczeństwa systemu RHEL pozostaje bardzo wysoki. Niestety, polityka SELinux ciągle jest dość złożona. Dla przykładu w obecnej polityce targeted systemu RHEL7/CentOS7 samych typów zdefiniowano ponad 4,5 tysiąca, a na każdy z nich statystycznie przypadają około 23 reguły.

> ARCHITEKTURA MODUŁU SELinux

Przy omawianiu polityki SELinux istotnych jest kilka komponentów architektury systemowego modułu bezpieczeństwa. Ważne jest również to, skąd bierze się sama polityka. Tworzenie jej od zera jest zajęciem tak karkołomnym, że zapewne szybko porzuciliby je nawet bardzo zaawansowani administratorzy (lub uprościli tak bardzo, że byłoby to niekorzystne dla poziomu bezpieczeństwa). Dlatego deweloperzy SELinux rozwijają uniwersalną politykę zwaną referencyjną.

Niemal wszystkie dystrybucje oferujące własną politykę budują ją na bazie polityki referencyjnej. Polityka ta kompilowana jest do binarnej postaci z podziałem na moduły i zazwyczaj w takiej formie jest też dostarczana do systemu (wyjątkiem jest jej bazowa część). Binarne moduły są ładowane wprost do modułu jądra, jakim jest SELinux, a dokładnie do jego komponentu, który określany jest mianem Security Server. Jego zadaniem jest podejmowanie decyzji z wykorzystaniem polityki załadowanej do jądra. Ponieważ sama polityka jest bardzo obszerna, efektywniej jest zapamiętywać już wcześniej wyszukane decyzje. Do tego służy komponent Access Vector Cache, natomiast same reguły dostępu określane są mianem reguł Access Vector. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"