Linux/SELinux/11 Fehlerbehebung/Lösungen

SELinux/11 Fehlerbehebung/Lösungen

← Zurück

Weiter →

Beschreibung

Lösungen

Hilfe bei der Fehlerbehebung

• Überprüfung von Linux-Berechtigungen, die vor den SELinux-Regeln geprüft werden
• mögliche Ursachen dafür, dass SELinux den Zugriff verweigert, aber keine Verweigerungen protokolliert werden
• Handbuchseiten für Dienste, die Informationen zu Labeling und Booleschen Werten enthalten
• permissive Domänen, um einem einzelnen Prozess statt dem gesamten System permissives Verhalten zu ermöglichen
• Suchen und Anzeigen von Verweigerungsmeldungen
• Analysieren von Verweigerungen
• Erstellen benutzerdefinierter Policy-Module

Linux-Berechtigungen

Wenn der Zugriff verweigert wird, überprüfen Sie die Standard-Linux-Berechtigungen

• Wie in Kapitel 1,Einführung, erwähnt, verwenden die meisten Betriebssysteme ein Discretionary Access Control (DAC)-System zur Zugriffskontrolle, das es Benutzern ermöglicht, die Berechtigungen für Dateien zu steuern, deren Eigentümer sie sind
• SELinux-Richtlinienregeln werden nach den DAC-Regeln überprüft
• SELinux-Richtlinienregeln werden nicht angewendet, wenn DAC-Regeln den Zugriff bereits verweigert haben

Wenn der Zugriff verweigert wird und keine SELinux-Verweigerungen protokolliert werden, verwenden Sie den folgenden Befehl, um die Standard-Linux-Berechtigungen anzuzeigen:

ls -l /var/www/html/index.html
-rw-r----- 1 root root 0 2009-05-07 11:06 index.html

In diesem Beispiel gehört die Datei index.html dem Root-Benutzer und der Root-Gruppe

• Der Root-Benutzer verfügt über Lese- und Schreibrechte (-rw), und Mitglieder der Root-Gruppe haben Leserechte (-r-)
• Alle anderen haben keinen Zugriff (---)
• Standardmäßig erlauben solche Berechtigungen httpd nicht, diese Datei zu lesen
• Um dieses Problem zu beheben, verwenden Sie den Befehl chown, um den Eigentümer und die Gruppe zu ändern
• Dieser Befehl muss als root ausgeführt werden:

sudo chown apache:apache /var/www/html/index.html

Dies setzt die Standardkonfiguration voraus, in der httpd als Linux-Apache-Benutzer läuft

• Wenn Sie httpd mit einem anderen Benutzer ausführen, ersetzen Sie apache:apache durch diesen Benutzer

Informationen zur Verwaltung von Linux-Berechtigungen finden Sie im Entwurf „Permissions“ des Fedora Documentation Project

Stille Zugriffsverweigerungen

Mögliche Ursachen für stille Zugriffsverweigerungen

In bestimmten Situationen werden AVC-Verweigerungsmeldungen möglicherweise nicht protokolliert, wenn SELinux den Zugriff verweigert

• Anwendungen und Systembibliotheksfunktionen versuchen oft, mehr Zugriff zu erlangen, als für die Ausführung ihrer Aufgaben erforderlich ist
• Um das Prinzip der geringsten Privilegien zu wahren, ohne die Audit-Protokolle mit AVC-Verweigerungen für harmlose Anwendungsversuche zu überfluten, kann die Richtlinie AVC-Verweigerungen unterdrücken, ohne die Berechtigung zu erteilen, indem sie „dontaudit“-Regeln verwendet
• Diese Regeln sind in Standardrichtlinien üblich
• Der Nachteil von „dontaudit“ ist, dass, obwohl SELinux den Zugriff verweigert, keine Verweigerungsmeldungen protokolliert werden, was die Fehlerbehebung erschwert

Um „dontaudit“-Regeln vorübergehend zu deaktivieren, sodass alle Verweigerungen protokolliert werden, geben Sie als Root den folgenden Befehl ein:

sudo semodule -DB

Die Option -D deaktiviert die „dontaudit“-Regeln; die Option -B erstellt die Richtlinie neu

