Verwendung von SELinux

Die standardmäßige Zugriffsrichtlinie, die auf Benutzer-, Gruppen- und anderen Berechtigungen basiert und als Discretionary Access Control (DAC) bekannt ist, ermöglicht es Systemadministratoren nicht, umfassende und fein abgestimmte Sicherheitsrichtlinien zu erstellen, wie etwa die Beschränkung bestimmter Anwendungen auf die ausschließliche Anzeige von Protokolldateien. Gleichzeitig können andere Anwendungen neue Daten an die Protokolldateien anhängen.

Security Enhanced Linux (SELinux) implementiert Mandatory Access Control (MAC). Jeder Prozess und jede Systemressource verfügt über ein spezielles Sicherheitsetikett, das als SELinux-Kontext bezeichnet wird. Ein SELinux-Kontext, manchmal auch als SELinux-Label bezeichnet, ist eine Kennung, die die Details auf Systemebene abstrahiert und sich auf die Sicherheitseigenschaften der Entität konzentriert. Dies bietet nicht nur eine konsistente Möglichkeit, Objekte in der SELinux-Richtlinie zu referenzieren, sondern beseitigt auch alle Unklarheiten, die bei anderen Identifizierungsmethoden auftreten können. Beispielsweise kann eine Datei auf einem System, das Bind-Mounts verwendet, mehrere gültige Pfadnamen haben.

Die SELinux-Richtlinie verwendet diese Kontexte in einer Reihe von Regeln, die definieren, wie Prozesse miteinander und mit den verschiedenen Systemressourcen interagieren können. Standardmäßig lässt die Richtlinie keine Interaktion zu, es sei denn, eine Regel gewährt explizit Zugriff

Die SELinux-Typinformationen sind möglicherweise die wichtigsten, wenn es um die SELinux-Richtlinie geht, da die häufigste Richtlinienregel, die die zulässigen Interaktionen zwischen Prozessen und Systemressourcen definiert, SELinux-Typen und nicht den vollständigen SELinux-Kontext verwendet.

SELinux-Typen enden mit _t. Der Typname für den Webserver lautet beispielsweise httpd_t. Der Typkontext für Dateien und Verzeichnisse, die normalerweise in /var/www/html/ zu finden sind, ist httpd_sys_content_t. Der Typkontext für Dateien und Verzeichnisse, der normalerweise in /tmp und /var/tmp/ zu finden ist, ist tmp_t. Der Typkontext für Webserver-Ports ist http_port_t.

Es gibt eine Richtlinienregel, die es Apache (dem Webserverprozess, der als httpd_t läuft) erlaubt, auf Dateien und Verzeichnisse mit einem Kontext zuzugreifen, der normalerweise in /var/www/html/ und anderen Webserververzeichnissen (httpd_sys_content_t) zu finden ist. Für Dateien, die sich normalerweise in /tmp und /var/tmp/ befinden, gibt es in der Richtlinie keine Zulassungsregel, sodass der Zugriff nicht gestattet ist. Selbst wenn Apache kompromittiert wird und ein bösartiges Skript Zugriff erhält, ist es mit SELinux immer noch nicht in der Lage, auf das Verzeichnis /tmp zuzugreifen.

Wie das vorherige Schema zeigt, erlaubt SELinux dem Apache-Prozess, der als httpd_t ausgeführt wird, den Zugriff auf das Verzeichnis /var/www/html/ und verweigert demselben Prozess den Zugriff auf das Verzeichnis /data/mysql/, da es keine Zulassungsregel für httpd_t und gibt Kontexte vom Typ mysqld_db_t. Andererseits kann der MariaDB-Prozess, der als mysqld_t ausgeführt wird, auf das Verzeichnis /data/mysql/ zugreifen, und SELinux verweigert dem Prozess mit dem Typ mysqld_t ebenfalls ordnungsgemäß den Zugriff auf das Verzeichnis /var/www/html/ mit der Bezeichnung httpd_sys_content_t.

SELinux bietet folgenden Vorteile:

SELinux ist jedoch nicht:

Die folgenden Beispiele zeigen, wie SELinux die Sicherheit erhöht:

SELinux ist ein Linux-Sicherheitsmodul (LSM), das in den Linux-Kernel integriert ist. Das SELinux-Subsystem im Kernel wird durch eine Sicherheitsrichtlinie gesteuert, die vom Administrator gesteuert und beim Booten geladen wird. Alle sicherheitsrelevanten Zugriffe auf Kernelebene auf das System werden von SELinux abgefangen und im Kontext der geladenen Sicherheitsrichtlinie untersucht. Wenn die geladene Richtlinie den Vorgang zulässt, wird sie fortgesetzt. Andernfalls wird der Vorgang blockiert und der Prozess erhält einen Fehler.

SELinux-Entscheidungen, wie z. B. das Zulassen oder Verbieten des Zugriffs, werden zwischengespeichert. Dieser Cache wird als Access Vector Cache (AVC) bezeichnet. Bei Verwendung dieser zwischengespeicherten Entscheidungen müssen SELinux-Richtlinienregeln weniger überprüft werden, was die Leistung erhöht. Denken Sie daran, dass SELinux-Richtlinienregeln keine Wirkung haben, wenn DAC-Regeln zuerst den Zugriff verweigern. Rohe Prüfmeldungen werden in /var/log/audit/audit.log protokolliert und beginnen mit der Zeichenfolge „type = AVC“.

In RHEL werden Systemdienste vom systemd-Daemon gesteuert. Systemd startet und stoppt alle Dienste und Benutzer und Prozesse kommunizieren mit systemd über das Dienstprogramm systemctl. Der systemd-Daemon kann die SELinux-Richtlinie konsultieren und die Bezeichnung des aufrufenden Prozesses sowie die Bezeichnung der Unit-Datei überprüfen, die der Aufrufer zu verwalten versucht, und dann SELinux fragen, ob dem Aufrufer der Zugriff gestattet ist oder nicht. Dieser Ansatz stärkt die Zugriffskontrolle auf kritische Systemfunktionen, zu denen das Starten und Stoppen von Systemdiensten gehört.

