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



23.06.2020

PLNOG Online

PLNOG Online
23.06.2020

Nowe zagrożenie

Ramsay
23.06.2020

Chmurowe kopie

Veeam Backup dla Microsoft Azure
19.06.2020

Nowości w kontenerach

Red Hat OpenShift 4.4
19.06.2020

Analityka bezpieczeństwa

FortiAI
19.06.2020

UPS dla obliczeń edge

Schneider APC Smart-UPS
16.06.2020

Przemysłowe SD

Nowe karty Transcend
16.06.2020

Storage dla SMB

QNAP TS-451DeU
16.06.2020

Pamięć masowa

Dell EMC PowerStore

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"