• Versuchen Sie nach dem Ausführen von semodule -DB die Anwendung auszuführen, bei der zuvor Berechtigungsprobleme auftraten, und prüfen Sie, ob SELinux-Ablehnungen – die für die Anwendung relevant sind – nun protokolliert werden
• Seien Sie vorsichtig bei der Entscheidung, welche Verweigerungen zugelassen werden sollen, da einige ignoriert und durch dontaudit-Regeln behandelt werden sollten
• Wenn Sie Zweifel haben oder Rat suchen, wenden Sie sich an andere SELinux-Benutzer und -Entwickler in einer SELinux-Mailingliste, wie fedora-selinux-list

Um die Richtlinie neu zu erstellen und dontaudit -Regeln zu aktivieren, geben Sie als Root den folgenden Befehl ein:

sudo semodule -B

Dadurch wird die Richtlinie in ihren ursprünglichen Zustand zurückversetzt

• Für eine vollständige Liste der dontaudit-Regeln führen Sie den Befehl sesearch --dontaudit aus
• Grenzen Sie die Suche mit der Option -sdomain und dem Befehl grep ein

Beispiel

sesearch --dontaudit -s smbd_t | grep squid
dontaudit smbd_t squid_port_t : tcp_socket name_bind ;
dontaudit smbd_t squid_port_t : udp_socket name_bind ;

Siehe Abschnitt „Raw Audit Messages“ und Abschnitt „[ [sealert-Meldungen]]“ für Informationen zur Analyse von Zugriffsverweigerungen

Handbuchseiten für Dienste

Handbuchseiten für Dienste enthalten wertvolle Informationen, beispielsweise welchen Dateityp in einer bestimmten Situation zu verwenden ist, sowie boolesche Werte zur Änderung der Zugriffsrechte eines Dienstes (wie httpd beim Zugriff auf NFS-Volumes)

• Diese Informationen können in der Standard-Handbuchseite oder in der Handbuchseite enthalten sein, die mit dem Dienstprogramm sepolicy manpage automatisch aus der SELinux-Richtlinie für jede Dienstdomäne generiert werden kann
• Solche Handbuchseiten sind im Format '‚Dienstname_selinux benannt
• Solche Handbuchseiten werden auch mit dem Paket selinux-policy-doc ausgeliefert

Beispielsweise enthält die Manpage httpd_selinux(8) Informationen darüber, welcher Dateityp in einer bestimmten Situation zu verwenden ist, sowie über Booleane, die Skripte, die Freigabe von Dateien, den Zugriff auf Verzeichnisse innerhalb von Benutzer-Home-Verzeichnissen usw. ermöglichen

• Weitere Manpages mit SELinux-Informationen für Dienste sind unter anderem:
• Samba: Die Manpage samba_selinux(8) beschreibt beispielsweise, dass die Aktivierung des Booleschen Werts samba_enable_home_dirs es Samba ermöglicht, Benutzer-Home-Verzeichnisse freizugeben
• NFS: Die Manpage nfsd_selinux(8) beschreibt die SELinux-nfsd-Richtlinie, die es Benutzern ermöglicht, ihre nfsd-Prozesse so sicher wie möglich einzurichten

Die Informationen in den Handbuchseiten helfen Ihnen dabei, die richtigen Dateitypen und Booleans zu konfigurieren, um zu verhindern, dass SELinux den Zugriff verweigert

Weitere Informationen zur sepolicy-Handbuchseite finden Sie im Abschnitt „Generieren von Handbuchseiten: sepolicy-Handbuchseite”

Permissive Domänen

Wenn SELinux im permissiven Modus läuft, verweigert SELinux keinen Zugriff, aber Verweigerungen werden für Aktionen protokolliert, die im Durchsetzungsmodus verweigert worden wären

• Früher war es nicht möglich, eine einzelne Domäne permissiv zu machen (denken Sie daran: Prozesse laufen in Domänen)
• In bestimmten Situationen führte dies dazu, dass das gesamte System zur Fehlerbehebung permissiv gemacht wurde

Permissive Domains ermöglichen es einem Administrator, einen einzelnen Prozess (eine Domain) so zu konfigurieren, dass er permissiv läuft, anstatt das gesamte System permissiv zu machen

• SELinux-Prüfungen werden für permissive Domains weiterhin durchgeführt; der Kernel gewährt jedoch Zugriff und meldet eine AVC-Verweigerung für Situationen, in denen SELinux den Zugriff verweigert hätte

Verwendungszweck