Der systemd-Daemon fungiert auch als SELinux Access Manager. Er ruft die Bezeichnung des Prozesses ab, der systemctl ausführt, oder des Prozesses, der eine D-Bus-Nachricht an systemd gesendet hat. Der Daemon sucht dann nach der Bezeichnung der Unit-Datei, die der Prozess konfigurieren wollte. Schließlich kann systemd Informationen vom Kernel abrufen, wenn die SELinux-Richtlinie den spezifischen Zugriff zwischen der Prozessbezeichnung und der Einheitsdateibezeichnung zulässt. Das bedeutet, dass eine kompromittierte Anwendung, die für einen bestimmten Dienst mit systemd interagieren muss, nun von SELinux eingeschränkt werden kann. Richtlinienautoren können diese fein abgestimmten Kontrollen auch nutzen, um Administratoren einzuschränken.

Wenn ein Prozess eine D-Bus-Nachricht an einen anderen Prozess sendet und die SELinux-Richtlinie die D-Bus-Kommunikation dieser beiden Prozesse nicht zulässt, gibt das System eine USER_AVC-Verweigerungsnachricht aus und die D-Bus-Kommunikation läuft ab. Man beachte, dass die D-Bus-Kommunikation zwischen zwei Prozessen bidirektional funktioniert.

RHEL 8 stellt die folgenden Pakete für die Arbeit mit SELinux bereit:

SELinux kann in einem von drei Modi ausgeführt werden:

Die Modi dtailliert:

Verwenden Sie das Dienstprogramm setenforce, um zwischen dem erzwingenden und dem permissiven Modus zu wechseln. Mit setenforce vorgenommene Änderungen bleiben bei Neustarts nicht bestehen. Um in den Erzwingungsmodus zu wechseln, geben Sie als Linux-Root-Benutzer den Befehl setenforce 1 ein. Um in den permissiven Modus zu wechseln, geben Sie den Befehl setenforce 0 ein. Verwenden Sie das Dienstprogramm getenforce, um den aktuellen SELinux-Modus anzuzeigen:

In Red Hat Enterprise Linux können Sie einzelne Domänen in den permissiven Modus versetzen, während das System im erzwingenden Modus läuft. So machen Sie beispielsweise die httpd_t-Domäne permissive:

Beachten Sie, dass freizügige Domänen ein leistungsstarkes Tool sind, das die Sicherheit Ihres Systems gefährden kann. Red Hat empfiehlt, permissive Domänen mit Vorsicht zu verwenden, beispielsweise beim Debuggen eines bestimmten Szenarios.

Wie in den SELinux -Zuständen und -Modi erläutert, kann SELinux aktiviert oder deaktiviert werden. Wenn SELinux aktiviert ist, verfügt es über zwei Modi: enforce und permissive. :w

Verwenden Sie die Befehle getenforce oder sestatus, um zu überprüfen, in welchem Modus SELinux ausgeführt wird. Der Befehl getenforce gibt Enforcing, Permissive oder Disabled zurück.

Der Befehl sestatus gibt den SELinux-Status und die verwendete SELinux-Richtlinie zurück:

Um zu verhindern, dass falsch gekennzeichnete und nicht gekennzeichnete Dateien Probleme verursachen, beschriftet SELinux Dateisysteme automatisch neu, wenn vom deaktivierten Zustand in den permissiven oder erzwingenden Modus gewechselt wird. Verwenden Sie den Befehl fixfiles -F onboot als Root, um die Datei /.autorelabel mit der Option -F zu erstellen, um sicherzustellen, dass Dateien beim nächsten Neustart neu gekennzeichnet werden.

Bevor Sie das System zum Umbenennen neu starten, stellen Sie sicher, dass das System im zulässigen Modus startet, indem Sie beispielsweise die Kernel-Option Freizeitcing = 0 verwenden. Dies verhindert, dass das System nicht startet, falls das System unbeschriftete Dateien enthält, die systemd vor dem Start des Selinux-Autorelabel-Dienstes benötigt.

Verwenden Sie das folgende Verfahren, um den SELinux-Modus dauerhaft in „permissiv“ zu ändern. Wenn SELinux im permissiven Modus ausgeführt wird, wird die SELinux-Richtlinie nicht erzwungen. Das System bleibt betriebsbereit und SELinux verweigert keine Vorgänge, sondern protokolliert nur AVC-Meldungen, die dann zur Fehlerbehebung, zum Debuggen und zur Verbesserung der SELinux-Richtlinien verwendet werden können. In diesem Fall wird jeder AVC nur einmal protokolliert.

Voraussetzungen

Vorgehensweise

Überprüfung

Bestätigen Sie nach dem Neustart des Systems, dass der Befehl getenforce Permissive zurückgibt:

Verwenden Sie das folgende Verfahren, um SELinux in den enforcings Modus zu schalten. Wenn SELinux im enforcing Modus ausgeführt wird, erzwingt es die SELinux-Richtlinie und verweigert den Zugriff basierend auf den SELinux-Richtlinienregeln. In RHEL ist der Durchsetzungsmodus standardmäßig aktiviert, wenn das System zum ersten Mal mit SELinux installiert wurde.

Vorgehensweise

Beim nächsten Start beschriftet SELinux alle Dateien und Verzeichnisse im System neu und fügt SELinux-Kontext für Dateien und Verzeichnisse hinzu, die erstellt wurden, als SELinux deaktiviert wurde.

Überprüfung

Bestätigen Sie nach dem Neustart des Systems, dass der Befehl getenforce enforcing zurückgibt:

Geben Sie alternativ bei installiertem setroubleshoot-server Paket Folgendes ein:

Wenn SELinux aktiv ist und der Audit-Daemon (auditd) nicht auf Ihrem System ausgeführt wird, suchen Sie in der Ausgabe des Befehls dmesg nach bestimmten SELinux-Meldungen:

Um Probleme zu vermeiden, z. B. dass Systeme nicht mehr starten können oder Prozessfehler auftreten, befolgen Sie dieses Verfahren, wenn Sie SELinux auf Systemen aktivieren, auf denen es zuvor deaktiviert war.

Vorgensweise

Dadurch wird die Datei /.autorelabel erstellt, die die Option -F enthält.

Überprüfung

Bestätigen Sie nach dem Neustart des Systems, dass der Befehl getenforce enforcing zurückgibt:

Verwenden Sie das folgende Verfahren, um SELinux dauerhaft zu deaktivieren.

Red Hat empfiehlt dringend, den Permissive-Modus zu verwenden, anstatt SELinux dauerhaft zu deaktivieren.

Vorgehensweise

Überprüfung

