Jedną z przyczyn ogromnego sukcesu systemu operacyjnego Linux na wbudowanych, mobilnych urządzeniach i serwerach jest dość wysoki stopień bezpieczeństwa jądra, powiązanych usług i aplikacji. Ale jeśli do architektury jądra Linuksa, to nie da się w nim znaleźć kwadratu odpowiedzialnego za bezpieczeństwo jako takie. Gdzie kryje się podsystem bezpieczeństwa Linuksa i z czego się składa?
Informacje o modułach bezpieczeństwa systemu Linux i SELinux
Security Enhanced Linux to zestaw reguł i mechanizmów dostępu opartych na obowiązkowych i opartych na rolach modeli dostępu, mających na celu ochronę systemów Linux przed potencjalnymi zagrożeniami i korygowanie niedociągnięć Discretionary Access Control (DAC), tradycyjnego systemu bezpieczeństwa Uniksa. Projekt powstał w głębi amerykańskiej Agencji Bezpieczeństwa Narodowego i został bezpośrednio opracowany głównie przez wykonawców Secure Computing Corporation i MITER, a także szereg laboratoriów badawczych.
Moduły bezpieczeństwa Linux
Linus Torvalds poczynił szereg komentarzy na temat nowych rozwiązań NSA, które miały zostać włączone do głównego jądra Linuksa. Opisał ogólne środowisko z zestawem przechwytywaczy do kontrolowania operacji na obiektach i zestawem pewnych pól ochronnych w strukturach danych jądra do przechowywania odpowiednich atrybutów. To środowisko może być następnie wykorzystane przez ładowalne moduły jądra do wdrożenia dowolnego pożądanego modelu bezpieczeństwa. LSM w pełni wszedł do jądra Linuksa v2.6 w 2003 roku.
Struktura LSM obejmuje pola ochronne w strukturach danych i wywołania funkcji przechwytujących w krytycznych punktach kodu jądra w celu manipulowania nimi i przeprowadzania kontroli dostępu. Dodaje także funkcjonalność rejestracji modułów bezpieczeństwa. Interfejs /sys/kernel/security/lsm zawiera listę aktywnych modułów w systemie. Haki LSM są przechowywane na listach, które są wywoływane w kolejności określonej w CONFIG_LSM. Szczegółowa dokumentacja dotycząca hooków znajduje się w pliku nagłówkowym include/linux/lsm_hooks.h.
Podsystem LSM umożliwił pełną integrację SELinuksa z tą samą wersją stabilnego jądra Linuksa v2.6. Niemal natychmiast SELinux stał się de facto standardem bezpiecznego środowiska Linux i znalazł się w najpopularniejszych dystrybucjach: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.
Słowniczek SELinuksa
- Tożsamość — Użytkownik SELinux nie jest tym samym, co zwykły identyfikator użytkownika Unix/Linux; mogą współistnieć w tym samym systemie, ale zasadniczo są zupełnie inni. Każde standardowe konto Linux może odpowiadać jednemu lub większej liczbie kont w SELinux. Tożsamość SELinux jest częścią ogólnego kontekstu bezpieczeństwa, który określa, do których domen możesz, a do których nie możesz dołączyć.
- Domeny - W SELinux domena jest kontekstem wykonania podmiotu, czyli procesu. Domena bezpośrednio określa dostęp, jaki ma proces. Domena to w zasadzie lista tego, co mogą zrobić procesy lub co proces może zrobić z różnymi typami. Niektóre przykłady domen to sysadm_t do administrowania systemem i user_t, który jest zwykłą domeną nieuprzywilejowanego użytkownika. System init działa w domenie init_t, a nazwany proces działa w domenie o nazwie_t.
- Role — Co służy jako pośrednik pomiędzy domenami a użytkownikami SELinux. Role określają, do jakich domen użytkownik może należeć i do jakich typów obiektów może uzyskać dostęp. Ten mechanizm kontroli dostępu zapobiega groźbie ataków polegających na eskalacji uprawnień. Role są wpisane w model bezpieczeństwa kontroli dostępu oparty na rolach (RBAC) używany w SELinux.
- Typy — Atrybut listy wymuszania typu przypisany do obiektu i określający, kto może uzyskać do niego dostęp. Podobna do definicji domeny, z tą różnicą, że domena dotyczy procesu, a typ odnosi się do obiektów takich jak katalogi, pliki, gniazda itp.
- Podmioty i przedmioty - Procesy są podmiotami i działają w określonym kontekście lub domenie bezpieczeństwa. Zasoby systemu operacyjnego: pliki, katalogi, gniazda itp. to obiekty, którym przypisany jest określony typ, czyli poziom prywatności.
- Zasady SELinuksa — SELinux wykorzystuje różnorodne polityki w celu ochrony systemu. Polityka SELinux definiuje dostęp użytkowników do ról, ról do domen i domen do typów. W pierwszej kolejności użytkownik uzyskuje uprawnienia do uzyskania roli, następnie rola uzyskuje dostęp do domen. Wreszcie domena może mieć dostęp tylko do określonych typów obiektów.
Architektura LSM i SELinux
Pomimo nazwy, moduły LSM na ogół nie są ładowalnymi modułami systemu Linux. Jednakże, podobnie jak SELinux, jest on bezpośrednio zintegrowany z jądrem. Jakakolwiek zmiana w kodzie źródłowym 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 to włączyć za pomocą opcji bootloadera systemu operacyjnego.
Stos kontroli LSM
LSM jest wyposażony w zaczepy w podstawowych funkcjach jądra, które mogą być istotne przy sprawdzaniu. Jedną z głównych cech LSM jest to, że są one ułożone w stosy. Zatem nadal przeprowadzane są standardowe kontrole, a każda warstwa LSM dodaje jedynie dodatkowe kontrole i kontrole. Oznacza to, że zakazu nie można cofnąć. Pokazano to na rysunku: jeśli wynik rutynowych kontroli DAC zakończy się niepowodzeniem, sprawa nie dotrze nawet do zaczepów LSM.
SELinux wykorzystuje architekturę bezpieczeństwa Flask z badawczego systemu operacyjnego Fluke, w szczególności zasadę najmniejszych uprawnień. Istotą tej koncepcji, jak sama nazwa wskazuje, jest nadanie użytkownikowi lub procesowi jedynie tych uprawnień, które są niezbędne do realizacji zamierzonych działań. Zasada ta jest realizowana poprzez wpisywanie z wymuszonym dostępem, stąd kontrola dostępu w SELinux opiera się na modelu domeny => typu.
Dzięki wymuszonemu typowaniu dostępu SELinux ma znacznie większe możliwości kontroli dostępu niż tradycyjny model DAC stosowany w systemach operacyjnych Unix/Linux. Można na przykład ograniczyć numer portu sieciowego, z którym będzie się łączył serwer FTP, pozwolić na zapisywanie i zmienianie plików w określonym folderze, ale bez ich usuwania.
Główne komponenty SELinux to:
- Serwer egzekwowania zasad — Główny mechanizm organizacji kontroli dostępu.
- Baza danych zasad bezpieczeństwa systemu.
- Interakcja z przechwytywaczem zdarzeń LSM.
- Selinuxfs - Pseudo-FS, taki sam jak /proc i zamontowany w /sys/fs/selinux. Dynamicznie wypełniane przez jądro Linuksa w czasie wykonywania i zawierające pliki zawierające informacje o stanie SELinux.
- Uzyskaj dostęp do pamięci podręcznej wektorów — Pomocniczy mechanizm zwiększania produktywności.
Jak działa SELinux
To wszystko działa w ten sposób.
- Określony podmiot, w terminologii SELinux, wykonuje dozwoloną akcję na obiekcie po sprawdzeniu DAC, jak pokazano na górnym obrazku. To żądanie wykonania operacji trafia do przechwytywacza zdarzeń LSM.
- Stamtąd żądanie wraz z kontekstem bezpieczeństwa podmiotu i obiektu jest przekazywane do modułu SELinux Abstraction and Hook Logic, który jest odpowiedzialny za interakcję z LSM.
- Organem decyzyjnym w sprawie dostępu podmiotu do obiektu jest Policy Enforcement Server, który otrzymuje dane z SELinux AnHL.
- Aby podjąć decyzję o dostępie lub odmowie, serwer Policy Enforcement Server korzysta z podsystemu buforowania Access Vector Cache (AVC) w celu uzyskania najczęściej używanych reguł.
- Jeśli w pamięci podręcznej nie zostanie znalezione rozwiązanie dla odpowiedniej reguły, żądanie przekazywane jest do bazy danych polityk bezpieczeństwa.
- Wynik wyszukiwania z bazy danych i AVC jest zwracany do serwera Policy Enforcement Server.
- Jeśli znaleziona zasada pasuje do żądanej akcji, operacja jest dozwolona. W przeciwnym razie operacja jest zabroniona.
Zarządzanie ustawieniami SELinux
SELinux działa w jednym z trzech trybów:
- Egzekwowanie — ścisłe przestrzeganie zasad bezpieczeństwa.
- Zezwalający - Dozwolone jest naruszenie ograniczeń, o czym zapisuje się odpowiednią notatkę w dzienniku.
- Wyłączone — zasady bezpieczeństwa nie obowiązują.
Możesz zobaczyć, w jakim trybie znajduje się SELinux, za pomocą następującego polecenia.
[admin@server ~]$ getenforce
PermissiveZmiana trybu przed ponownym uruchomieniem, na przykład ustawienie go na wymuszanie lub 1. Parametr permissive odpowiada kodowi numerycznemu 0.
[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое
Tryb możesz także zmienić edytując plik:
[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=enforcing
# 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=cel
Różnica w przypadku setenfoce polega na tym, że po uruchomieniu systemu operacyjnego tryb SELinux zostanie ustawiony zgodnie z wartością parametru SELINUX w pliku konfiguracyjnym. Ponadto zmiany w wymuszaniu <=> wyłączone zaczynają obowiązywać dopiero po edycji pliku /etc/selinux/config i po ponownym uruchomieniu.
Zobacz krótki raport o stanie:
[admin@server ~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 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 httpdW porównaniu do normalnego wyjścia ls -l, istnieje kilka dodatkowych pól w następującym formacie:
<user>:<role>:<type>:<level>
Ostatnie pole oznacza coś w rodzaju klauzuli bezpieczeństwa i składa się z kombinacji dwóch elementów:
- s0 – istotność, zapisana także jako przedział niskiego poziomu – wysokiego poziomu
- c0, c1… c1023 - kategoria.
Zmiana konfiguracji dostępu
Użyj semodule, aby załadować, dodać i usunąć moduły SELinux.
[admin@server ~]$ semodule -l |wc -l #список всех модулей
408
[admin@server ~]$ semodule -e abrt #enable - активировать модуль
[admin@server ~]$ semodule -d accountsd #disable - отключить модуль
[admin@server ~]$ semodule -r avahi #remove - удалить модульPierwszy zespół zarządzaj logowaniem łączy użytkownika SELinux z użytkownikiem systemu operacyjnego, drugi wyświetla listę. Na koniec ostatnie polecenie z przełącznikiem -r usuwa mapowanie użytkowników SELinux na konta systemu operacyjnego. Wyjaśnienie składni wartości zakresu MLS/MCS znajduje się w poprzedniej sekcji.
[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__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ół użytkownik zarządzający używany do zarządzania mapowaniami pomiędzy użytkownikami i 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_uParametry polecenia:
- -a dodaj wpis niestandardowego mapowania ról;
- -l lista pasujących użytkowników i ról;
- -d usuń wpis dotyczący mapowania ról użytkownika;
- -R lista ról przypisanych do użytkownika;
Pliki, porty i wartości logiczne
Każdy moduł SELinux zapewnia zestaw reguł oznaczania plików, ale w razie potrzeby możesz także dodać własne reguły. Na przykład chcemy, aby serwer WWW miał 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 zasady oznaczania, a druga resetuje, a raczej ustawia typy plików zgodnie z obowiązującymi regułami.
Podobnie porty TCP/UDP są oznaczone w taki sposób, że tylko odpowiednie usługi mogą na nich nasłuchiwać. Na przykład, aby serwer WWW nasłuchiwał na porcie 8080, musisz uruchomić polecenie.
[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080Znaczna liczba modułów SELinux ma parametry, które mogą przyjmować wartości logiczne. Całą listę takich parametrów można zobaczyć za pomocą getsebool -a. Możesz zmienić wartości logiczne 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
Warsztat, uzyskaj dostęp do interfejsu internetowego Pgadmin
Spójrzmy na praktyczny przykład: zainstalowaliśmy pgadmin7.6-web na RHEL 4 w celu administrowania bazą danych PostgreSQL. Poszliśmy trochę z ustawieniami pg_hba.conf, postgresql.conf i config_local.py, ustaw uprawnienia do folderów, zainstaluj brakujące moduły Pythona z pip. Wszystko gotowe, uruchamiamy i odbieramy 500 wewnętrzny błąd serwera.
Zaczynamy od typowych podejrzanych, sprawdzając /var/log/httpd/error_log. Jest tam kilka ciekawych wpisów.
[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
...
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.
W tym momencie większość administratorów Linuksa będzie miała silną pokusę uruchomienia setencorce 0 i to będzie koniec. Szczerze mówiąc, właśnie to zrobiłem za pierwszym razem. Jest to oczywiście również wyjście, ale dalekie od najlepszego.
Pomimo uciążliwych projektów, SELinux może być przyjazny dla użytkownika. Wystarczy zainstalować pakiet setroubleshoot i wyświetlić dziennik systemowy.
[admin@server ~]$ yum install setroubleshoot
[admin@server ~]$ journalctl -b -0
[admin@server ~]$ service restart auditd
Należy pamiętać, że usługę audytu należy uruchomić ponownie w ten sposób, a nie przy użyciu systemctl, pomimo obecności systemd w systemie operacyjnym. W dzienniku systemowym zostanie wskazany nie tylko fakt zablokowania, ale także powód i sposób na ominięcie zakazu.
Wykonujemy następujące polecenia:
[admin@server ~]$ setsebool -P httpd_can_network_connect 1
[admin@server ~]$ setsebool -P httpd_can_network_connect_db 1
Sprawdzamy dostęp do strony WWW pgadmin4, wszystko działa.
Źródło: www.habr.com