• Sie können verwendet werden, um einen einzelnen Prozess (eine Domäne) permissiv laufen zu lassen, um ein Problem zu beheben, ohne das gesamte System durch die Umstellung auf den permissiven Modus zu gefährden
• Sie ermöglichen es einem Administrator, Richtlinien für neue Anwendungen zu erstellen
• Früher wurde empfohlen, eine minimale Richtlinie zu erstellen, und anschließend den gesamten Rechner in den permissiven Modus zu versetzen, damit die Anwendung ausgeführt werden konnte, SELinux-Verweigerungen jedoch weiterhin protokolliert wurden
• Das Tool audit2allow konnte dann zur Erstellung der Richtlinie herangezogen werden
• Dies stellte das gesamte System einem Risiko aus
• Mit permissiven Domänen kann nur die Domäne in der neuen Richtlinie als permissiv markiert werden, ohne das gesamte System einem Risiko auszusetzen

Domäne permissiv machen

Um eine Domäne permissiv zu machen, führen Sie den Befehl semanage permissive -adomain aus, wobeidomain die Domäne ist, die Sie permissiv machen möchten

Geben Sie beispielsweise als Root den folgenden Befehl ein, um die Domäne httpd_t (die Domäne, in der der Apache-HTTP-Server läuft) permissiv zu machen:

sudo semanage permissive -a httpd_t

Um eine Liste der Domänen anzuzeigen, die Sie als permissiv markiert haben, führen Sie als Root den Befehl semodule -l | grep permissive aus

Beispiel

sudo semodule -l | grep permissive
permissive_httpd_t (null)
permissivedomains (null)

Wenn Sie eine Domäne nicht mehr als permissiv festlegen möchten, führen Sie den Befehl semanage permissive -ddomain als Root aus

Beispiel

sudo semanage permissive -d httpd_t

Permissiven Domänen deaktivieren

Das Modul permissivedomains.pp enthält alle Deklarationen für permissive Domänen, die auf dem System vorhanden sind

• Um alle permissiven Domänen zu deaktivieren, geben Sie als Root den folgenden Befehl ein:

sudo semodule -d permissivedomains

Hinweis

Sobald ein Richtlinienmodul über den Befehl semodule -d deaktiviert wurde, wird es nicht mehr in der Ausgabe des Befehls semodule -l angezeigt

Um alle Richtlinienmodule einschließlich der deaktivierten anzuzeigen, geben Sie als Root den folgenden Befehl ein:

sudo semodule --list-modules=full

Ablehnungen für permissive Domänen

Die SYSCALL -Meldung unterscheidet sich bei permissiven Domänen

• Im Folgenden finden Sie ein Beispiel für eine AVC-Ablehnung (und den zugehörigen Systemaufruf) vom Apache-HTTP-Server:

type=AVC msg=audit(1226882736.442:86): avc: denied { getattr } for pid=2427 comm= „httpd“ path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit (1226882736. 442:86): arch=40000003 syscall=196 success=no exit=-13 a0=b9a1e198 a1=bfc2921c a2=54dff4 a3=2008171 items=0 ppid=2425 pid=2427 auid=502 uid=48 gid=4
8 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Standardmäßig ist die Domäne httpd_t nicht permissiv, weshalb die Aktion verweigert wird und die SYSCALL -Meldung success=no enthält

• Das Folgende ist ein Beispiel für eine AVC-Verweigerung in derselben Situation, mit dem Unterschied, dass der Befehl semanage permissive -a httpd_t ausgeführt wurde, um die Domäne httpd_t permissiv zu machen:

type=AVC msg=audit(1226882925.714:136): avc: denied { read } for pid=2512 comm="httpd" name="file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u: object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226882925.714:136): arch=40000003 syscall=5 success=yes exit=11 a0=b962a1e8 a1=8000 a2=0 a3=8000 items=0 ppid=2511 pid=2512 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid =48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

In diesem Fall wurde zwar eine AVC-Ablehnung protokolliert, der Zugriff wurde jedoch nicht verweigert, wie durch success=yes in der SYSCALL -Meldung angezeigt wird

Weitere Informationen zu permissiven Domänen finden Sie in Dan Walshs Blogeintrag „Permissive Domains“

Suchen und Anzeigen von Verweigerungen

Dieser Abschnitt setzt voraus, dass die Pakete setroubleshoot, setroubleshoot-server, dbus und audit installiert sind und dass die Daemons auditd, rsyslogd und setroubleshootd laufen