Beim Booten können Sie mehrere Kernel-Parameter festlegen, um die Art und Weise zu ändern, wie SELinux ausgeführt wird:

enforcing=0

Das Festlegen dieses Parameters führt dazu, dass das System im zulässigen Modus startet, was bei der Fehlerbehebung hilfreich ist. Wenn Ihr Dateisystem zu stark beschädigt ist, ist die Verwendung des Permissivmodus möglicherweise die einzige Möglichkeit, ein Problem zu erkennen. Darüber hinaus erstellt das System im Permissivmodus die Etiketten weiterhin korrekt. Die in diesem Modus erstellten AVC-Nachrichten können sich von denen im Erzwingungsmodus unterscheiden.

Im permissiven Modus wird nur die erste Ablehnung aus einer Reihe derselben Ablehnungen gemeldet. Im Durchsetzungsmodus erhalten Sie jedoch möglicherweise eine Ablehnung bezüglich des Lesens eines Verzeichnisses und eine Anwendung wird angehalten. Im permissiven Modus erhalten Sie dieselbe AVC-Meldung, aber die Anwendung liest weiterhin Dateien im Verzeichnis und Sie erhalten zusätzlich eine AVC für jede Ablehnung.

selinux=0

Dieser Parameter bewirkt, dass der Kernel die gesamte SELinux-Infrastruktur nicht lädt. Die Init-Skripte bemerken, dass das System mit dem Parameter „selinux = 0“ gestartet wurde, und aktualisieren die Datei /.autorelabel. Dies führt dazu, dass das System beim nächsten Start mit aktiviertem SELinux automatisch eine neue Bezeichnung vornimmt.

autorelabel=1 Dieser Parameter erzwingt eine Umbenennung durch das System, ähnlich wie bei den folgenden Befehlen:

Wenn ein Dateisystem eine große Menge falsch gekennzeichneter Objekte enthält, starten Sie das System im permissive Modus, damit der automatische Neukennzeichnungsprozess erfolgreich ist.

Jeder Linux-Benutzer wird mithilfe der SELinux-Richtlinie einem SELinux-Benutzer zugeordnet. Dadurch können Linux-Benutzer die Einschränkungen für SELinux-Benutzer übernehmen.

Um die SELinux -Benutzerzuordnung auf Ihrem System anzuzeigen, verwenden Sie den Befehl semanage login -l als Root:

In Red Hat Enterprise Linux werden Linux-Benutzer standardmäßig der SELinux-Standardanmeldung zugeordnet, die dem SELinux-Benutzer unconfined_u zugeordnet ist. Die folgende Zeile definiert die Standardzuordnung:

Eingeschränkte Benutzer (Confined users) werden durch SELinux-Regeln eingeschränkt, die explizit in der aktuellen SELinux-Richtlinie definiert sind. Uneingeschränkte (Unconfined) Benutzer unterliegen durch SELinux nur minimalen Einschränkungen.

Eingeschränkte und unbeschränkte Linux-Benutzer unterliegen Prüfungen des ausführbaren und beschreibbaren Speichers und werden auch durch MCS oder MLS eingeschränkt.

Geben Sie den folgenden Befehl ein, um die verfügbaren SELinux-Benutzer aufzulisten:

Beachten Sie, dass der Befehl seinfo vom Paket setools-console bereitgestellt wird, das nicht standardmäßig installiert ist.

Wenn ein unbeschränkter Linux-Benutzer eine Anwendung ausführt, die in der SELinux-Richtlinie als eine Anwendung definiert ist, die von der unconfined_t-Domäne zu ihrer eigenen begrenzten Domäne wechseln kann, unterliegt der unbeschränkte Linux-Benutzer weiterhin den Einschränkungen dieser begrenzten Domäne. Der Sicherheitsvorteil besteht darin, dass die Anwendung eingeschränkt bleibt, auch wenn ein Linux-Benutzer uneingeschränkt ausgeführt wird. Daher kann die Ausnutzung eines Fehlers in der Anwendung durch die Richtlinie eingeschränkt werden.

Ebenso können wir diese Prüfungen auf eingeschränkte Benutzer anwenden. Jeder eingeschränkte Benutzer ist durch eine eingeschränkte Benutzerdomäne eingeschränkt. Die SELinux-Richtlinie kann auch einen Übergang von einer begrenzten Benutzerdomäne zu einer eigenen begrenzten Zieldomäne definieren. In einem solchen Fall unterliegen eingeschränkte Benutzer den Einschränkungen dieser eingeschränkten Zieldomäne. Der Hauptpunkt besteht darin, dass den eingeschränkten Benutzern entsprechend ihrer Rolle besondere Privilegien zugeordnet sind.

In SELinux gewähren eingeschränkte Administratorrollen den ihnen zugewiesenen Linux-Benutzern bestimmte Privilegien und Berechtigungen zum Ausführen bestimmter Aufgaben. Durch die Zuweisung separater, eingeschränkter Administratorrollen können Sie die Berechtigungen über verschiedene Domänen der Systemadministration auf einzelne Benutzer aufteilen. Dies ist in Szenarios mit mehreren Administratoren nützlich, von denen jeder eine eigene Domäne hat.

SELinux verfügt über die folgenden eingeschränkten Administratorrollen:

auditadm_r

Die Audit-Administratorrolle ermöglicht die Verwaltung des Audit-Subsystems.

dbadm_r

Die Datenbankadministratorrolle ermöglicht die Verwaltung von MariaDB- und PostgreSQL-Datenbanken.

logadm_r

Die Rolle des Protokolladministrators ermöglicht die Verwaltung von Protokollen.

webadm_r

Der Webadministrator ermöglicht die Verwaltung des Apache HTTP Servers.

secadm_r

Die Rolle des Sicherheitsadministrators ermöglicht die Verwaltung der SELinux-Datenbank.

sysadm_r

Die Systemadministratorrolle ermöglicht die Ausführung aller zuvor aufgeführten Rollen und verfügt über zusätzliche Berechtigungen. In nicht standardmäßigen Konfigurationen kann die Sicherheitsverwaltung von der Systemverwaltung getrennt werden, indem das Modul sysadm_secadm in der SELinux-Richtlinie deaktiviert wird.

ZUSÄTZLICHE RESSOURCEN

Weitere Informationen zu den einzelnen Rollen und den zugehörigen Typen finden Sie auf den entsprechenden Manpages:

ZUSÄTZLICHE RESSOURCEN

