🥇Systemy ochrony Linux

Jednym z powodów ogromnego sukcesu systemu Linux na zintegrowanych, mobilnych urządzeniach i serwerach jest stosunkowo wysoki poziom bezpieczeństwa jądra, towarzyszących usług i aplikacji. Jednak jeśli przyjrzeć się uważnie architekturze jądra Linux, to nie można w nim znaleźć kwadratu odpowiedzialnego za bezpieczeństwo jako takie. Gdzie zatem ukrywa się podsystem bezpieczeństwa Linux i z czego się składa?

Historia modułów bezpieczeństwa Linux i SELinux

Security Enhanced Linux to zestaw reguł i mechanizmów dostępu, oparty na modelach dostępu mandatu i ról, mających na celu ochronę systemów Linux przed potencjalnymi zagrożeniami oraz zniwelowanie wad Discretionary Access Control (DAC) – tradycyjnego systemu bezpieczeństwa Unix. Projekt ten powstał w Agencji Bezpieczeństwa Narodowego USA, nad jego rozwojem pracowali głównie kontrahenci Secure Computing Corporation oraz MITRE, a także kilka laboratoriów badawczych.

Moduły bezpieczeństwa Linux

Linus Torvalds zgłosił szereg uwag na temat nowych rozwiązań NSA, aby mogły zostać włączone do głównej gałęzi jądra Linux. Opisał ogólne środowisko z zestawem przechwytywaczy do zarządzania operacjami na obiektach oraz zestawem pewnych pól ochronnych w strukturach danych jądra do przechowywania odpowiednich atrybutów. Następnie to środowisko może być wykorzystywane przez moduły jądra do wdrażania dowolnego pożądanego modelu bezpieczeństwa. LSM został w pełni włączony do jądra Linux v2.6 w 2003 roku.

Framework LSM zawiera pola ochronne w strukturach danych oraz wywołania funkcji przechwytywania w krytycznych punktach kodu jądra, aby zarządzać nimi i realizować kontrolę dostępu. Dodaje również funkcje do rejestrowania modułów bezpieczeństwa. Interfejs /sys/kernel/security/lsm zawiera listę aktywnych modułów w systemie. Hooki LSM są przechowywane w listach, które są wywoływane w kolejności określonej w CONFIG_LSM. Szczegółowa dokumentacja dotycząca hooków jest zawarta w pliku nagłówkowym include/linux/lsm_hooks.h.

Podsystem LSM umożliwił pełną integrację SELinux w tej samej wersji stabilnego jądra Linux v2.6. Natychmiast po tym, SELinux stał się standardem de facto zabezpieczonego środowiska Linux i został włączony do najbardziej popularnych dystrybucji: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Słownik terminów SELinux

Tożsamość Użytkownik SELinux nie jest tym samym, co tradycyjny identyfikator użytkownika Unix/Linux; mogą współistnieć na tym samym systemie, ale zasadniczo różnią się od siebie. Każde standardowe konto Linux może odpowiadać jednemu lub kilku w SELinux. Tożsamość SELinux jest częścią ogólnego kontekstu bezpieczeństwa, który określa, do jakich domen można uzyskać dostęp, a do jakich — nie.
Domeny W SELinux domena jest kontekstem wykonawczym podmiotu, czyli procesu. Domena bezpośrednio określa dostęp, który ma proces. Domena to zasadniczo lista tego, co mogą robić procesy lub jakie działania proces może wykonywać z różnymi typami. Przykłady domen to: sysadm_t dla administracji systemu oraz user_t, który jest zwykłym nieuprzywilejowanym domeną użytkownika. System inicjalizacji init uruchamiany jest w domenie init_t, a proces named uruchamiany jest w domenie named_t.
Role To, co służy jako pośrednik między domenami a użytkownikami SELinux. Role określają, w jakich domenach użytkownik może się znajdować i do jakich typów obiektów może uzyskać dostęp. Taki mechanizm rozgraniczania dostępu zapobiega zagrożeniu przeprowadzenia ataku podwyższenia przywilejów. Role zapisane są w modelu bezpieczeństwa opartego na rolach (Role Based Access Control, RBAC), stosowanym w SELinux.
Typy Atrybut listy Type Enforcement, który jest przypisywany obiektowi i określa, kto ma do niego dostęp. Podobny do definicji domeny, z tą różnicą, że domena stosuje się do procesu, a typ stosuje się do takich obiektów jak katalogi, pliki, gniazda itp.
Podmioty i obiekty Procesy są podmiotami i uruchamiane są w określonym kontekście, czyli w domenie bezpieczeństwa. Zasoby systemu operacyjnego: pliki, katalogi, gniazda itp., są obiektami, którym przypisany jest określony typ, innymi słowy — poziom poufności.
Polityki SELinux Aby chronić system, SELinux stosuje różnorodne polityki. Polityka SELinux określa dostęp użytkowników do ról, ról do domen oraz domen do typów. Na początku użytkownik autoryzowany jest do uzyskania roli, następnie rola jest autoryzowana do dostępu do domen. Na koniec domena może mieć dostęp jedynie do niektórych typów obiektów.

