Linux/SELinux/10 Systemd

Linux/SELinux/10 Systemd - SELinux-Zugriffskontrolle mit systemdn steuern

← Zurück

Weiter →

Beschreibung

Systemd

Nahezu jeder Dienst in Linux erzeugt beim Start oder im laufenden Betrieb Hilfsobjekte: Verzeichnisse unter /run, PID-Dateien, UNIX-Sockets, Journal-Verzeichnisse, temporäre Dateien, Caches und andere Betriebsdaten

Verzeichnisse wie /run oder /tmp können als temporäre Dateisysteme (tmpfs) eingehängt sein

• Das bedeutet, dass ihr Inhalt bei jedem Neustart des Servers vollständig gelöscht wird

Wenn ein Dienst (zum Beispiel ein Webserver oder ein DBMS) für seinen Betrieb ein eigenes Verzeichnis unter /run benötigt (zum Beispiel /run/myapp/), entstehen zwei Probleme

1. Das Verzeichnis muss bei jedem Systemstart erneut angelegt werden, bevor der Dienst versucht, darauf zuzugreifen
2. Wenn der Dienst das Verzeichnis selbst anlegt, kann es den Standardkontext des Elternverzeichnisses erben (zum Beispiel var_run_t)

• In einer strikten SELinux-Policy kann dem Dienst die Arbeit mit dem Basistyp var_run_t untersagt sein, sodass ein spezifischer Kontext erforderlich ist (zum Beispiel myapp_var_run_t)

systemd-tmpfiles

Zur Verwaltung temporärer Dateien und Verzeichnisse dient das Werkzeug systemd-tmpfiles

• Beim Systemstart (oder per Timer) liest es Konfigurationsdateien aus den Verzeichnissen /etc/tmpfiles.d/, /run/tmpfiles.d/ und /usr/lib/tmpfiles.d/ und erstellt, entfernt oder bereinigt Dateien und Verzeichnisse entsprechend den Regeln

systemd-tmpfiles ist eng mit SELinux integriert

• Beim Erzeugen eines beliebigen Objekts greift das Werkzeug automatisch auf die SELinux-Kontextdatenbank (file_contexts) zu
• Dadurch wird das korrekte Label automatisch gesetzt, ohne dass nach jedem Neustart manuell restorecon ausgeführt werden muss

Regeln

Regeln können unter folgenden Pfaden gefunden werden

• /usr/lib/tmpfiles.d/ — vordefinierte Regeln
• /run/tmpfiles.d/ — Runtime-Regeln
• /etc/tmpfiles.d/ — lokale und administrative Regeln

Die Regeln haben folgendes Format

Typ  Pfad  Modus  Benutzer  Gruppe  Alter  Argument

• Typ: Gibt an, was getan werden soll
  • d (Verzeichnis anlegen, falls es nicht existiert)
  • f (Datei anlegen)
  • z (SELinux-Kontext und Rechte wiederherstellen, ohne das Objekt zu erzeugen)
  • Z (SELinux-Kontext rekursiv wiederherstellen)
• Pfad: Absoluter Pfad zum Objekt
• Modus: Zugriffsrechte (zum Beispiel 0755)
• Benutzer/Gruppe (UID/GID): Eigentümer des Objekts

Regel anlegen

Hier wird der Prozess zur Vorbereitung einer Umgebung unter Verwendung des Typs httpd_runtime_t für einen neuen Dienst myapp demonstriert, der eine PID-Datei im Verzeichnis /run/myapp benötigt

Zunächst muss eine File-Context-Regel in die SELinux-Policy-Datenbank eingetragen werden, damit das System weiß, welcher Kontext für den benötigten Pfad erwartet wird

semanage fcontext -a -t httpd_runtime_t "/run/myapp(/.*)?"

Danach muss eine Konfigurationsdatei für den Dienst myapp erstellt werden

nano /etc/tmpfiles.d/myapp.conf

Inhalt der Datei

d /run/myapp 0755 root root - -
z /run/myapp 0755 root root - -

Erläuterung

• Die erste Zeile legt das Verzeichnis an, falls es noch nicht existiert
• Die zweite Zeile bringt das Verzeichnis explizit in den erwarteten Zustand zurück und stellt den SELinux-Kontext dafür wieder her

systemd erzeugt die Objekte beim Systemstart selbstständig, der Vorgang kann jedoch auch manuell ausgelöst werden

systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf

Ergebnis prüfen

ls -Zld /run/myapp
drwxr-xr-x. 2 root root system_u:object_r:httpd_runtime_t:s0 40 ... /run/myapp