Die SELinux-Richtlinie ordnet jeden Linux-Benutzer einem SELinux-Benutzer zu. Dadurch können Linux-Benutzer die Einschränkungen von SELinux-Benutzern übernehmen.

Sie können die Berechtigungen für eingeschränkte Benutzer in Ihrer SELinux-Richtlinie an spezifische Anforderungen anpassen, indem Sie boolesche Werte in der Richtlinie anpassen. Sie können den aktuellen Status dieser booleschen Werte ermitteln, indem Sie den Befehl semanage boolean -l verwenden. Um alle SELinux-Benutzer, ihre SELinux-Rollen sowie MLS/MCS-Ebenen und Bereiche aufzulisten, verwenden Sie den Befehl semanage user -l als Root.

Beachten Sie, dass system_u eine spezielle Benutzeridentität für Systemprozesse und -objekte ist und system_r die zugehörige Rolle ist. Administratoren dürfen diesen system_u-Benutzer und die system_r-Rolle niemals einem Linux-Benutzer zuordnen. Darüber hinaus sind unconfined_u und root unbeschränkte Benutzer. Aus diesen Gründen sind die diesen SELinux-Benutzern zugeordneten Rollen nicht in der folgenden Tabelle „Typen und Zugriff von SELinux-Rollen“ enthalten.

Jede SELinux-Rolle entspricht einem SELinux-Typ und stellt spezifische Zugriffsrechte bereit.

Neben den bereits erwähnten SELinux-Benutzern gibt es spezielle Rollen, die diesen Benutzern mit dem Befehl semanage user zugeordnet werden können. Diese Rollen bestimmen, was SELinux dem Benutzer erlaubt:

Um alle verfügbaren Rollen aufzulisten, geben Sie den Befehl seininfo -r ein:

Beachten Sie, dass der Befehl seinfo vom Paket setools-console bereitgestellt wird, das nicht standardmäßig installiert ist.

ZUSÄTZLICHE RESSOURCEN

Die Manpages seinfo (1), semanage-login (8) und xguest_selinux (8).

Das folgende Verfahren zeigt, wie Sie dem System einen neuen Linux-Benutzer hinzufügen. Der Benutzer wird automatisch dem SELinux-Benutzer unconfined_u zugeordnet.

Voraussetzungen

Vorgehensweise

Melden Sie sich als Linux-Benutzer example.user an. Wenn Sie sich anmelden, ordnet das PAM-Modul pam_selinux den Linux-Benutzer automatisch einem SELinux-Benutzer zu (in diesem Fall unconfined_u) und richtet den resultierenden SELinux-Kontext ein. Mit diesem Kontext wird dann die Shell des Linux-Benutzers gestartet.

Überprüfung

ZUSÄTZLICHE RESSOURCEN

Pam_selinux (8) Manpage.

Führen Sie die folgenden Schritte aus, um dem System einen neuen, auf SELinux beschränkten Benutzer hinzuzufügen. In diesem Beispielverfahren wird der Benutzer mit dem Befehl zum Erstellen des Benutzerkontos dem SELinux-Benutzerrecht „staff_u“ zugeordnet.

Voraussetzungen

Vorgehensweise

Überprüfung

ZUSÄTZLICHE RESSOURCEN

Pam_selinux (8) Manpage.

Sie können alle regulären Benutzer auf Ihrem System einschränken, indem Sie sie dem SELinux-Benutzer user_u zuordnen.

Standardmäßig werden alle Linux-Benutzer in Red Hat Enterprise Linux, einschließlich Benutzern mit Administratorrechten, dem uneingeschränkten SELinux-Benutzer unconfined_u zugeordnet. Sie können die Sicherheit des Systems verbessern, indem Sie Benutzer SELinux-beschränkten Benutzern zuweisen.

Vorgehensweise

Überprüfung

Stellen Sie sicher, dass die Prozesse eines neuen Benutzers im SELinux-Kontext user_u: user_r: user_t: s0 ausgeführt werden.

Erstellen Sie einen neuen Benutzer:

Definieren Sie ein Passwort für example.user:

Melden Sie sich als Root ab und als neuer Benutzer an. Zeigen Sie den Sicherheitskontext für die Benutzer-ID an:

Zeigen Sie den Sicherheitskontext der aktuellen Prozesse des Benutzers an:

Sie können einen Benutzer mit Administratorrechten einschränken, indem Sie den Benutzer direkt dem SELinux-Benutzer sysadm_u zuordnen. Wenn sich der Benutzer anmeldet, wird die Sitzung im SELinux-Kontext sysadm_u: sysadm_r: sysadm_t ausgeführt.

Standardmäßig werden alle Linux-Benutzer in Red Hat Enterprise Linux, einschließlich Benutzern mit Administratorrechten, dem uneingeschränkten SELinux-Benutzer unconfined_u zugeordnet. Sie können die Sicherheit des Systems verbessern, indem Sie Benutzer SELinux-beschränkten Benutzern zuweisen.

Voraussetzung

Vorgehensweise

Optional: Ordnen Sie einen vorhandenen Benutzer dem SELinux-Benutzer sysadm_u zu und fügen Sie den Benutzer der Wheel-Benutzergruppe hinzu:

Überprüfung

Erfolgt keine Ausgabe, wurde der Befehl erfolgreich abgeschlossen.

Wenn der Befehl nicht erfolgreich abgeschlossen wird, wird die folgende Meldung ausgegeben:

Sie können dem SELinux-Benutzer „staff_u“ einen bestimmten Benutzer mit Administratorrechten zuordnen und sudo so konfigurieren, dass der Benutzer die SELinux-Administratorrolle „sysadm_r“ erhalten kann. Mit dieser Rolle kann der Benutzer Verwaltungsaufgaben ohne SELinux-Ablehnungen ausführen. Wenn sich der Benutzer anmeldet, wird die Sitzung im SELinux-Kontext „staff_u: staff_r: staff_t“ ausgeführt. Wenn der Benutzer jedoch mit „sudo“ einen Befehl eingibt, wechselt die Sitzung in den Kontext „staff_u: sysadm_r: sysadm_t“.

Standardmäßig werden alle Linux-Benutzer in Red Hat Enterprise Linux, einschließlich Benutzern mit Administratorrechten, dem uneingeschränkten SELinux-Benutzer unconfined_u zugeordnet. Sie können die Sicherheit des Systems verbessern, indem Sie Benutzer SELinux-beschränkten Benutzern zuweisen.

