Wyszukiwanie w witrynie

Wdrażanie obowiązkowej kontroli dostępu za pomocą SELinux lub AppArmor w systemie Linux


Aby pokonać ograniczenia i zwiększyć mechanizmy bezpieczeństwa zapewniane przez standardowe uprawnienia ugo/rwx i listy kontroli dostępu, Agencja Bezpieczeństwa Narodowego Stanów Zjednoczonych (NSA) opracowała elastyczną Agencję Bezpieczeństwa Narodowego Stanów Zjednoczonych (NSA)Metoda obowiązkowej kontroli dostępu (MAC) znana jako SELinux (skrót od Security Enhanced Linux) w celu ograniczenia między innymi możliwości procesów uzyskiwać dostęp lub wykonywać inne operacje na obiektach systemowych (takich jak pliki, katalogi, porty sieciowe itp.) z najmniejszymi możliwymi uprawnieniami, jednocześnie umożliwiając późniejsze modyfikacje tego modelu.

Innym popularnym i powszechnie używanym MAC jest AppArmor, który oprócz funkcji udostępnianych przez SELinux zawiera tryb uczenia się, który pozwala systemowi „uczyć się ”, jak zachowuje się konkretna aplikacja oraz ustawić limity, konfigurując profile w celu bezpiecznego korzystania z aplikacji.

W CentOS 7 SELinux jest wbudowany w samo jądro i domyślnie włączony w trybie Wymuszanie (więcej na ten temat w następnej sekcji), w przeciwieństwie do openSUSE i Ubuntu, które korzystają z AppArmor.

W tym artykule wyjaśnimy podstawy SELinux i AppArmor oraz jak korzystać z jednego z tych narzędzi dla własnej korzyści, w zależności od wybranej dystrybucji.

Wprowadzenie do SELinux i jak go używać w CentOS 7

Security Enhanced Linux może działać na dwa różne sposoby:

  1. Egzekwowanie: SELinux odmawia dostępu w oparciu o zasady polityki SELinux, zestaw wytycznych kontrolujących silnik bezpieczeństwa.
  2. Zezwalający: SELinux nie odmawia dostępu, ale odmowy są rejestrowane w przypadku działań, które zostałyby odrzucone, gdyby działały w trybie wymuszania.

SELinux można również wyłączyć. Chociaż sam w sobie nie jest to tryb pracy, nadal jest to opcja. Lepiej jednak nauczyć się korzystać z tego narzędzia, niż je ignorować. Pamiętaj o tym!

Aby wyświetlić bieżący tryb SELinux, użyj getenforce. Jeśli chcesz przełączyć tryb działania, użyj setenforce 0 (aby ustawić na Permissive) lub setenforce 1 (Enforcing mocny>).

Ponieważ ta zmiana nie przetrwa ponownego uruchomienia, będziesz musiał edytować plik /etc/selinux/config i ustawić zmienną SELINUX na dowolną wymuszanie, zezwalanie lub wyłączanie w celu zapewnienia trwałości przy ponownym uruchomieniu:

Na marginesie, jeśli getenforce zwróci Disabled, będziesz musiał edytować /etc/selinux/config, ustawiając żądany tryb działania i zrestartować komputer. W przeciwnym razie nie będzie można ustawić (ani przełączyć) trybu działania za pomocą setenforce.

Jedno z typowych zastosowań setenforce polega na przełączaniu pomiędzy trybami SELinux (od wymuszającego do zezwalającego lub na odwrót) w celu rozwiązywania problemów z aplikacją, która zachowuje się niewłaściwie lub nie działa zgodnie z oczekiwaniami. Jeśli to zadziała po ustawieniu SELinux w tryb Permissive, możesz mieć pewność, że masz do czynienia z problemem z uprawnieniami SELinux.

Dwa klasyczne przypadki, w których najprawdopodobniej będziemy mieli do czynienia z SELinuxem to:

  1. Zmiana domyślnego portu, na którym nasłuchuje demon.
  2. Ustawianie dyrektywy DocumentRoot dla hosta wirtualnego poza /var/www/html.

Przyjrzyjmy się tym dwóm przypadkom na poniższych przykładach.

