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


In dieser Serie haben wir mindestens zwei Zugriffssteuerungsmethoden im Detail untersucht: Standard-ugo/rwx-Berechtigungen (Benutzer und Gruppen verwalten - Teil 3) und Zugriffssteuerungslisten (ACLs auf Dateisystemen konfigurieren - Teil 7).

Obwohl dies als Berechtigungen und Zugriffskontrollmechanismen der ersten Ebene erforderlich ist, weisen sie einige Einschränkungen auf, die von Security Enhanced Linux (kurz SELinux genannt) behoben werden.

Eine dieser Einschränkungen besteht darin, dass ein Benutzer eine Datei oder ein Verzeichnis durch einen schlecht ausgearbeiteten Befehl chmod einer Sicherheitsverletzung aussetzen und so eine unerwartete Weitergabe von Zugriffsrechten verursachen kann. Infolgedessen kann jeder von diesem Benutzer gestartete Prozess mit den Dateien des Benutzers tun, was ihm gefällt. Schließlich kann eine böswillige oder anderweitig kompromittierte Software auf Root-Ebene auf das gesamte System zugreifen.

Unter Berücksichtigung dieser Einschränkungen hat die NSA (United States National Security Agency) zunächst SELinux entwickelt, eine flexible Methode zur obligatorischen Zugriffskontrolle, um die Fähigkeit von Prozessen einzuschränken, auf Systemobjekte (wie Dateien, Verzeichnisse, Netzwerkports) zuzugreifen oder andere Vorgänge auszuführen usw.) auf das Modell mit der geringsten Berechtigung, das später nach Bedarf geändert werden kann. Mit wenigen Worten, jedes Element des Systems erhält nur den Zugriff, der für die Funktion erforderlich ist.

In RHEL 7 ist SELinux in den Kernel selbst integriert und standardmäßig im Durchsetzungsmodus aktiviert. In diesem Artikel werden die grundlegenden Konzepte von SELinux und seine Funktionsweise kurz erläutert.

SELinux-Modi

SELinux kann auf drei verschiedene Arten arbeiten:

  1. Enforcing: SELinux denies access based on SELinux policy rules, a set of guidelines that control the security engine.
  2. Permissive: SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode.
  3. Disabled (self-explanatory).

Der Befehl getenforce zeigt den aktuellen Modus von SELinux an, während setenforce (gefolgt von einer 1 oder einer 0) verwendet wird, um den Modus während des Vorgangs auf Erzwingen bzw. Zulassen zu ändern Nur aktuelle Sitzung.

Um eine Persistenz über Abmeldungen und Neustarts hinweg zu erreichen, müssen Sie die Datei /etc/selinux/config bearbeiten und die Variable SELINUX auf erzwingend, zulässig oder deaktiviert setzen:

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

In der Regel verwenden Sie setenforce, um als ersten Schritt zur Fehlerbehebung zwischen den SELinux-Modi umzuschalten (Erzwingen auf Zulässig und Zurück). Wenn SELinux derzeit auf die Durchsetzung eingestellt ist, während ein bestimmtes Problem auftritt, und dasselbe verschwindet, wenn Sie es auf "Zulässig" setzen, können Sie sicher sein, dass Sie sich mit einem Problem mit SELinux-Berechtigungen befassen.

SELinux-Kontexte

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

  1. A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
  2. The concept of role acts as an intermediary between domains and SELinux users in that it defines which process domains and file types can be accessed. This will shield your system against vulnerability to privilege escalation attacks.
  3. A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.

Sehen wir uns anhand der folgenden Beispiele an, wie das alles funktioniert.

In Securing SSH - Part 8 haben wir erklärt, dass das Ändern des Standardports, an dem sshd abhört, eine der ersten Sicherheitsmaßnahmen ist, um Ihren Server vor externen Angriffen zu schützen. Bearbeiten Sie die Datei /etc/ssh/sshd_config und setzen Sie 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 an, dass sshd die Berechtigung zum Starten an Port 9999 verweigert wurde (SELinux-Protokollnachrichten enthalten das Wort „AVC“, damit sie leicht identifiziert werden können aus anderen Nachrichten), da dies ein reservierter Port für den JBoss Management-Dienst ist:

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

Zu diesem Zeitpunkt können Sie SELinux deaktivieren (aber nicht!), Wie bereits erläutert, und versuchen, sshd erneut zu starten. Dies sollte funktionieren. Das Semanage-Dienstprogramm kann uns jedoch mitteilen, was wir ändern müssen, damit wir sshd an jedem von uns ausgewählten Port ohne Probleme starten können.

Lauf,

# semanage port -l | grep ssh

um eine Liste der Ports zu erhalten, an denen SELinux sshd abhören lässt.

Ändern Sie also den Port in /etc/ssh/sshd_config in Port 9998, fügen Sie den Port dem Kontext ssh_port_t hinzu und starten Sie den Dienst neu:

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

Wie Sie sehen, wurde der Dienst diesmal erfolgreich gestartet. Dieses Beispiel zeigt, dass SELinux die TCP-Portnummer anhand seiner internen Definitionen für den eigenen Porttyp steuert.

Dies ist ein Beispiel für die Verwaltung eines Prozesses durch SELinux, der auf einen anderen Prozess zugreift. Wenn Sie mod_security und mod_evasive zusammen mit Apache auf Ihrem RHEL 7-Server implementieren möchten, 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 über Neustarts hinweg dauerhaft bleibt.

# 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, sind SELinux-Boolesche Einstellungen (oder nur Boolesche Werte) wahre/falsche Regeln, die in SELinux-Richtlinien eingebettet sind. Sie können alle Booleschen Werte mit semanage boolean -l auflisten und alternativ an grep weiterleiten, um die Ausgabe zu filtern.

Angenommen, Sie bedienen eine statische Website in einem anderen Verzeichnis als dem Standardverzeichnis (/var/www/html ), z. B./sites (dies kann der Fall sein, wenn Sie Ihre Webdateien in einem Verzeichnis speichern) z. B. freigegebenes Netzwerklaufwerk und muss unter/sites bereitgestellt werden).

ein). Erstellen Sie eine index.html-Datei in/sites mit den folgenden Inhalten:

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

Wenn Sie tun,

# ls -lZ /websites/index.html

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

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

c). Navigieren Sie zu http:/ , und Sie sollten eine 503 Forbidden HTTP-Antwort erhalten.

d). Ändern Sie als Nächstes die Bezeichnung/Websites rekursiv in den Typ httpd_sys_content_t, um Apache schreibgeschützten Zugriff auf dieses Verzeichnis und dessen 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:/ . Die HTML-Datei wird dann korrekt angezeigt:

Zusammenfassung

In diesem Artikel haben wir die Grundlagen von SELinux durchgearbeitet. Beachten Sie, dass aufgrund der Größe des Themas eine ausführliche Erläuterung in einem einzelnen Artikel nicht möglich ist. Wir sind jedoch der Ansicht, dass die in diesem Handbuch beschriebenen Grundsätze Ihnen helfen werden, zu fortgeschritteneren Themen überzugehen, falls Sie dies wünschen.

Wenn ich darf, empfehle ich zunächst zwei wichtige Ressourcen: die NSA SELinux-Seite und das RHEL 7 SELinux-Benutzer- und Administratorhandbuch.

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