Voraussetzungen

Überprüfung

Erfolgt keine Ausgabe, wurde der Befehl erfolgreich abgeschlossen.

Wenn der Befehl nicht erfolgreich abgeschlossen wird, wird die folgende Meldung ausgegeben:

Sie können den Apache-HTTP-Server so konfigurieren, dass er einen anderen Port überwacht und Inhalte in einem nicht standardmäßigen Verzeichnis bereitstellt. Um Folgeverweigerungen von SELinux zu verhindern, befolgen Sie die Schritte in diesem Verfahren, um die SELinux-Richtlinie Ihres Systems anzupassen.

Voraussetzungen

Vorgehensweise

Überprüfung

Sie können Teile der SELinux-Richtlinie zur Laufzeit mithilfe von Booleschen Werten ändern, auch ohne Kenntnisse über das Schreiben von SELinux-Richtlinien. Dies ermöglicht Änderungen, z. B. das Ermöglichen des Dienstzugriffs auf NFS-Volumes, ohne die SELinux-Richtlinie neu laden oder neu kompilieren zu müssen. Das folgende Verfahren veranschaulicht das Auflisten von SELinux-Booleschen Werten und deren Konfiguration, um die erforderlichen Änderungen in der Richtlinie zu erreichen.

NFS-Mounts auf der Clientseite werden mit einem Standardkontext gekennzeichnet, der durch eine Richtlinie für NFS-Volumes definiert wird. In RHEL verwendet dieser Standardkontext den Typ nfs_t. Darüber hinaus werden auf der Clientseite gemountete Samba-Freigaben mit einem durch die Richtlinie definierten Standardkontext gekennzeichnet. Dieser Standardkontext verwendet den Typ cifs_t. Sie können boolesche Werte aktivieren oder deaktivieren, um zu steuern, welche Dienste auf die Typen nfs_t und cifs_t zugreifen dürfen.

Führen Sie die folgenden Schritte aus, um dem Apache-HTTP-Serverdienst (httpd) den Zugriff auf und die Freigabe von NFS- und CIFS-Volumes zu ermöglichen:

Voraussetzungen

Vorgehemsweise

. Aktivieren Sie die identifizierten booleschen Werte:

Überprüfung

Wenn Sie Zugriffskontrollregeln festlegen müssen, die von der Standard-SELinux-Richtlinie nicht abgedeckt werden, suchen Sie zunächst nach einem Boolean-Wert, der Ihrem Anwendungsfall entspricht. Wenn Sie keinen passenden Boolean-Wert finden, können Sie einen passenden SELinux-Typ verwenden oder sogar ein lokales Richtlinienmodul erstellen.

Voraussetzungen

Vorgehensweise

Sie können den Zugriff auf ein nicht standardmäßiges freigegebenes Verzeichnis für den generischen, nicht privilegierten SELinux-Benutzer user_u konfigurieren, indem Sie den entsprechenden SELinux-Dateityp suchen und zuordnen. Der Benutzer user_u hat die Standardrolle user_r und die Standarddomäne user_t.

Voraussetzungen

Die Pakete selinux-policy-doc und setools-console sind auf Ihrem System installiert.

Vorgehensweise

Suchen Sie im Abschnitt VERWALTETE DATEIEN nach einem Attribut oder Typ, der Ihrem Szenario entspricht. Beispielsweise das Attribut user_home_type.

Überprüfung

Befolgen Sie nur die notwendigen Schritte dieses Verfahrens. In den meisten Fällen müssen Sie nur Schritt 1 ausführen.

Vorgehensweise

Wenn es keine Übereinstimmungen gibt, prüfen Sie, ob der Audit-Daemon ausgeführt wird. Wenn nicht, wiederholen Sie das abgelehnte Szenario, nachdem Sie auditd gestartet haben, und prüfen Sie das Audit-Protokoll erneut.

So deaktivieren Sie Dontaudit-Regeln vorübergehend, sodass alle Ablehnungen protokolliert werden:

Nachdem Sie Ihr abgelehntes Szenario erneut ausgeführt und mithilfe der vorherigen Schritte Ablehnungsmeldungen gefunden haben, aktiviert der folgende Befehl die Dontaudit-Regeln in der Richtlinie wieder:

Wechseln Sie in den permissiven Modus:

Wenn das Problem weiterhin auftritt, blockiert etwas anderes als SELinux Ihr Szenario.

Nachdem Sie festgestellt haben, dass SELinux Ihr Szenario blockiert, müssen Sie möglicherweise die Grundursache analysieren, bevor Sie eine Lösung auswählen.

Voraussetzungen

Die Pakete policycoreutils-python-utils und setroubleshoot-server sind auf Ihrem System installiert.

Vorgehensweise

Wenn die im vorherigen Schritt erhaltene Ausgabe keine klaren Vorschläge enthält:

Leeren Sie den Setroubleshoot-Cache:

Reproduzieren Sie das Problem. Wiederholen Sie Schritt 1.

Nachdem Sie den Vorgang abgeschlossen haben, deaktivieren Sie die vollständige Pfadüberwachung:

Wenn sealert nur Catchall-Vorschläge zurückgibt oder vorschlägt, mit dem Tool audit2allow eine neue Regel hinzuzufügen, gleichen Sie Ihr Problem mit den in den SELinux-Ablehnungen im Audit-Protokoll aufgeführten und erläuterten Beispielen ab.

In den meisten Fällen geben Ihnen die Vorschläge des Tools sealert die richtige Anleitung, wie Sie Probleme im Zusammenhang mit der SELinux-Richtlinie beheben können. Informationen zur Verwendung von sealert zur Analyse von SELinux-Ablehnungen finden Sie unter Analysieren von SELinux-Ablehnungsmeldungen.

Seien Sie vorsichtig, wenn das Tool vorschlägt, das Tool audit2allow für Konfigurationsänderungen zu verwenden. Sie sollten audit2allow nicht als erste Option verwenden, um ein lokales Richtlinienmodul zu generieren, wenn Sie eine SELinux-Ablehnung sehen. Die Fehlerbehebung sollte mit einer Überprüfung beginnen, ob ein Beschriftungsproblem vorliegt. Der zweithäufigste Fall ist, dass Sie eine Prozesskonfiguration geändert und vergessen haben, SELinux darüber zu informieren.

Beschriftungsprobleme (Labeling)