• Informationen zum Starten dieser Daemons finden Sie im Abschnitt „ Welche Protokolldatei wird verwendet“ für Informationen zum Starten dieser Daemons
• Es stehen eine Reihe von Dienstprogrammen zum Suchen und Anzeigen von SELinux-AVC-Meldungen zur Verfügung, wie beispielsweise ausearch, aureport und sealert

ausearch

Das audit-Paket enthält das Dienstprogramm ausearch, mit dem die Protokolle des audit-Daemons nach Ereignissen anhand verschiedener Suchkriterien durchsucht werden können.[10]

Das Dienstprogramm ausearch greift auf /var/log/audit/audit.log zu und muss daher als Root-Benutzer ausgeführt werden:

Suche nach	Befehl
alle Verweigerungen	ausearch -m avc,user_avc,selinux_err,user_selinux_err
Verweigerungen für den heutigen Tag	ausearch -m avc -ts today
Verweigerungen der letzten 10 Minuten	ausearch -m avc -ts recent

Um nach SELinux-AVC-Meldungen für einen bestimmten Dienst zu suchen, verwenden Sie die Option -ccomm-name, wobeicomm-name der Name der ausführbaren Datei ist, zum Beispiel httpd für den Apache-HTTP-Server und smbd für Samba:

sudo ausearch -m avc -c httpd
sudo ausearch -m avc -c smbd

Bei jedem ausearch Befehl wird empfohlen, entweder die Option --interpret (-i) für bessere Lesbarkeit oder die Option --raw (-r) für die Skriptverarbeitung zu verwenden

• Weitere Optionen für ausearch finden Sie in der Handbuchseite ausearch(8)

aureport

Das Audit-Paket enthält das Dienstprogramm aureport

• das zusammenfassende Berichte der Audit-Systemprotokolle erstellt. [11]

Das Dienstprogramm aureport greift auf /var/log/audit/audit.log zu und muss daher als Root-Benutzer ausgeführt werden

• Um eine Liste der SELinux-Ablehnungsmeldungen und deren Häufigkeit anzuzeigen, führen Sie den Befehl aureport -a aus

Nachfolgend finden Sie eine Beispielausgabe, die zwei Ablehnungen enthält:

sudo aureport -a

AVC-Bericht

======================================
# Datum Uhrzeit Befehl Subjekt Systemaufruf Klasse Berechtigung Objekt Ereignis
======================================
1. 01.05.2009 21:41:39 httpd unconfined_u:system_r: httpd_t:s0 195 file getattr system_u:object_r:samba_share_t:s0 denied 2
2. 03.05.2009 22:00:25 vsftpd unconfined_u: system_r:ftpd_t:s0 5 file read unconfined_u:object_r:cifs_t:s0 denied 4

sealert

Das Paket setroubleshoot-server stellt das Dienstprogramm sealert bereit

• das die von setroubleshoot-server übersetzten Ablehnungsmeldungen ausliest.[12]
• Ablehnungen werden IDs zugewiesen, wie in /var/log/messages zu sehen ist

Beispiel für eine Ablehnung aus messages

setroubleshoot: SELinux verhindert den Zugriff von /usr/sbin/httpd auf name_bind über den tcp_socket
Für vollständige SELinux-Meldungen führen Sie sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7

In diesem Beispiel lautet die Ablehnungs-ID 8c123656-5dda-4e5d-8791-9e3bd03786b7

• Die Option -l nimmt eine ID als Argument entgegen
• Die Ausführung des Befehls sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7 liefert eine detaillierte Analyse, warum SELinux den Zugriff verweigert hat, sowie eine mögliche Lösung, um den Zugriff zu ermöglichen

Wenn Sie das X Window System verwenden, die Pakete setroubleshoot und setroubleshoot-server installiert haben und die Daemons setroubleshootd, dbus und auditd laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:

„Eine AVC-Ablehnungsmeldung“

Ein Klick auf Anzeigen startet die sealert GUI, mit der Sie das Problem beheben können:

Datei:Bild3.png

Alternativ können Sie den Befehl sealert -b ausführen, um die sealert GUI zu starten

• Um eine detaillierte Analyse aller Verweigerungsmeldungen anzuzeigen, führen Sie den Befehl sealert -l \* aus

Rohdaten der Audit-Meldungen

Rohdaten der Audit-Meldungen werden in /var/log/audit/audit.log protokolliert