Der Dienst systemd-tmpfiles hat das Verzeichnis erfolgreich mit dem erforderlichen Kontext vorbereitet

In modernen systemd-Versionen werden für einfache Aufgaben häufig Direktiven wie RuntimeDirectory= direkt in der Unit-Datei eines Dienstes (zum Beispiel in myapp.service) verwendet

• Diese Direktive arbeitet nach einem ähnlichen Prinzip: systemd erstellt das Verzeichnis vor dem Start des Dienstes und wendet darauf automatisch die Kontextregeln aus der SELinux-Datenbank an

tmpfiles.d bleibt jedoch für komplexere Szenarien, die Bereinigung alter Dateien und die Konfiguration gemeinsam genutzter Ressourcen unverzichtbar

← Zurück

Weiter →

RHEL

Beschreibung

Systemdienste werden vom systemd-Daemon gesteuert

Frühere Daemons konnten auf zwei Arten gestartet werden

• Beim Systemstart führte der System-V-Daemon init ein Skript namens init.rc aus, woraufhin dieses Skript den erforderlichen Daemon startete

Beispielsweise erhielt der Apache-Server, der beim Systemstart gestartet wurde, das folgende SELinux-Label:

system_u:system_r:httpd_t:s0

Ein Administrator startete das init.rc Skript manuell, wodurch der Daemon ausgeführt wurde

Wenn der Befehl service httpd restart auf dem Apache-Server aufgerufen wurde, sah das resultierende SELinux-Label wie folgt aus:

unconfined_u:system_r:httpd_t:s0

Bei manuellem Start übernahm der Prozess den Benutzerteil des SELinux-Labels, das ihn gestartet hatte, was die Labeling-Praktiken in den beiden oben genannten Szenarien inkonsistent machte

• Beim systemd-Daemon verlaufen die Übergänge ganz anders
• Da systemd alle Aufrufe zum Starten und Beenden von Daemons auf dem System unter Verwendung des Typs init_t verarbeitet, kann es den Benutzerteil des Labels überschreiben, wenn ein Daemon manuell neu gestartet wird
• Infolgedessen lauten die Labels in beiden oben genannten Szenarien wie erwartet system_u:system_r:httpd_t:s0 und die SELinux-Richtlinie könnte verbessert werden, um zu regeln, welche Domänen welche Einheiten steuern dürfen

Berechtigungen für Dienste

In früheren Versionen von Red Hat Enterprise Linux konnte ein Administrator anhand des Labels des System V-Init-Skripts steuern, welche Benutzer oder Anwendungen Dienste starten oder stoppen durften

• Jetzt startet und stoppt systemd alle Dienste, und Benutzer und Prozesse kommunizieren mit systemd über das Dienstprogramm systemctl
• Der systemd-Daemon kann die SELinux-Richtlinie abfragen und die Kennzeichnung des aufrufenden Prozesses sowie die Kennzeichnung der Unit-Datei, die der Aufrufer zu verwalten versucht, überprüfen und anschließend bei SELinux erfragen, ob dem Aufrufer der Zugriff gestattet ist
• Dieser Ansatz stärkt die Zugriffskontrolle auf kritische Systemfunktionen, zu denen das Starten und Beenden von Systemdiensten gehört

Administratoren mussten etwa zuvor dem NetworkManager erlauben, systemctl auszuführen, um eine D-Bus-Nachricht an systemd zu senden, das daraufhin den vom NetworkManager angeforderten Dienst startete oder stoppte

• Tatsächlich durfte der NetworkManager alles tun, was systemctl tun konnte
• Es war zudem unmöglich, Administratoren mit eingeschränkten Rechten so einzurichten, dass sie nur bestimmte Dienste starten oder stoppen konnten

Um diese Probleme zu beheben, fungiert systemd auch als SELinux-Zugriffsmanager

• Es kann das Label des Prozesses abrufen, der systemctl ausführt, oder des Prozesses, der eine D-Bus-Nachricht an systemd gesendet hat
• Der Daemon sucht dann nach dem Label der Unit-Datei, die der Prozess konfigurieren wollte
• Schließlich kann systemd Informationen vom Kernel abrufen, wenn die SELinux-Richtlinie den spezifischen Zugriff zwischen dem Prozess-Label und dem Unit-Datei-Label erlaubt
• Das bedeutet, dass eine kompromittierte Anwendung, die für einen bestimmten Dienst mit systemd interagieren muss, nun durch SELinux eingeschränkt werden kann
• Richtlinienentwickler können diese fein abgestimmten Steuerungen auch nutzen, um Administratoren einzuschränken

Die Richtlinienänderungen beinhalten eine neue Klasse namens service, mit den folgenden Berechtigungen