Eine häufige Ursache für Beschriftungsprobleme ist die Verwendung eines nicht standardmäßigen Verzeichnisses für einen Dienst. Beispielsweise möchte ein Administrator für eine Website möglicherweise nicht /var/www/html/, sondern /srv/myweb/ verwenden. Unter Red Hat Enterprise Linux wird das Verzeichnis /srv mit dem Typ var_t beschriftet. In /srv erstellte Dateien und Verzeichnisse erben diesen Typ. Außerdem können neu erstellte Objekte in Verzeichnissen der obersten Ebene, wie z. B. /myserver, mit dem Typ default_t beschriftet werden. SELinux verhindert, dass der Apache-HTTP-Server (httpd) auf beide Typen zugreift. Um den Zugriff zu ermöglichen, muss SELinux wissen, dass die Dateien in /srv/myweb/ über httpd zugänglich sein sollen:

Dieser Semanage-Befehl fügt den Kontext für das Verzeichnis /srv/myweb/ und alle Dateien und Verzeichnisse darunter zur SELinux-Dateikontextkonfiguration hinzu. Das Semanage-Dienstprogramm ändert den Kontext nicht. Verwenden Sie als Root das Dienstprogramm restorecon, um die Änderungen anzuwenden:

Falscher Kontext

Das Dienstprogramm matchpathcon prüft den Kontext eines Dateipfads und vergleicht ihn mit der Standardbezeichnung für diesen Pfad. Das folgende Beispiel zeigt die Verwendung von matchpathcon in einem Verzeichnis, das falsch bezeichnete Dateien enthält:

In diesem Beispiel sind die Dateien index.html und page1.html mit dem Typ user_home_t bezeichnet. Dieser Typ wird für Dateien in Benutzer-Home-Verzeichnissen verwendet. Wenn Sie den Befehl mv verwenden, um Dateien aus Ihrem Home-Verzeichnis zu verschieben, kann es sein, dass Dateien mit dem Typ user_home_t gekennzeichnet werden. Dieser Typ sollte außerhalb von Home-Verzeichnissen nicht existieren. Verwenden Sie das Dienstprogramm restorecon, um solche Dateien auf ihren richtigen Typ zurückzusetzen:

Um den Kontext für alle Dateien in einem Verzeichnis wiederherzustellen, verwenden Sie die Option -R:

Confined Anwendungen, die auf nicht standardmäßige Weise konfiguriert sind

Dienste können auf verschiedene Arten ausgeführt werden. Um dies zu berücksichtigen, müssen Sie angeben, wie Sie Ihre Dienste ausführen. Sie können dies durch SELinux-Boolesche Werte erreichen, die es ermöglichen, Teile der SELinux-Richtlinie zur Laufzeit zu ändern. Dies ermöglicht Änderungen, wie z. B. das Erlauben des Zugriffs von Diensten auf NFS-Volumes, ohne die SELinux-Richtlinie neu zu laden oder neu zu kompilieren. Außerdem erfordert das Ausführen von Diensten auf nicht standardmäßigen Portnummern eine Aktualisierung der Richtlinienkonfiguration mit dem Befehl „semanage“.

Um beispielsweise dem Apache-HTTP-Server die Kommunikation mit MariaDB zu ermöglichen, aktivieren Sie den Booleschen Wert httpd_can_network_connect_db:

Beachten Sie, dass die Option -P die Einstellung über Neustarts des Systems hinweg persistent macht.

Wenn der Zugriff für einen bestimmten Dienst verweigert wird, verwenden Sie die Dienstprogramme getsebool und grep, um zu prüfen, ob Boolesche Werte verfügbar sind, um den Zugriff zu erlauben. Verwenden Sie beispielsweise getsebool -a | grep ftp-Befehl zum Suchen nach FTP-bezogenen Booleans:

Um eine Liste der Booleans zu erhalten und herauszufinden, ob sie aktiviert oder deaktiviert sind, verwenden Sie den Befehl getsebool -a. Um eine Liste der Booleans einschließlich ihrer Bedeutung zu erhalten und herauszufinden, ob sie aktiviert oder deaktiviert sind, installieren Sie das Paket selinux-policy-devel und verwenden Sie den Befehl semanage boolean -l als Root.

Portnummern

Je nach Richtlinienkonfiguration können Dienste nur auf bestimmten Portnummern ausgeführt werden dürfen. Der Versuch, den Port zu ändern, auf dem ein Dienst ausgeführt wird, ohne die Richtlinie zu ändern, kann dazu führen, dass der Dienst nicht gestartet wird. Führen Sie beispielsweise den Befehl semanage port -l | grep http als Root aus, um HTTP-bezogene Ports aufzulisten:

Der Porttyp http_port_t definiert die Ports, auf denen der Apache HTTP-Server lauschen kann. In diesem Fall sind dies die TCP-Ports 80, 443, 488, 8008, 8009 und 8443. Wenn ein Administrator httpd.conf so konfiguriert, dass httpd auf Port 9876 lauscht (Listen 9876), die Richtlinie jedoch nicht entsprechend aktualisiert wird, schlägt der folgende Befehl fehl:

Eine SELinux-Ablehnungsmeldung ähnlich der folgenden wird in /var/log/audit/audit.log protokolliert:

Um httpd das Abhören eines Ports zu ermöglichen, der nicht für den Porttyp http_port_t aufgeführt ist, verwenden Sie den Befehl semanage port, um dem Port eine andere Bezeichnung zuzuweisen:

Die Option -a fügt einen neuen Datensatz hinzu, die Option -t definiert einen Typ und die Option -p definiert ein Protokoll. Das letzte Argument ist die hinzuzufügende Portnummer.

Sonderfälle, sich entwickelnde oder defekte Anwendungen und kompromittierte Systeme

Anwendungen können Fehler enthalten, die dazu führen, dass SELinux den Zugriff verweigert. Außerdem entwickeln sich die SELinux-Regeln weiter – SELinux hat möglicherweise eine Anwendung nicht auf eine bestimmte Weise ausgeführt, was möglicherweise dazu führt, dass es den Zugriff verweigert, obwohl die Anwendung wie erwartet funktioniert. Wenn beispielsweise eine neue Version von PostgreSQL veröffentlicht wird, kann sie Aktionen ausführen, die die aktuelle Richtlinie nicht berücksichtigt, wodurch der Zugriff verweigert wird, obwohl der Zugriff erlaubt sein sollte.