Im Folgenden finden Sie ein Beispiel für eine AVC-Ablehnungsmeldung (und den zugehörigen Systemaufruf), die auftrat, als der Apache-HTTP-Server (der in der Domäne httpd_t läuft) versuchte, auf die Datei /var/www/html/file1 (mit dem Typ samba_share_t gekennzeichnet):

type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm -0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=4 8 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

{ getattr }

Der Eintrag in den geschweiften Klammern gibt die verweigerte Berechtigung an

• Der Eintrag getattr zeigt an, dass der Quellprozess versucht hat, die Statusinformationen der Zieldatei zu lesen
• Dies geschieht vor dem Lesen von Dateien
• Diese Aktion wird verweigert, da die Datei, auf die zugegriffen wird, ein falsches Label hat
• Häufig vorkommende Berechtigungen sind getattr, read und write

comm="httpd"

Die ausführbare Datei, die den Prozess gestartet hat

• Der vollständige Pfad der ausführbaren Datei findet sich im Abschnitt exe= der Systemaufruf-Meldung (SYSCALL), der in diesem Fall exe=„/usr/sbin/httpd“ lautet

path="/var/www/html/file1"

Der Pfad zu dem Objekt (Ziel), auf das der Prozess zuzugreifen versuchte

scontext=„‚'unconfined_u:system_r:httpd_t:s0"

Der SELinux-Kontext des Prozesses, der die abgelehnte Aktion versucht hat

• In diesem Fall ist es der SELinux-Kontext des Apache-HTTP-Servers, der in der Domäne httpd_t läuft

tcontext="unconfined_u:object_r:samba_share_t:s0"

Der SELinux-Kontext des Objekts (Ziels), auf das der Prozess zugreifen wollte

• In diesem Fall ist es der SELinux-Kontext von file1
• Beachten Sie, dass der Typ samba_share_t für Prozesse, die in der httpd_t Domäne laufen, nicht zugänglich ist

In bestimmten Situationen kann der tcontext mit dem scontext übereinstimmen, beispielsweise wenn ein Prozess versucht, einen Systemdienst auszuführen, der Eigenschaften des laufenden Prozesses, wie beispielsweise die Benutzer-ID, ändert

• Außerdem kann der tcontext mit dem scontext übereinstimmen, wenn ein Prozess versucht, mehr Ressourcen (wie Speicher) zu nutzen, als die normalen Grenzen zulassen, was zu einer Sicherheitsprüfung führt, um festzustellen, ob dieser Prozess diese Grenzen überschreiten darf

Systemaufruf-Meldung

Aus der Systemaufruf-Meldung (SYSCALL) sind zwei Punkte von Interesse:

• success=‚'no: gibt an, ob die Verweigerung (AVC) durchgesetzt wurde oder nicht
  • success=no bedeutet, dass der Systemaufruf nicht erfolgreich war (SELinux hat den Zugriff verweigert). success=yes bedeutet, dass der Systemaufruf erfolgreich war
  • Dies ist bei permissiven Domänen oder unconfined Domänen zu beobachten, wie beispielsweise unconfined_service_t und kernel_t
• exe=„'/usr/sbin/httpd“ : der vollständige Pfad zu der ausführbaren Datei, die den Prozess gestartet hat; in diesem Fall ist dies exe=„/usr/sbin/httpd“

Falscher Dateityp

Ein falscher Dateityp ist eine häufige Ursache dafür, dass SELinux den Zugriff verweigert

• Um mit der Fehlerbehebung zu beginnen, vergleichen Sie den Quellkontext (scontext) mit dem Zielkontext (tcontext )
• Sollte der Prozess (scontext) auf ein solches Objekt (tcontext) zugreifen?
• Beispielsweise sollte der Apache-HTTP-Server (httpd_t) nur auf Typen zugreifen, die in der Handbuchseite httpd_selinux(8) angegeben sind, wie httpd_sys_content_t, public_content_t'‚ usw., sofern nicht anders konfiguriert

sealert-Meldungen

Verweigerungen werden IDs zugewiesen, wie in '/var/log/messages

Beispiel

AVC-Verweigerung (protokolliert in messages) die auftrat, als der Apache-HTTP-Server (der in der Domäne httpd_t läuft) versuchte, auf die Datei /var/www/html/file1 (mit dem Typ samba_share_t gekennzeichnet) zuzugreifen:

hostname setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l 32eee32b-21ca-4846-a22f-0ba050206786

