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


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

SELinux – kontrola sieci

Data publikacji: 26-06-2017 Autor: Grzegorz Kuczyński

Poziom ochrony systemów oferowany przez mechanizm bezpieczeństwa SELinux jest bardzo wysoki. Celem, jaki założyli sobie twórcy tego modułu, było spełnienie kryteriów często określanych jako Trusted System. W drugiej części artykułu skupiamy się m.in. na kontroli pakietów, możliwościach mechanizmu SECMARK i konfiguracji protokołu IPSec.

Głównym zadaniem polityki SELinux jest separacja procesów. Mechanizm ten ma bardzo rozbudowane możliwości wymuszonej kontroli (Mandatory Access Controls) w systemie operacyjnym. W jego architekturze podmiotem wykonującym działania zazwyczaj jest proces lub jądro systemu. Nawet jeżeli systemowe operacje będą wykonywane przez użytkownika, to i tak w systemie będzie reprezentował go proces (np. bash). SELinux przed każdym zadaniem sprawdza, czy dany proces ma prawo wykonywać określone operacje na docelowym obiekcie. Obiektem tym może być nie tylko zasób systemu, taki jak plik, ale kontrola może dotyczyć również interakcji z innymi procesami. Z uwagi na budowę systemu operacyjnego często zdarza się, że proces inicjujący daną akcję musi zmienić domenę TE (Type Enforcement), aby móc wykonać określone zadanie. Taki mechanizm nazywa się przejściem pomiędzy domenami (Domain Transition), a SELinux ogranicza w ten sposób proces do przestrzeni systemowej opisanej w polityce danej domeny i izoluje go od innych domen TE. W zależności od polityki każda interakcja procesu z innymi elementami systemu może być kontrolowana.

> MECHANIZM SECMARK

Zadaniem mechanizmu SECMARK jest wykorzystanie możliwości frameworku netfilter do łączenia kontekstu SELinux z ruchem sieciowym. W tym przypadku chodzi głównie o pakiety, ale w ten sposób można powiązać też adres IP z interfejsem i portem. W polityce SELinux istnieje obiekt klasy packet, który reprezentuje pakiety.

Aby przekonać się, jak można wykorzystać kontrolę pakietów, musimy rozbudować politykę naszego serwera i klienta. Załóżmy, że chcemy oznaczać i odróżniać pakiety wysyłane przez serwer i klienta. W tym celu musimy zdefiniować nowe typy oraz reguły SELinux. Zacznijmy od modułu serwera, w którym musimy również zdefiniować pakiety klienta. Pamiętajmy, że do pakietów musimy odwoływać się w obu modułach, a żeby móc się do nich odwołać, to typ musi już być zdefiniowany w polityce. Dlatego w module serwera netserver.te wprowadzamy definicję typów netserver_packet_t, netclient_packet_t oraz netundef_packet_t (tym ostatnim typem pakietu będziemy oznaczać pakiety, które będą kierowane do serwera bądź klienta, ale ich źródło nie będzie pasować do znanych nadawców). Serwer otrzyma pozwolenie tylko na wysyłanie swoich pakietów i odbieranie pakietów od klientów. Należy również zezwolić na etykietowanie w iptables naszych pakietów – będzie mógł to wykonywać użytkownik root, czyli domena unconfined_t.

W celu dodania wspomnianej kontroli pakietów do modułu netserver musimy dodać poniższe zmiany:

netserver.te:

gen_require(`
...
class packet { send recv relabelto };
')
...
type netserver_packet_t;
type netclient_packet_t;
type netundef_packet_t;
allow unconfined_t netserver_packet_t:packet relabelto;
allow unconfined_t netclient_packet_t:packet relabelto;
allow unconfined_t netundef_packet_t:packet relabelto;
allow netserver_t netserver_packet_t:packet { send };
allow netserver_t netclient_packet_t:packet { recv };

Z kolei w module netclient dodajemy tylko reguły pozwalające klientowi wysyłać pakiety własnego typu i odbierać pakiety serwera. Wymaga to dodania następujących reguł:
netclient.te:

gen_require(`
...
class packet { send recv };
')
...
allow netclient_t netserver_packet_t:packet { recv };
allow netclient_t netclient_packet_t:packet { send };

Po wprowadzeniu zmian oba moduły należy ponownie przekompilować w kolejności, w jakiej zostały przedstawione. Należy zrobić to na obu hostach – serwera i klienta. Teraz pozostaje nadać pakietom odpowiednie etykiety, na co zezwala nam uprawnienie relabelto klasy packet. Oznaczenie pakietów wykonujemy w specjalnie przeznaczonej do tego tabeli iptables zwanej security. Zdefiniujemy w niej trzy łańcuchy – oddzielny na pakiety przychodzące i wysyłane ze znanych adresów oraz na pakiety z nieznanych hostów.

[...]

Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog nt. systemu GNU/Linux.

Artykuł pochodzi z miesięcznika: IT Professional

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"