Verwenden Sie für diese Situationen nach der Zugriffsverweigerung das Dienstprogramm audit2allow, um ein benutzerdefiniertes Richtlinienmodul zu erstellen, das den Zugriff erlaubt. Sie können fehlende Regeln in der SELinux-Richtlinie in Red Hat Bugzilla melden. Erstellen Sie für Red Hat Enterprise Linux 9 Fehler für das Produkt Red Hat Enterprise Linux 9 und wählen Sie die Komponente selinux-policy aus. Fügen Sie die Ausgabe der Befehle audit2allow -w -a und audit2allow -a in solche Fehlerberichte ein.

Wenn eine Anwendung wichtige Sicherheitsberechtigungen anfordert, kann dies ein Zeichen dafür sein, dass die Anwendung kompromittiert ist. Verwenden Sie Intrusion Detection Tools, um solches verdächtiges Verhalten zu untersuchen.

Die Solution Engine auf dem Red Hat Customer Portal kann auch Anleitungen in Form eines Artikels mit einer möglichen Lösung für dasselbe oder ein sehr ähnliches Problem wie Sie bereitstellen. Wählen Sie das entsprechende Produkt und die Version aus und verwenden Sie SELinux-bezogene Schlüsselwörter wie selinux oder avc zusammen mit dem Namen Ihres blockierten Dienstes oder Ihrer blockierten Anwendung, zum Beispiel: selinux samba.

Durch das Hinzufügen bestimmter SELinux-Richtlinienmodule zu einer aktiven SELinux-Richtlinie können bestimmte Probleme mit der SELinux-Richtlinie behoben werden. Sie können dieses Verfahren verwenden, um ein bestimmtes bekanntes Problem zu beheben, das in den Versionshinweisen von Red Hat beschrieben wird, oder um eine bestimmte Red Hat-Lösung zu implementieren.

Voraussetzungen

Die Pakete „setools-console“ und „audit“ zur Überprüfung.

Vorgehensweise

Um Ihre lokalen Module besser zu organisieren, verwenden Sie das Präfix „local_“ in den Namen lokaler SELinux-Richtlinienmodule.

Die Beispiellösung wurde für RHEL in RHBA-2021:4420 dauerhaft behoben. Daher haben die für diese Lösung spezifischen Teile dieses Verfahrens keine Auswirkungen auf aktualisierte RHEL 8- und 9-Systeme und sind nur als Syntaxbeispiele enthalten.

Sie können eine der beiden SELinux-Regelsyntaxen verwenden, Common Intermediate Language (CIL) und m4. Beispielsweise entspricht (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read))) in CIL dem Folgenden in m4:

Wenn Sie ein lokales Richtlinienmodul entfernen möchten, das Sie mit „semodule -i“ erstellt haben, verweisen Sie auf den Modulnamen ohne das Suffix „.cil“. Um ein lokales Richtlinienmodul zu entfernen, verwenden Sie „semodule -r <local_module>“.

Überprüfung

Da lokale Module die Priorität 400 haben, können Sie sie auch mithilfe dieses Werts aus der Liste filtern, z. B. mit dem Befehl semodule -lfull | grep -v ^100.

Wobei <SOURCENAME> der Quell-SELinux-Typ, <TARGETNAME> der Ziel-SELinux-Typ, <CLASSNAME> der Name der Sicherheitsklasse oder Objektklasse und <P1> und <P2> die spezifischen Berechtigungen der Regel sind.

Beispielsweise verweigert SELinux cups-lpd den Lesezugriff auf cups.sock in der RHEL-Lösung:

Die letzte Zeile sollte jetzt den Lesevorgang enthalten.

Identifizieren Sie den Prozess, der mit dem relevanten Dienst zusammenhängt:

Überprüfen Sie den SELinux-Kontext des Prozesses, der in der Ausgabe des vorherigen Befehls aufgeführt ist:

Überprüfen Sie, dass der Dienst keine SELinux-Ablehnungen verursacht:

Die Option -i interpretiert die numerischen Werte in einen für Menschen lesbaren Text.

Das Linux Audit-System speichert Protokolleinträge standardmäßig in der Datei /var/log/audit/audit.log.

Um nur SELinux-bezogene Datensätze aufzulisten, verwenden Sie den Befehl ausearch mit dem Nachrichtentypparameter, der mindestens auf AVC und AVC_USER eingestellt ist, zum Beispiel: i

Ein SELinux-Ablehnungseintrag in der Audit-Protokolldatei kann wie folgt aussehen:

Die wichtigsten Teile dieses Eintrags sind:

Der vorherige Protokolleintrag kann wie folgt übersetzt werden:

SELinux hat dem httpd-Prozess mit PID 6591 und dem Typ httpd_t das Lesen aus einem Verzeichnis mit dem Typ nfs_t verweigert.

Die folgende SELinux-Ablehnungsmeldung wird angezeigt, wenn der Apache-HTTP-Server versucht, auf ein Verzeichnis zuzugreifen, das mit einem Typ für die Samba-Suite gekennzeichnet ist:

Diese SELinux-Verweigerung kann wie folgt übersetzt werden:

SELinux hat dem httpd-Prozess mit PID 2465 den Zugriff auf die Datei /var/www/html/file1 mit dem Typ samba_share_t verweigert, die für Prozesse, die in der Domäne httpd_t ausgeführt werden, nicht zugänglich ist, sofern nicht anders konfiguriert.

Die Multi-Level Security (MLS)-Technologie klassifiziert Daten in einer hierarchischen Klassifizierung anhand von Informationssicherheitsstufen, zum Beispiel:

Standardmäßig verwendet die MLS SELinux-Richtlinie 16 Vertraulichkeitsstufen:

MLS verwendet eine spezielle Terminologie, um Vertraulichkeitsstufen anzusprechen:

Um MLS zu implementieren, verwendet SELinux das Bell-La Padula-Modell (BLP). Dieses Modell gibt an, wie Informationen innerhalb des Systems fließen können, basierend auf Etiketten, die jedem Subjekt und Objekt zugeordnet sind.

Das Grundprinzip von BLP lautet „Kein Lesen, kein Aufschreiben“. Dies bedeutet, dass Benutzer nur Dateien mit ihrer eigenen Vertraulichkeitsstufe und niedriger lesen können und Daten nur von niedrigeren zu höheren Ebenen fließen können und nie umgekehrt.

