RHCSA-Serie: Grundlagen der obligatorischen Zugriffskontrolle mit SELinux in RHEL 7 - Teil 13

In dieser Serie haben wir mindestens zwei Zugriffskontrollmethoden im Detail untersucht: Standard-ugo/rwx-Berechtigungen (Benutzer und Gruppen verwalten – Teil 3) und Zugriffskontrolllisten (Konfigurieren von ACLs auf Dateisystemen – Teil 7).

Obwohl sie als First-Level-Berechtigungen und Zugriffskontrollmechanismen notwendig sind, haben sie einige Einschränkungen, die von Security Enhanced Linux (kurz SELinux) behoben werden.

Eine dieser Einschränkungen besteht darin, dass ein Benutzer eine Datei oder ein Verzeichnis durch einen schlecht ausgearbeiteten chmod-Befehl einer Sicherheitsverletzung aussetzen und so eine unerwartete Weitergabe von Zugriffsrechten verursachen kann. Infolgedessen kann jeder Prozess, der von diesem Benutzer gestartet wird, mit den Dateien, die dem Benutzer gehören, tun, was er will, und schließlich kann eine bösartige oder anderweitig kompromittierte Software Root-Level-Zugriff auf das gesamte System erhalten.

Unter Berücksichtigung dieser Einschränkungen hat die National Security Agency (NSA) der Vereinigten Staaten zunächst SELinux entwickelt, eine flexible obligatorische Zugriffskontrollmethode, um die Fähigkeit von Prozessen, auf Systemobjekte (wie Dateien, Verzeichnisse, Netzwerkports usw.) zuzugreifen oder andere Vorgänge daran auszuführen, auf das Modell mit den geringsten Berechtigungen zu beschränken, das später bei Bedarf geändert werden kann. In wenigen Worten, jedes Element des Systems erhält nur den Zugriff, der zum Funktionieren erforderlich ist.

In RHEL 7 ist SELinux in den Kernel selbst integriert und standardmäßig im Erzwingungsmodus aktiviert. In diesem Artikel werden wir kurz die grundlegenden Konzepte im Zusammenhang mit SELinux und seiner Funktionsweise erläutern.

SELinux-Modi

SELinux kann auf drei verschiedene Arten funktionieren:

1. Erzwingung: SELinux verweigert den Zugriff basierend auf SELinux-Richtlinienregeln, einer Reihe von Richtlinien, die die Sicherheits-Engine steuern.
2. Zulässig: SELinux verweigert den Zugriff nicht, aber Verweigerungen werden für Aktionen protokolliert, die im Erzwingungsmodus verweigert worden wären.
3. Behindert (selbsterklärend).

Der Befehl getenforce zeigt den aktuellen Modus von SELinux an, während setenforce (gefolgt von einer 1 oder 0) verwendet wird, um den Modus nur während der aktuellen Sitzung in Enforcing bzw. Permissive zu ändern.

Um Persistenz über Abmeldungen und Neustarts hinweg zu erreichen, müssen Sie die Datei /etc/selinux/config bearbeiten und die Variable SELINUX entweder auf enforceing, permissive oder disabled setzen:

# getenforce
setenforce 0
getenforce
setenforce 1
getenforce
cat /etc/selinux/config

In der Regel verwenden Sie setenforce, um zwischen SELinux-Modi umzuschalten (Erzwingen auf permissive und zurück) als ersten Schritt zur Fehlerbehebung. Wenn SELinux derzeit so eingestellt ist, dass es erzwungen wird, während ein bestimmtes Problem auftritt, und das Gleiche verschwindet, wenn Sie es auf permissive setzen, können Sie sicher sein, dass es sich um ein SELinux-Berechtigungsproblem handelt.

SELinux-Kontexte

Ein SELinux-Kontext besteht aus einer Zugriffskontrollumgebung, in der Entscheidungen auf der Grundlage von SELinux-Benutzer, -Rolle und -Typ (und optional einer Ebene) getroffen werden:

1. Ein SELinux-Benutzer ergänzt ein reguläres Linux-Benutzerkonto, indem er es einem SELinux-Benutzerkonto zuordnet, das wiederum im SELinux-Kontext für Prozesse in dieser Sitzung verwendet wird, um deren zulässige Rollen und Ebenen explizit zu definieren.
2. Das Konzept der Rolle fungiert als Vermittler zwischen Domänen und SELinux-Benutzern, indem es definiert, auf welche Prozessdomänen und Dateitypen zugegriffen werden kann. Dies schützt Ihr System vor Anfälligkeit für Privilege-Escalation-Angriffe.
3. Ein Typ definiert einen SELinux-Dateityp oder eine SELinux-Prozessdomäne. Unter normalen Umständen wird verhindert, dass Prozesse auf Dateien zugreifen, die von anderen Prozessen verwendet werden, und dass sie auf andere Prozesse zugreifen können, daher ist der Zugriff nur erlaubt, wenn eine bestimmte SELinux-Richtlinienregel vorhanden ist, die dies zulässt.

Sehen wir uns anhand der folgenden Beispiele an, wie all dies funktioniert.

BEISPIEL 1: Ändern des Standardports für den sshd-Daemon

In Securing SSH – Part 8 haben wir erklärt, dass das Ändern des Standardports, auf dem sshd lauscht, eine der ersten Sicherheitsmaßnahmen ist, um Ihren Server vor externen Angriffen zu schützen. Bearbeiten wir die Datei /etc/ssh/sshd_config und setzen den Port auf 9999:

