Linux/SELinux/10 Systemd

SELinux-Zugriffskontrolle mit systemd

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 beispielsweise 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

SELinux-Zugriffsberechtigungen 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

Beispielsweise mussten Administratoren 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 10.1, „Zuordnung von Methodenaufrufen in systemd-Unit-Dateien zu SELinux-Zugriffsprüfungen“, ordnet Zugriffsprüfungen für Unit-Dateien zu, während Tabelle 10.2, „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

Zuordnung von 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

Zuordnung von Methodenaufrufen in systemd-Unit-Dateien zu 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

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

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	Stopp
PowerOff	Stopp
Reboot	Neustart
SetUserLinger	Stopp
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

Beispielsweise gibt der Befehl sesearch -A -s NetworkManager_t -c service Folgendes zurück

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

Beispielsweise listet der folgende Befehl alle Protokolle auf, 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)