LSM i architektura SELinux

Mimo nazwy LSM nie są to w zasadzie moduły do ładowania jądra Linux. Jednak podobnie jak w przypadku SELinux, jest on bezpośrednio zintegrowany z jądrem. Każda zmiana kodu źródłowego LSM wymaga nowej kompilacji jądra. Odpowiednia opcja musi być włączona w ustawieniach jądra, w przeciwnym razie kod LSM nie zostanie aktywowany po uruchomieniu. Ale nawet w tym przypadku można go włączyć opcją bootloadera OS.

Stos sprawdzeń LSM

LSM wyposażony jest w haki w głównych funkcjach jądra, które mogą być odpowiednie do sprawdzeń. Jedną z głównych cech LSM jest to, że są one zorganizowane na zasadzie stosu. W ten sposób standardowe sprawdzenia są nadal wykonywane, a każdy poziom LSM jedynie dodaje dodatkowe elementy kontroli. Oznacza to, że zakazu nie można cofnąć. Jak pokazano na rysunku, jeśli wyniki rutynowych sprawdzeń DAC zakończyły się odmową, to sprawa nawet nie może dotrzeć do haków LSM.

SELinux przejął architekturę bezpieczeństwa Flask z badawczej wersji systemu operacyjnego Fluke, w szczególności zasadę najmniejszych uprawnień. Istota tej koncepcji, zgodnie z ich nazwą, polega na przyznawaniu użytkownikowi lub procesowi jedynie tych praw, które są niezbędne do realizacji zamierzonych działań. Zasada ta jest realizowana za pomocą przymusowej typizacji dostępu, w ten sposób kontrola dostępu w SELinux opiera się na modelu domena => typ.

Dzięki przymusowej typizacji dostępu SELinux ma znacznie większe możliwości ograniczania dostępu niż tradycyjny model DAC, stosowany w systemach Unix/Linux. Na przykład można ograniczyć numer portu sieciowego, który będzie wykorzystywany przez serwer FTP, zezwolić na zapis i zmiany plików w określonym folderze, ale nie na ich usunięcie.

Główne składniki SELinux to:

Serwer egzekwowania polityki — Główny mechanizm kontroli dostępu.
Baza danych polityk bezpieczeństwa systemu.
Interakcja z przechwytywaczem zdarzeń LSM.
Selinuxfs — Pseudo-FS, podobnie jak /proc i zamontowane w /sys/fs/selinux. Dynamcznie wypełniane przez jądro Linux w czasie wykonywania i zawiera pliki z informacjami o statusie SELinux.
Cache Wektorów Dostępu — Mechanizm pomocniczy zwiększający wydajność.

Schemat działania SELinux

Wszystko to działa w następujący sposób.