Vollständige Meldung anzuzeigen

sealert -l 32eee32b-21ca-4846-a22f-0ba050206786

Dieser Befehl funktioniert nur auf dem lokalen Rechner und zeigt dieselben Informationen an wie die sealert GUI:

sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
SELinux verhindert, dass httpd mit getattr auf die Datei /var/www/html/file1 zugreift

***** Das Plugin restorecon (92,2 % Zuverlässigkeit) schlägt vor ************************
Wenn Sie das Label korrigieren möchten

Das Standard-Label für /var/www/html/file1 sollte httpd_sys_content_t lauten
Dann können Sie restorecon ausführen
Führen Sie
sudo /sbin/restorecon -v /var/www/html/file1

***** Das Plugin public_content (Vertrauenswürdigkeit 7,83) schlägt vor ********************
Wenn Sie file1 als öffentlichen Inhalt behandeln möchten, dann müssen Sie die Label von file1 in public_content_t oder public_content_rw_t ändern
Führen Sie Folgendes aus
sudo semanage fcontext -a -t public_content_t ‚/var/www/html/file1‘

sudo restorecon -v ‚/var/www/html/file1‘
***** Das Plugin catchall (Vertrauenswürdigkeit 1,41) schlägt vor **************************

Wenn Sie der Meinung sind, dass httpd standardmäßig getattr-Zugriff auf die Datei file1 erhalten sollte

• Dann sollten Sie dies als Fehler melden

Sie können ein lokales Richtlinienmodul erstellen, um diesen Zugriff zuzulassen

Erlauben

Sie diesen Zugriff vorerst durch Ausführung von:

sudo ausearch -c ‚httpd‘ --raw | audit2allow -M my-httpd
sudo semodule -i my-httpd.pp

Zusätzliche Informationen:
Quellkontext system_u:system_r:httpd_t:s0

Zielkontext unconfined_u:object_r:samba_share_t:s0

Zielobjekte /var/www/html/file1 [ Datei ]
Quelle httpd
Quellpfad httpd
Port <Unbekannt>
Host hostname.redhat.com
Quell-RPM-Pakete
Ziel-RPM-Pakete
Richtlinien-RPM selinux-policy-3.13.1-166.el7.noarch

Selinux aktiviert True

Richtlinientyp targeted
Durchsetzungsmodus Enforcing
Hostname hostname.redhat.com
Plattform Linux hostname.redhat.com
                              3.10.0-693.el7.x86_64 #1 SMP Do, 6

• Juli 19:56:57

                              EDT 2017 x86_64 x86_64

Anzahl der Warnmeldungen 2

Erstmals gesehen 20.07.2017 02:52:11 EDT
Zuletzt gesehen 20.07.2017 02:52:11 EDT
Lokale ID 32eee32b-21ca-4846-a22f-0ba050206786

Rohdaten der Audit-Meldungen

 type=AVC msg=audit(1500533531.140:295): avc: abgelehnt { getattr } für pid=24934 comm="httpd" path="/var/www/html/file1" dev="vda1" ino=31457414 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

Hash: httpd,httpd_t,samba_share_t,file,getattr

Zusammenfassung

Eine kurze Zusammenfassung der abgelehnten Aktion

• Dies entspricht der Ablehnung in /var/log/messages
• In diesem Beispiel wurde dem Prozess httpd der Zugriff auf eine Datei (file1) verweigert, die mit dem Typ samba_share_t gekennzeichnet ist

>Detaillierte Beschreibung

Ausführliche Beschreibung

• In diesem Beispiel ist file1 mit dem Typ samba_share_t gekennzeichnet
• Dieser Typ wird für Dateien und Verzeichnisse verwendet, die Sie über Samba exportieren möchten
• Die Beschreibung schlägt vor, den Typ in einen Typ zu ändern, auf den der Apache-HTTP-Server und Samba zugreifen können, falls ein solcher Zugriff erforderlich ist

Zugriff gewähren

Ein Vorschlag, wie der Zugriff gewährt werden kann

• Dies kann das Umbenennen von Dateien, das Aktivieren eines booleschen Werts oder das Erstellen eines lokalen Richtlinienmoduls sein
• In diesem Fall lautet der Vorschlag, die Datei mit einem Typ zu kennzeichnen, auf den sowohl der Apache-HTTP-Server als auch Samba zugreifen können

Befehl zur Behebung des Problems