PRZYKŁAD 1: Zmiana domyślnego portu dla demona sshd

Jedną z pierwszych rzeczy, które większość administratorów systemów robi w celu zabezpieczenia swoich serwerów, jest zmiana portu, na którym nasłuchuje demon SSH, głównie w celu zniechęcenia skanerów portów i zewnętrznych atakujących. Aby to zrobić, używamy dyrektywy Port w /etc/ssh/sshd_config, a następnie nowego numeru portu w następujący sposób (w tym przypadku użyjemy portu 9999):


Port 9999

Po próbie ponownego uruchomienia usługi i sprawdzeniu jej statusu zobaczymy, że nie udało się uruchomić:


systemctl restart sshd
systemctl status sshd

Jeśli przyjrzymy się /var/log/audit/audit.log, zobaczymy, że sshd nie mógł uruchomić się na porcie 9999 przez SELinux, ponieważ jest to port zarezerwowany dla usługi JBoss Management (komunikaty dziennika SELinux zawierają słowo „AVC”, dzięki czemu można je łatwo zidentyfikowane na podstawie innych wiadomości):


cat /var/log/audit/audit.log | grep AVC | tail -1

W tym momencie większość ludzi prawdopodobnie wyłączyłaby SELinux, ale my tego nie zrobimy. Zobaczymy, że istnieje sposób, aby SELinux i sshd nasłuchujące na innym porcie mogły żyć razem w harmonii. Upewnij się, że masz zainstalowany i uruchomiony pakiet policycoreutils-python:


yum install policycoreutils-python

Aby wyświetlić listę portów, na których SELinux pozwala na nasłuchiwanie sshd. Na poniższym obrazku widzimy również, że port 9999 był zarezerwowany dla innej usługi i dlatego na razie nie możemy go użyć do uruchomienia innej usługi:


semanage port -l | grep ssh

Oczywiście moglibyśmy wybrać inny port dla SSH, ale jeśli mamy pewność, że nie będziemy musieli używać tej konkretnej maszyny do jakichkolwiek usług związanych z JBoss, możemy wówczas zmodyfikować istniejącą regułę SELinux i zamiast tego przypisać ten port do SSH:


semanage port -m -t ssh_port_t -p tcp 9999

Następnie możemy użyć pierwszego polecenia semanage, aby sprawdzić, czy port został poprawnie przypisany, lub opcji -lC (skrót od list niestandardowe):


semanage port -lC
semanage port -l | grep ssh

Możemy teraz ponownie uruchomić SSH i połączyć się z usługą za pomocą portu 9999. Należy pamiętać, że ta zmiana przetrwa ponowne uruchomienie.

PRZYKŁAD 2: Wybór DocumentRoot poza /var/www/html dla hosta wirtualnego

Jeśli musisz skonfigurować wirtualnego hosta Apache przy użyciu katalogu innego niż /var/www/html jako DocumentRoot (powiedzmy na przykład /websrv/sites /gabriel/public_html):


DocumentRoot “/websrv/sites/gabriel/public_html”

Apache odmówi udostępnienia treści, ponieważ plik index.html został oznaczony etykietą typu default_t SELinux, do którego Apache nie ma dostępu:


wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html

Podobnie jak w poprzednim przykładzie, możesz użyć następującego polecenia, aby sprawdzić, czy rzeczywiście jest to problem związany z SELinux:


cat /var/log/audit/audit.log | grep AVC | tail -1

Aby zmienić etykietę /websrv/sites/gabriel/public_html rekurencyjnie na httpd_sys_content_t, wykonaj:


semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

Powyższe polecenie przyzna Apache'owi dostęp tylko do odczytu do tego katalogu i jego zawartości.

Na koniec, aby zastosować zasadę (i natychmiastowo wprowadzić zmianę etykiety), wykonaj:


restorecon -R -v /websrv/sites/gabriel/public_html

Teraz powinieneś mieć dostęp do katalogu:


wget http://localhost/index.html

Aby uzyskać więcej informacji na temat SELinux, zobacz Fedora 22 SELinux i podręcznik administratora.