Port 9999

Speichern Sie die Änderungen, und starten Sie sshd neu:

# systemctl restart sshd
systemctl status sshd

Wie Sie sehen können, konnte sshd nicht gestartet werden. Aber was ist passiert?

Eine schnelle Überprüfung von /var/log/audit/audit.log zeigt, dass sshd die Berechtigung zum Starten auf Port 9999 verweigert wurde (SELinux-Protokollnachrichten enthalten das Wort "AVC", damit sie anhand anderer Nachrichten leicht identifiziert werden können), da dies ein reservierter Port für den JBoss-Verwaltungsdienst ist:

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

An dieser Stelle könnten Sie SELinux deaktivieren (tun es aber nicht!), wie zuvor erklärt, und versuchen, sshd erneut zu starten, und es sollte funktionieren. Das semanage-Dienstprogramm kann uns jedoch sagen, was wir ändern müssen, damit wir sshd an einem beliebigen Port ohne Probleme starten können.

Laufen

# semanage port -l | grep ssh

, um eine Liste der Ports zu erhalten, an denen SELinux das Abhören von sshd zulässt.

Ändern wir also den Port in /etc/ssh/sshd_config auf Port 9998, fügen den Port zum ssh_port_t Kontext hinzu und starten dann den Dienst neu:

# semanage port -a -t ssh_port_t -p tcp 9998
systemctl restart sshd
systemctl is-active sshd

Wie Sie sehen können, wurde der Dienst dieses Mal erfolgreich gestartet. Dieses Beispiel verdeutlicht die Tatsache, dass SELinux die TCP-Portnummer auf seine eigenen internen Porttypdefinitionen steuert.

BEISPIEL 2: Zulassen, dass httpd Zugriff auf sendmail sendet

Dies ist ein Beispiel dafür, wie SELinux einen Prozess verwaltet, der auf einen anderen Prozess zugreift. Wenn Sie mod_security und mod_evasive zusammen mit Apache auf Ihrem RHEL 7-Server implementieren, müssen Sie httpd den Zugriff auf sendmail erlauben, um nach einem (D)DoS-Angriff eine E-Mail-Benachrichtigung zu senden. Lassen Sie im folgenden Befehl das Flag -P weg, wenn Sie nicht möchten, dass die Änderung nach einem Neustart beibehalten wird.

# semanage boolean -1 | grep httpd_can_sendmail
setsebool -P httpd_can_sendmail 1
semanage boolean -1 | grep httpd_can_sendmail

Wie Sie dem obigen Beispiel entnehmen können, handelt es sich bei booleschen SELinux-Einstellungen (oder nur booleschen Werten) um Wahr/Falsch-Regeln, die in SELinux-Richtlinien eingebettet sind. Sie können alle booleschen Werte mit semanage boolean -l auflisten und alternativ an grep übergeben, um die Ausgabe zu filtern.

BEISPIEL 3: Bereitstellen einer statischen Site aus einem anderen Verzeichnis als dem Standardverzeichnis

Angenommen, Sie stellen eine statische Website mit einem anderen Verzeichnis als dem Standardverzeichnis (/var/www/html) bereit, z. B. /websites (dies könnte der Fall sein, wenn Sie Ihre Webdateien beispielsweise auf einem freigegebenen Netzlaufwerk speichern und sie unter /websites bereitstellen müssen).

a). Erstellen Sie eine index.html Datei in /websites mit folgendem Inhalt:

<html>
<h2>SELinux test</h2>
</html>

Wenn ja,

# ls -lZ /websites/index.html

Sie werden sehen, dass die index.html Datei mit dem Typ default_t SELinux gekennzeichnet wurde, auf den Apache nicht zugreifen kann:

b). Ändern Sie die DocumentRoot-Direktive in /etc/httpd/conf/httpd.conf in /websites und vergessen Sie nicht, den entsprechenden Verzeichnisblock zu aktualisieren. Starten Sie dann Apache neu.

c). Navigieren Sie zu http://<Webserver-IP-Adresse>, und Sie sollten eine 503 Forbidden HTTP-Antwort erhalten.

d). Ändern Sie als Nächstes die Bezeichnung von /websites rekursiv in den Typ httpd_sys_content_t, um Apache schreibgeschützten Zugriff auf dieses Verzeichnis und seinen Inhalt zu gewähren:

# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Wenden Sie abschließend die in d erstellte SELinux-Richtlinie an:

# restorecon -R -v /websites

Starten Sie nun Apache neu und navigieren Sie erneut zu http://<Webserver-IP-Adresse> und Sie sehen die HTML-Datei korrekt angezeigt:

Zusammenfassung

In diesem Artikel haben wir die Grundlagen von SELinux erläutert. Beachten Sie, dass aufgrund des Umfangs des Themas eine vollständige, detaillierte Erklärung in einem einzigen Artikel nicht möglich ist, aber wir glauben, dass die in diesem Leitfaden beschriebenen Prinzipien Ihnen helfen werden, zu fortgeschritteneren Themen überzugehen, wenn Sie dies wünschen.

Wenn Sie gestatten, möchte ich Ihnen zunächst zwei wichtige Ressourcen empfehlen: die NSA SELinux-Seite und das RHEL 7 SELinux User's and Administrator's Guide.

Zögern Sie nicht, uns mitzuteilen, wenn Sie Fragen oder Kommentare haben.