Die MLS SELinux-Richtlinie, die die Implementierung von MLS auf RHEL darstellt, wendet ein modifiziertes Prinzip namens Bell-La Padula mit Schreibgleichheit an. Dies bedeutet, dass Benutzer Dateien auf ihrer eigenen Vertraulichkeitsstufe und niedriger lesen können, aber nur auf genau ihrer eigenen Stufe schreiben können. Dies verhindert beispielsweise, dass Benutzer mit niedriger Berechtigung Inhalte in streng geheime Dateien schreiben.

Beispielsweise gilt standardmäßig für einen Benutzer mit Berechtigungsstufe s2:

In der Praxis werden Benutzern normalerweise verschiedene Freigabestufen zugewiesen, z. B. s1-s2. Ein Benutzer kann Dateien mit niedrigeren Vertraulichkeitsstufen als der maximalen Stufe des Benutzers lesen und in alle Dateien innerhalb dieses Bereichs schreiben.

Beispielsweise gilt standardmäßig für einen Benutzer mit einer Freigabestufe von s1-s2:

Der Sicherheitskontext für einen nicht privilegierten Benutzer in einer MLS-Umgebung ist beispielsweise:

Dabei gilt:

Ist der SELinux-Benutzer.

Ist die SELinux-Rolle.

Ist der SELinux-Typ.

Ist der Bereich der MLS-Vertraulichkeitsstufen.

Das System kombiniert immer MLS-Zugriffsregeln mit herkömmlichen Dateizugriffsberechtigungen. Wenn beispielsweise ein Benutzer mit der Sicherheitsstufe „Geheim“ Discretionary Access Control (DAC) verwendet, um den Zugriff anderer Benutzer auf eine Datei zu blockieren, können selbst „Streng geheime“ Benutzer nicht auf diese Datei zugreifen. Eine hohe Sicherheitsfreigabe erlaubt einem Benutzer nicht automatisch, das gesamte Dateisystem zu durchsuchen.

Benutzer mit Freigaben auf höchster Ebene erhalten nicht automatisch Administratorrechte auf mehrstufigen Systemen. Obwohl sie möglicherweise Zugriff auf alle vertraulichen Informationen über das System haben, ist dies etwas anderes als Administratorrechte.

Außerdem bieten Administratorrechte keinen Zugriff auf vertrauliche Informationen. Selbst wenn sich beispielsweise jemand als Root anmeldet, kann er streng geheime Informationen nicht lesen.

Sie können den Zugriff innerhalb eines MLS-Systems mithilfe von Kategorien weiter anpassen. Mit Multi-Category Security (MCS) können Sie Kategorien wie Projekte oder Abteilungen definieren. Benutzer dürfen dann nur auf Dateien in den Kategorien zugreifen, denen sie zugewiesen sind. Weitere Informationen finden Sie unter Verwenden von Multi-Category Security (MCS) zum Schutz der Datenvertraulichkeit.

Die SELinux-Richtlinie ordnet jeden Linux-Benutzer einem SELinux-Benutzer zu. Dadurch können Linux-Benutzer die Beschränkungen von SELinux-Benutzern übernehmen.

Sie können die Berechtigungen für eingeschränkte Benutzer in Ihrer SELinux-Richtlinie nach Ihren spezifischen Anforderungen anpassen, indem Sie die Booleschen Werte in der Richtlinie anpassen. Sie können den aktuellen Status dieser Booleschen Werte mit dem Befehl „semanage boolean -l“ ermitteln. Um alle SELinux-Benutzer, ihre SELinux-Rollen und MLS/MCS-Ebenen und -Bereiche aufzulisten, verwenden Sie den Befehl „semanage user -l“ als Root.

Beachten Sie, dass system_u eine spezielle Benutzeridentität für Systemprozesse und -objekte und system_r die zugehörige Rolle ist. Administratoren dürfen diesen system_u-Benutzer und die system_r-Rolle niemals einem Linux-Benutzer zuordnen. Auch unconfined_u und root sind uneingeschränkte Benutzer. Aus diesen Gründen sind die diesen SELinux-Benutzern zugeordneten Rollen nicht in der folgenden Tabelle Typen und Zugriff von SELinux-Rollen enthalten.

Jede SELinux-Rolle entspricht einem SELinux-Typ und bietet bestimmte Zugriffsrechte.

Verwenden Sie die folgenden Schritte, um die SELinux-Richtlinie von gezielt auf Multi-Level Security (MLS) umzustellen.

Vorgehensweise

Speichern Sie die Änderungen und beenden Sie den Editor.

Da der vorherige Befehl nicht alle Szenarien abdeckt, finden Sie unter Beheben von Problemen im Zusammenhang mit SELinux Anleitungen zum Identifizieren, Analysieren und Beheben von SELinux-Ablehnungen.

Starten Sie das System neu:

Beachten Sie auch, dass sich in MLS SSH-Anmeldungen als Root-Benutzer, der der SELinux-Rolle sysadm_r zugeordnet ist, von der Anmeldung als Root in staff_r unterscheiden. Bevor Sie Ihr System zum ersten Mal in MLS starten, sollten Sie SSH-Anmeldungen als sysadm_r zulassen, indem Sie den SELinux-Booleschen Wert ssh_sysadm_login auf 1 setzen. Um ssh_sysadm_login später, bereits in MLS, zu aktivieren, müssen Sie sich als Root in staff_r anmelden, mit dem Befehl newrole -r sysadm_r zu Root in sysadm_r wechseln und dann den Booleschen Wert auf 1 setzen.

Überprüfung

Überprüfen Sie, ob SELinux im Durchsetzungsmodus ausgeführt wird:

Überprüfen Sie, ob der Status von SELinux den mls-Wert zurückgibt:

Nachdem Sie die SELinux-Richtlinie auf MLS umgestellt haben, müssen Sie Benutzern Sicherheitsfreigabestufen zuweisen, indem Sie sie eingeschränkten SELinux-Benutzern zuordnen. Standardmäßig gilt für einen Benutzer mit einer bestimmten Sicherheitsfreigabe:

Voraussetzungen

Vorgehensweise

Beachten Sie, dass SELinux im permissiven Modus die aktive Richtlinie nicht erzwingt, sondern nur Access Vector Cache (AVC)-Nachrichten protokolliert, die dann zur Fehlerbehebung und zum Debuggen verwendet werden können.

Überprüfungsschritte