class service
{
       start
       stop
       status
       reload
       kill
       load
       enable
       disable
}

Beispielsweise kann ein Richtlinienentwickler nun einer Domäne erlauben, den Status eines Dienstes abzurufen oder einen Dienst zu starten und zu stoppen, jedoch nicht, einen Dienst zu aktivieren oder zu deaktivieren

• Zugriffskontrolloperationen in SELinux und systemd stimmen nicht in allen Fällen überein
• Es wurde eine Zuordnung definiert, um systemd-Methodenaufrufe mit SELinux-Zugriffsprüfungen abzugleichen
• Tabelle „Zuordnung von Methodenaufrufen in systemd-Unit-Dateien zu SELinux-Zugriffsprüfungen“, ordnet Zugriffsprüfungen für Unit-Dateien zu, während Tabelle „Zuordnung von allgemeinen systemd-Systemaufrufen zu SELinux-Zugriffsprüfungen“, Zugriffsprüfungen für das System im Allgemeinen abdeckt
• Wird in keiner der beiden Tabellen eine Übereinstimmung gefunden, wird die Systemprüfung „undefined“ aufgerufen

Methodenaufrufe

Systemd-Unit-Datei-Methodenaufrufen

systemd-Unit-Datei-Methodenaufrufen zu SELinux-Zugriffsprüfungen

systemd-Unit-Datei-Methode	SELinux-Zugriffsprüfung
DisableUnitFiles	disable
EnableUnitFiles	enable
GetUnit	status
GetUnitByPID	status
GetUnitFileState	status
Kill	stop
KillUnit	stop
LinkUnitFiles	enable
ListUnits	status
LoadUnit	status
MaskUnitFiles	disable
PresetUnitFiles	aktivieren
ReenableUnitFiles	aktivieren
Reexecute	starten
Reload	neu laden
ReloadOrRestart	starten
ReloadOrRestartUnit	starten
ReloadOrTryRestart	starten
ReloadOrTryRestartUnit	start
ReloadUnit	reload
ResetFailed	stop
ResetFailedUnit	stop
Restart	start
RestartUnit	start
Start	start
StartUnit	start
StartUnitReplace	start
Stop	stop
StopUnit	stop
TryRestart	start
TryRestartUnit	start
UnmaskUnitFiles	enable

Methodenaufrufen in systemd-Unit-Dateien und SELinux-Zugriffsprüfungen

Methode in systemd-Unit-Datei	SELinux-Zugriffsprüfung
DisableUnitFiles	deaktivieren
EnableUnitFiles	aktivieren
GetUnit	Status
GetUnitByPID	status
GetUnitFileState	status
Kill	stop
KillUnit	stop
LinkUnitFiles	enable
ListUnits	status
LoadUnit	status
MaskUnitFiles	deaktivieren
PresetUnitFiles	aktivieren
ReenableUnitFiles	aktivieren
Reexecute	starten
Reload	neu laden
ReloadOrRestart	starten
ReloadOrRestartUnit	starten
Neu laden oder Neustart versuchen	starten
Neu laden oder Neustart versuchen (Einheit)	starten
Einheit neu laden	neu laden
Zurücksetzen fehlgeschlagen	stoppen
Zurücksetzen fehlgeschlagen (Einheit)	stoppen
Neustart	starten
Einheit neu starten	starten
Start	start
StartUnit	start
StartUnitReplace	start
Stop	stop
StopUnit	stop
TryRestart	start
TryRestartUnit	start
UnmaskUnitFiles	enable

Systemd- und SELinux-Zugriffsprüfungen

Zuordnung von allgemeinen systemd-Systemaufrufen zu SELinux-Zugriffsprüfungen

Allgemeiner systemd-Systemaufruf	SELinux-Zugriffsprüfung
ClearJobs	reboot
FlushDevices	halt
Get	status
GetAll	status
GetJob	status
GetSeat	status
GetSession	status
GetSessionByPID	status
GetUser	status
Halt	halt
Introspect	status
KExec	reboot
KillSession	halt
KillUser	halt
ListJobs	status
ListSeats	status
ListSessions	status
ListUsers	status
LockSession	halt
PowerOff	halt
Reboot	reboot
SetUserLinger	halt
TerminateSeat	halt
TerminateSession	halt
TerminateUser	halt

SELinux-Richtlinie für einen Systemdienst

Mit dem Dienstprogramm sesearch können Sie Richtlinienregeln für einen Systemdienst auflisten

Beispiel

sesearch -A -s NetworkManager_t -c service
allow NetworkManager_t dnsmasq_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t nscd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t ntpd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t pppd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t polipo_unit_file_t : service { start stop status reload kill load } ;