Ein vorgeschlagener Befehl, um den Zugriff zu gewähren und die Zugriffsverweigerung zu beheben

• In diesem Beispiel wird der Befehl angegeben, den Typ von file1 in public_content_t zu ändern, der sowohl für den Apache-HTTP-Server als auch für Samba zugänglich ist

Zusätzliche Informationen

Informationen, die in Fehlerberichten nützlich sind, wie der Name und die Version des Richtlinienpakets (selinux-policy-3.13.1-166.el7.noarch), die jedoch möglicherweise nicht zur Klärung der Ursache für die Zugriffsverweigerung beitragen

Rohdaten der Audit-Meldungen

Die Rohdaten der Audit-Meldungen aus /var/log/audit/audit.log, die mit der Verweigerung in Verbindung stehen

• Informationen zu den einzelnen Elementen der AVC-Verweigerung finden Sie in Abschnitt 11.3.6, „Rohdaten der Audit-Meldungen“

Zugriff zulassen

audit2allow

Warnung

Verwenden Sie das Beispiel in diesem Abschnitt nicht in der Produktion

• Es dient lediglich zur Veranschaulichung der Verwendung des Dienstprogramms audit2allow

audit2allow sammelt Informationen aus den Protokollen abgelehnter Vorgänge und generiert daraus SELinux-Policy-Zulassungsregeln.

Nachdem Sie die Ablehnungsmeldungen gemäß Abschnitt „sealert-Meldungen“, analysiert haben und sofern keine Label-Änderungen oder Boolesche Werte den Zugriff erlaubt haben, verwenden Sie audit2allow, um ein lokales Policy-Modul zu erstellen

• Wenn der Zugriff von SELinux verweigert wird, generiert die Ausführung von audit2allow Type-Enforcement-Regeln, die den zuvor verweigerten Zugriff erlauben

Sie sollten audit2allow nicht als erste Option zum Erstellen eines lokalen Richtlinienmoduls verwenden, wenn Sie eine SELinux-Ablehnung feststellen

• Die Fehlerbehebung sollte mit einer Überprüfung beginnen, ob ein Labeling-Problem vorliegt
• Der zweithäufigste Fall ist, dass Sie eine Prozesskonfiguration geändert und vergessen haben, SELinux darüber zu informieren
• Weitere Informationen finden Sie im Whitepaper „Die vier Hauptursachen für SELinux-Fehler“

Verwendung von audit2allow zum Erstellen eines Policy-Moduls

1. Eine Verweigerungsmeldung und der zugehörige Systemaufruf werden in der Datei /var/log/audit/audit.log protokolliert:

type=AVC msg=audit(122627035.848:238): avc: denied { write } for pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
type=SYSCALL msg=audit(1226270358.848:238): arch=40000003 syscall=39 success=no exit=-13 a0=39a2bf a1=3ff a2=3a0354 a3=94703c8 items=0 ppid=13344 pid=13349 auid=4294967295 uid=0 gid=0 euid=0 suid= 0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certwatch" exe="/usr/bin/certwatch" subj=system_u: system_r:certwatch_t:s0 key=(null)

In diesem Beispiel wurde certwatch der Schreibzugriff auf ein Verzeichnis verweigert, das mit dem Typ var_t gekennzeichnet ist

• Analysieren Sie die Ablehnungsmeldung gemäß Abschnitt 11.3.7, „sealert-Meldungen“
• Wenn keine Label-Änderungen vorgenommen wurden oder Booleane den Zugriff erlaubt haben, verwenden Sie audit2allow, um ein lokales Richtlinienmodul zu erstellen

2. Geben Sie den folgenden Befehl ein, um eine für Menschen lesbare Beschreibung zu erstellen, warum der Zugriff verweigert wurde

Das Dienstprogramm audit2allow liest die Datei /var/log/audit/audit.log und muss daher als Root-Benutzer ausgeführt werden:

sudo audit2allow -w -a
type=AVC msg=audit(1226270358.848:238): avc: verweigert { schreiben } für pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
       Ursache:
               Fehlende Type Enforcement (TE)-Zulassungsregel

Sie können audit2allow verwenden, um ein ladbares Modul zu generieren, das diesen Zugriff erlaubt

Die Befehlszeilenoption -a bewirkt, dass alle Audit-Protokolle gelesen werden