Podmiot, w terminologii SELinux, wykonuje dozwoloną akcję na obiekcie po przeprowadzeniu weryfikacji DAC, jak pokazano na górnym obrazku. To zapytanie o wykonanie operacji trafia do przechwytywacza zdarzeń LSM.
Stamtąd zapytanie razem z kontekstem bezpieczeństwa podmiotu i obiektu jest przekazywane do modułu SELinux Abstraction and Hook Logic, odpowiedzialnego za interakcję z LSM.
Instancją podejmowania decyzji o dostępie podmiotu do obiektu jest Policy Enforcement Server, do którego docierają dane z SELinux AnHL.
Aby podjąć decyzję o dostępie lub jego odmowie, Policy Enforcement Server odwołuje się do podsystemu pamięci podręcznej najczęściej używanych zasad Access Vector Cache (AVC).
Jeśli decyzja dla odpowiedniej zasady nie zostanie znaleziona w pamięci podręcznej, zapytanie jest przekazywane dalej do bazy danych polityk bezpieczeństwa.
Wynik wyszukiwania z bazy danych i AVC jest zwracany do Policy Enforcement Server.
Jeśli znalezione zasady zgadzają się z żądaną akcją, to operacja jest dozwolona. W przeciwnym razie operacja jest zabroniona.

Zarządzanie ustawieniami SELinux

SELinux działa w jednym z trzech trybów:

Enforcing — Ścisłe egzekwowanie polityk bezpieczeństwa.
Permissive — Dopuszcza się naruszenie ograniczeń, odpowiednia informacja jest rejestrowana.
Disabled — Polityki bezpieczeństwa nie mają mocy.

Można sprawdzić, w jakim trybie znajduje się SELinux, za pomocą następującego polecenia.

[admin@server ~]$ getenforce
Permissive

Zmiana trybu do czasu restartu, na przykład ustawienie na enforcing, lub 1. Parametrowi permissive odpowiada kod numeryczny 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 # to samo

Można również zmienić tryb poprzez edycję pliku:

[admin@server ~]$ cat /etc/selinux/config

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=wymuszony # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection.
SELINUXTYPE=targete

Różnica z setenfoce polega na tym, że przy uruchamianiu systemu operacyjnego tryb SELinux będzie ustawiony zgodnie z wartością parametru SELINUX w pliku konfiguracyjnym. Oprócz tego, zmiany enforcing disabled wchodzą w życie tylko poprzez edycję pliku /etc/selinux/config i po restarcie.

Wyświetlenie krótkiego raportu stanu:

[admin@server ~]$ sestatus

Status SELinux: włączony Montaż SELinuxfs: /sys/fs/selinux Katalog główny SELinux: /etc/selinux Załadowana nazwa polityki: targeted Aktualny tryb: permissive Tryb z pliku konfiguracyjnego: enforcing Status polityki MLS: włączony Status deny_unknown polityki: dozwolony Maksymalna wersja polityki jądra: 31
Aby wyświetlić atrybuty SELinux, niektóre standardowe narzędzia używają parametru -Z.