SELinux und journald

In systemd ist der journald Daemon (auch bekannt als systemd-journal) die Alternative zum syslog Dienst, einem Systemdienst, der Protokolldaten sammelt und speichert

• Er erstellt und verwaltet strukturierte und indizierte Journale auf der Grundlage von Protokollinformationen, die vom Kernel, von Benutzerprozessen über die libc '‚'syslog()‘ -Funktion, aus der Standard- und Fehlerausgabe von Systemdiensten oder über seine native API empfangen werden
• Er sammelt implizit zahlreiche Metadatenfelder für jede Protokollmeldung auf sichere Weise

Der systemd-journal -Dienst kann zusammen mit SELinux verwendet werden, um die Sicherheit zu erhöhen

• SELinux kontrolliert Prozesse, indem es ihnen nur erlaubt, das zu tun, wofür sie vorgesehen sind; manchmal sogar noch weniger, je nach den Sicherheitszielen des Policy-Autors
• Beispielsweise verhindert SELinux, dass ein kompromittierter ntpd -Prozess etwas anderes tut, als die Netzwerkzeit zu verwalten
• Der ntpd -Prozess sendet jedoch syslog -Meldungen, sodass SELinux dem kompromittierten Prozess erlauben würde, diese Meldungen weiterhin zu senden
• Der kompromittierte ntpd könnte syslog-Meldungen so formatieren, dass sie denen anderer Daemons entsprechen, und damit möglicherweise einen Administrator irreführen oder, schlimmer noch, ein Dienstprogramm, das die syslog -Datei ausliest, dazu bringen, das gesamte System zu kompromittieren

Der systemd-journal -Daemon überprüft alle Protokollmeldungen und fügt ihnen unter anderem SELinux-Labels hinzu

• So lassen sich Unstimmigkeiten in Protokollmeldungen leicht erkennen und Angriffe dieser Art verhindern, bevor sie stattfinden
• Mit dem Dienstprogramm journalctl können Sie die Protokolle der systemd Journale abfragen
• Wenn keine Befehlszeilenargumente angegeben werden, listet dieses Dienstprogramm den vollständigen Inhalt des Journals auf, beginnend mit den ältesten Einträgen
• Um alle auf dem System erzeugten Protokolle anzuzeigen, einschließlich der Protokolle für Systemkomponenten, führen Sie journalctl als Root aus
• Wenn Sie es als Nicht-Root-Benutzer ausführen, beschränkt sich die Ausgabe nur auf Protokolle, die sich auf den aktuell angemeldeten Benutzer beziehen

Beispiel

Auflisten von Protokollen mit journalctl

• Es ist möglich, journalctl zu verwenden, um alle Protokolle aufzulisten, die sich auf ein bestimmtes SELinux-Label beziehen

Auflisten alle Protokolle, die unter dem Label system_u:system_r:policykit_t:s0 protokolliert wurden

sudo journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0
21. Okt. 10:22:42 localhost.localdomain polkitd[647]: polkitd Version 0.112 gestartet
21. Okt. 10:22:44 localhost.localdomain polkitd[647]: Regeln aus dem Verzeichnis /etc/polkit-1/rules.d werden geladen
21. Okt. 10:22:44 localhost.localdomain polkitd[647]: Lade Regeln aus dem Verzeichnis /usr/share/polkit-1/rules.d
21. Okt. 10:22:44 localhost.localdomain polkitd[647]: Laden, Kompilieren und Ausführen von 5 Regeln abgeschlossen
21. Okt. 10:22:44 localhost.localdomain polkitd[647]: Name org.freedesktop.PolicyKit1 auf dem Systembus abgerufen 21. Okt. 10:23:10 localhost polkitd [647]: Authentifizierungsagent für unix-session:c1 registriert (Systembus-Name: 1.49, Objektpfad /org/freedesktop/PolicyKit1/AuthenticationAgent, Locale en_US.UTF-8) (vom Bus getrennt)
21. Okt. 10:23:35 localhost polkitd[647]: Authentifizierungsagent für unix-session:c1 abgemeldet (Systembusname :1.80 [/usr/bin/gnome-shell --mode=classic], Objektpfad /org/freedesktop/PolicyKit1/AuthenticationAgent, Locale en_US.utf8)

Weitere Informationen zu journalctl finden Sie auf der Manpage journalctl(1)

Systemd und Temporäre Verzeichnisse

• Datei und Verzeichnis Erstellung durch Systemd
• SELinux Context setzen via systemd-tmpfiles

← Zurück

Weiter →