• Die Option -w erzeugt eine für Menschen lesbare Beschreibung
• Wie gezeigt, wurde der Zugriff aufgrund einer fehlenden Type Enforcement-Regel verweigert

1. Geben Sie den folgenden Befehl ein, um die Type Enforcement-Regel anzuzeigen, die den verweigerten Zugriff erlaubt:

sudo audit2allow -a

certwatch_t

allow certwatch_t var_t:dir write;

Wichtig

Fehlende Type Enforcement-Regeln werden in der Regel durch Fehler in der SELinux-Richtlinie verursacht und sollten in Red Hat Bugzilla gemeldet werden

• Erstellen Sie für das Produkt Red 

Hat Enterprise Linux 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

1. Um die von audit2allow -a' angezeigte Regel zu verwenden, geben Sie als Root den folgenden Befehl ein, um ein benutzerdefiniertes Modul zu erstellen

• Die Option -M erstellt eine Type-Enforcement-Datei (.te) mit dem durch -M angegebenen Namen in Ihrem aktuellen Arbeitsverzeichnis:

sudo audit2allow -a -M mycertwatch
******************** WICHTIG ********** *************
Um dieses Richtlinienpaket zu aktivieren, führen Sie Folgendes aus:

semodule -i mycertwatch.pp

# Außerdem kompiliert audit2allow die Type Enforcement-Regel in ein Richtlinienpaket (.pp):

sudo ls
mycertwatch.pp mycertwatch.te

Um das Modul zu installieren, geben Sie als Root den folgenden Befehl ein:

sudo semodule -imycertwatch.pp

Wichtig

Mit audit2allow erstellte Module gewähren möglicherweise mehr Zugriff als erforderlich

• Es wird empfohlen, mit audit2allow erstellte Richtlinien zur Überprüfung an die Upstream-SELinux-Liste zu senden
• Wenn Sie glauben, dass die Richtlinie einen Fehler enthält, melden Sie diesen bitte in Red Hat Bugzilla

Wenn Sie mehrere Ablehnungsmeldungen von verschiedenen Prozessen erhalten, aber nur eine benutzerdefinierte Richtlinie für einen einzelnen Prozess erstellen möchten, verwenden Sie das Dienstprogramm grep, um die Eingabe für audit2allow einzugrenzen

Das folgende Beispiel zeigt, wie man mit grep nur Ablehnungsmeldungen im Zusammenhang mit certwatch an audit2allow sendet:

sudo grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2
******************** WICHTIG ***************** ******
Um dieses Richtlinienpaket zu aktivieren, führen Sie Folgendes aus:
 semodule -i mycertwatch2.pp

Eigene Policy-Module mit audit2allow

Prinzip

Wenn Standardlösungen (wie Booleans oder Dateikontexte) nicht ausreichen, analysiert audit2allow die Audit-Protokolle und generiert automatisch Regeln, um zuvor blockierte Aktionen systemweit zuzulassen.

Installation

Unter Debian ist das Tool Teil der Python-Utilities für SELinux:

sudo apt install policycoreutils-python-utils

Analyse

Prüfen Sie zunächst die menschenlesbare Erklärung der Blockaden, um die Ursache zu verstehen:

sudo audit2allow -w -a

Modul generieren

Filtern Sie die Logs gezielt nach dem betroffenen Dienst (z. B. nginx), um keine unerwünschten Rechte freizugeben, und erstellen Sie das Modul:

sudo grep mein_prozess /var/log/audit/audit.log | audit2allow -M mein_modul

Dies erzeugt eine Quellcode-Datei (.te) und das kompilierte Policy-Paket (.pp)

Modul aktivieren

Laden Sie das kompilierte Paket abschließend in den Kernel:

sudo semodule -i mein_modul.pp

Initiale Einrichtung

Nach einer frischen SELinux-Installation und der Deinstallation von AppArmor wird das System oft mit unklaren AVC-Meldungen geflutet. Um das System initial wieder nutzbar zu machen, können Sie alle bisherigen Blockaden pauschal erfassen:

sudo grep "AVC" /var/log/audit/audit.log | audit2allow -M my_custom_policy

Laden Sie auch dieses Modul anschließend mit

sudo semodule -i my_custom_policy.pp

Hinweis

Diese "Holzhammer-Methode" eignet sich nur für die allererste Stabilisierung des Systems. Im späteren Betrieb sollten Sie Ausnahmen immer strikt nach Diensten getrennt erstellen.

---

← Zurück

Weiter →