[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL                             PID TTY          TIME CMD
system_u:system_r:httpd_t:s0     2914 ?        00:00:04 httpd
system_u:system_r:httpd_t:s0     2915 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2916 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2917 ?        00:00:00 httpd
...
system_u:system_r:httpd_t:s0     2918 ?        00:00:00 httpd

W porównaniu do standardowego wyjścia ls -l, tutaj pojawiają się dodatkowe pola w następującym formacie:

:::

Ostatnie pole oznacza coś w rodzaju klauzuli poufności i składa się z kombinacji dwóch elementów:

s0 — znaczenie, również zapisuje się jako aby wskazać zakres lowlevel-highlevel
c0, c1… c1023 — kategoria.

Zmiana konfiguracji dostępu

Użyj semodule, aby ładować moduły SELinux, dodawać je i usuwać.

[admin@server ~]$ semodule -l |wc -l #lista wszystkich modułów
408
[admin@server ~]$ semodule -e abrt #enable - włączyć moduł
[admin@server ~]$ semodule -d accountsd #disable - wyłączyć moduł
[admin@server ~]$ semodule -r avahi #remove - usunąć moduł

Pierwsza komenda semanage login wiąże użytkownika SELinux z użytkownikiem systemu operacyjnego, druga wyświetla listę. Ostateczna komenda z kluczem -r usuwa powiązanie użytkowników SELinux z kontami systemu. Wyjaśnienie składni zakresów MLS/MCS znajduje się w poprzedniej sekcji.

[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l

Nazwa logowania Użytkownik SELinux Zakres MLS/MCS Usługi __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * [admin@server ~]$ semanage login -d karol
Zespół semanage user jest używane do zarządzania powiązaniami między użytkownikami a rolami SELinux.

[admin@server ~]$ semanage user -l
                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles
guest_u         user       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          user       s0         s0                    user_r
xguest_u        user       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u

Parametry komendy:

-a dodać wpis użytkownika dopasowującego rolę;
-l lista dopasowań użytkowników i ról;
-d usunąć wpis użytkownika dopasowującego rolę;
-R lista ról przypisanych do użytkownika;

Pliki, porty i wartości logiczne

Każdy moduł SELinux dostarcza zestaw reguł etykietowania plików, można jednak dodać własne reguły w razie potrzeby. Na przykład, chcemy nadać serwerowi WWW prawa dostępu do folderu /srv/www.

[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/

Pierwsza komenda rejestruje nowe reguły etykietowania, a druga przywraca, a raczej ustawia, typy plików zgodnie z aktualnymi regułami.

Podobnie, porty TCP/UDP są oznaczone w taki sposób, że tylko odpowiednie usługi mogą ich słuchać. Na przykład, aby serwer WWW mógł nasłuchiwać na porcie 8080, należy wykonać polecenie.

[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080

Znaczna liczba modułów SELinux ma parametry, które mogą przyjmować wartości logiczne. Pełną listę takich parametrów można zobaczyć za pomocą getsebool -a. Zmieniać wartości logiczne można za pomocą setsebool.

[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi ---> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_homedirs ---> off

Praktyka, uzyskać dostęp do interfejsu Pgadmin-web

Rozważmy przykład z praktyki, zainstalowaliśmy na RHEL 7.6 pgadmin4-web do zarządzania bazami danych PostgreSQL. Przeszliśmy przez mały quest z konfiguracją pg_hba.conf, postgresql.conf i config_local.py, nadaliśmy prawa do folderów, zainstalowaliśmy brakujące moduły Pythona z pip. Wszystko gotowe, uruchamiamy i otrzymujemy 500 Internal Server error.

Zaczynamy od typowych podejrzanych, sprawdzamy /var/log/httpd/error_log. Tam znajdują się interesujące wpisy.

[timestamp] [core:notice] [pid 23689] Włączona polityka SELinux; httpd działa w kontekście system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Odrzucono uprawnienia: '\/var\/lib\/pgadmin' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] WSKAZÓWKA: Możliwe, że musisz ręcznie ustawić uprawnienia na [timestamp] [wsgi:error] [pid 23690] \/var\/lib\/pgadmin, aby umożliwić apache'owi zapis do niego.

W tym momencie większość administratorów Linux będzie miała silne pokuszenie, by uruchomić setenforce 0 i zakończyć sprawę. Przyznam, że pierwszy raz tak właśnie zrobiłem. Oczywiście to także wyjście, ale nie najlepsze.

Mimo że konstrukcje SELinux mogą być złożone, może być przyjazny dla użytkownika. Wystarczy zainstalować pakiet setroubleshoot i przeglądać dziennik systemowy.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Zauważ, że usługę auditd należy restartować w ten sposób, a nie za pomocą systemctl, mimo obecności systemd w systemie. W dzienniku systemowym będzie wskazana nie tylko informacja o blokadzie, ale także przyczyna oraz sposób obejścia zakazu.

Wykonujemy te komendy: