Zum Inhalt springen

Linux/SELinux/06 Benutzer

Aus Foxwiki

Linux/SELinux/06 Benutzer

← Zurück
Weiter →

Benutzerkontext

Bis zu diesem Punkt wurde betrachtet, wie Prozesse mit Dateien interagieren (Type Enforcement). Doch woher erhält ein Prozess – zum Beispiel die Shell bash – überhaupt seinen Kontext, wenn sich ein realer Benutzer am Server anmeldet?

Hier wird die Teilsystematik RBAC (Role-Based Access Control) sowie die Begriffe Benutzerkontext und SELinux user eingeführt.

Genau auf dieser Ebene entscheidet SELinux
  • welcher Benutzerkontext einer neuen Sitzung zugewiesen wird
  • welche Rollen dieser Sitzung erlaubt sind
  • und damit, in welche Domänen Prozesse gelangen können, die unter diesem Benutzer gestartet werden

Kontext

Nach erfolgreicher Anmeldung und nach Abschluss des Zuordnungsprozesses (Mappings) erhält der Prozess der Benutzershell (zum Beispiel bash) seinen endgültigen SELinux-Kontext. Dieser lässt sich mit dem bereits bekannten Befehl id -Z anzeigen.

Es wird der Kontext staff_u:staff_r:staff_t:s0-s0:c0.c1023 betrachtet.

Dieser Kontext besteht aus vier klassischen SELinux-Elementen:

  • SELinux User ('staff_u'): Die Benutzerkennung innerhalb der Sicherheitspolicy. Sie wird beim Login durch das PAM-Modul fest zugewiesen und ändert sich in der Regel während der gesamten Sitzung nicht. Selbst wenn mit su oder sudo zum Linux-Benutzer root gewechselt wird, bleibt der ursprüngliche SELinux User in den meisten Konfigurationen unverändert.
  • Role ('staff_r'): Die Benutzerrolle. Dies ist das zentrale Element von RBAC und fungiert als „Bindeglied“ zwischen Benutzer und Prozess. Ein SELinux-Benutzer darf nur in die Rollen eintreten, die ihm durch die Policy explizit erlaubt sind.
  • Type / Domain ('staff_t'): Die Prozessdomäne (Grundelement des Type Enforcement). Wie bekannt, bestimmt letztlich die Domäne, welche Dateien gelesen und welche Programme ausgeführt werden dürfen. Die Rolle wiederum bestimmt, in welche Domänen ein Übergang überhaupt zulässig ist.
  • MLS/MCS Range ('s0-s0:c0.c1023'): Sensitivitätsstufen und Kategorien. (Für Kategorien gibt es eine eigene Lektion; an dieser Stelle ist nur wichtig, dass der Bereich von 0 bis 1023 bedeutet: Von dieser Seite her bestehen für den Benutzer keine Einschränkungen.)

SELinux user

Linux user vs. SELinux user

Linux user ist das gewöhnliche Betriebssystemkonto: UID, primäre Gruppe, ergänzende Gruppen, Home-Verzeichnis, Shell, der Eintrag in /etc/passwd und die zugehörigen Authentifizierungs- und Autorisierungsmechanismen.

SELinux user ist eine interne Entität der Sicherheitspolicy, die festlegt, welche Rollen (roles) und Sicherheitsstufen (MLS/MCS) einer Person nach erfolgreicher Anmeldung zur Verfügung stehen.

Der Name endet in der Regel auf _u (zum Beispiel user_u, staff_u, sysadm_u, unconfined_u).

Aus Sicht der Policy ist der SELinux user eine Abstraktionsebene zwischen Linux user und role. Genau der SELinux User verbindet den realen Login-Namen mit dem Satz von Rollen und Levels, die ihm erlaubt sind.

Anzeige der Zuordnung

Die Beziehung Linux user <-> SELinux user wird durch einen separaten Mechanismus zur Zuordnung von Login-Namen zu SELinux Usern definiert. Auf administrativer Ebene lässt sich dies mit semanage login -l anzeigen. 

semanage login -l

Ausgabe: 

Login Name           SELinux User         MLS/MCS Range        Service
__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
sddm                 xdm                  s0-s0                *
    • Die Zeile __default__ wird genauer betrachtet.
    • Dies ist die wichtigste Regel für gewöhnliche Benutzer. Wenn sich etwa der Student bob oder die Entwicklerin alice anmeldet und ihre Namen nicht in dieser Tabelle stehen, wendet SELinux auf sie den Eintrag __default__. In diesem Fall wird jeder neue Benutzer automatisch zu unconfined_u – also zu einem Benutzer ohne strenge Einschränkungen – mit dem vollständigen Kategoriesatz c0.c1023.

Für die Zuordnung von SELinux Usern zu ihren erlaubten Rollen wird semanage user -l verwendet. 

semanage user -l

In der Ausgabe sind die Spalten für SELinux User, Label-Prefix, MLS/MCS-Kategorien und die zugehörigen Rollen zu sehen: 

                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

guest_u         user       s0         s0                             guest_r
root            sysadm     s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r
staff_u         staff      s0         s0-s0:c0.c1023                 staff_r sysadm_r
sysadm_u        sysadm     s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
unconfined_u    unconfined s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xdm             user       s0         s0                             system_r xdm_r
xguest_u        user       s0         s0                             xguest_r

User Mapping

Mapping Linux user -> SELinux user ist die Regel, die einen Linux-Benutzernamen mit einem SELinux User verknüpft.

Solange das System nicht entschieden hat, auf welchen SELinux User ein Linux-Login abgebildet werden soll, kann es noch nicht korrekt bestimmen, welche Rollen für die neue Sitzung zulässig sind. Deshalb ist das Mapping die erste RBAC-Aktion beim Login: Es legt die anfängliche SELinux-Identität des Benutzers fest und begrenzt damit, was im weiteren Verlauf überhaupt möglich ist.

Aus administrativer Sicht ist semanage login -l das Werkzeug zur Anzeige des Mappings. Auf Konfigurationsebene wird die Datei seusers gelesen (Pfad: /etc/selinux/{POLICY}/seusers).

Format eines Eintrags in der Datei
[%group_id]|[user_id]:seuser_id[:range]

In diesem Format wird auch der spezielle Fallback-Eintrag __default__ unterstützt, der bereits zuvor erwähnt wurde.

Arten von Mappings

System-Mappings sind die Basiseinträge der aktiven Policy, die bereits im System vorhanden sind und das Ausgangsverhalten definieren. Auf einem typischen System sind dies mindestens __default__, root und system_u. Genau diese Einträge bestimmen das Verhalten „out of the box“, wenn der Administrator nichts verändert hat.

Lokale Mappings sind administrative Änderungen, die bereits auf einem konkreten Host vorgenommen wurden. Für semanage login lassen sich solche Änderungen mit folgendem Befehl anzeigen: 

semanage login -l -C

Die Option -C (Customizations) in semanage login zeigt genau die lokal hinzugefügten Einträge an.

Logik der Auswahl eines Mappings

  • Wenn für den Linux-Benutzer alice ein separater Eintrag angelegt wurde (explizites Mapping), dann verwendet SELinux beim Login von alice genau diese SELinux-Identität und nicht die allgemeine Regel __default__.
    • Ein Mapping kann mit dem folgenden Befehl angelegt werden:
semanage login -a -s user_u alice
    • Parameter -a – hinzufügen
    • Parameter -s – „SELinux user“
  • Wenn kein separater Eintrag für den Login existiert, erscheint der Benutzer nicht als eigene Zeile in semanage login -l, und es wird das Standard-Mapping verwendet.
    • In diesem Fall greift die Regel __default__. In einer unveränderten targeted-policy (oder default-policy unter Debian) wird ein Linux user ohne explizites Mapping auf unconfined_u abgebildet.

Gruppen-Mappings

Das Format von seusers und semanage login unterstützt nicht nur die Zuordnung per Benutzername, sondern auch die Zuordnung über eine Linux-Gruppe. Dazu wird der Gruppenname mit dem Präfix % angegeben. 

semanage login -a -s staff_u %engineering

Ein solcher Mechanismus ist dort nützlich, wo RBAC nicht für jeden Login manuell vergeben wird, sondern über die Zugehörigkeit zu einer administrativen oder funktionalen Gruppe.

Dienstspezifische Mappings

Neben der allgemeinen Datei seusers unterstützt SELinux auch dienstspezifische Mappings. Dazu werden zusätzliche Dateien im Verzeichnis /etc/selinux/{POLICY}/logins verwendet – jeweils eine Datei pro Linux-Benutzername. Diese Dateien ermöglichen es, dass derselbe Linux-Benutzer je nach Anmeldedienst einen unterschiedlichen SELinux User erhält.

Format eines Eintrags
service:seuser[:range]

Beispiel für den Inhalt der Datei /etc/selinux/targeted/logins/alice: 

login:user_u:s0
gdm-password:staff_u:s0
Erläuterung
  • login:user_u:s0: Wenn sich der Benutzer an der lokalen Konsole anmeldet (Dienst login oder tty), ist das Vertrauensniveau niedriger; entsprechend wird user_u verwendet.
  • gdm-password:staff_u:s0: Wenn sich der Benutzer über die grafische GNOME-Oberfläche anmeldet, ist das Vertrauensniveau höher; staff_u erlaubt den Erwerb administrativer Rechte.

Wichtiger Hinweis

Dienstspezifische Mappings funktionieren nur für SELinux-kompatible Anwendungen, die bei der Auswahl des SELinux User die Funktion getseuser() aufrufen. Das heißt konkret: nur dann, wenn die Anwendung pam_selinux zur Auswahl des Benutzerkontexts verwendet.

Leider ist OpenSSH kein gutes Beispiel für die Demonstration dieses Mechanismus, da es das Basis-Mapping aus der Datei seusers in seiner eigenen Implementierung verwendet (über die Funktion getseuserbyname()).

Löschen eines Mappings

Wenn für einen Benutzer ein eigener Mapping-Eintrag angelegt wurde, müssen das Löschen des Linux-Kontos und das Löschen des SELinux-Mappings in folgender Reihenfolge erfolgen:

Benutzer aus dem System entfernen
userdel -r newuser
Mapping entfernen
semanage login -d newuser

Wenn ein Linux-Benutzer nur unter __default__ lief und keinen eigenen Eintrag in semanage login hatte, muss nach userdel kein persönliches SELinux-Mapping entfernt werden – ein solches existierte in diesem Fall nicht.

Rollen

Die Zugriffskette wird nun mit dem bereits vorhandenen Wissen über SELinux-Entitäten betrachtet: 

Linux user 
 -> SELinux user 
  -> erlaubte Rollen 
   -> erlaubte Prozessdomänen 
    -> Regeln allow/type_transition/entrypoint/constraints 
     -> tatsächlicher Zugriff

Damit fungiert die Rolle als Bindeglied: Einem SELinux User kann die Nutzung einer begrenzten Menge von Rollen erlaubt sein, und jede Rolle besitzt wiederum eine strikt begrenzte Menge von Domänen (Typen), in die ein Übergang zulässig ist.

Für jede Rolle gibt es in der Policy häufig einen entsprechenden Standard-Domänentyp und einen Standard-Benutzer, zum Beispiel:

  • user_u-user_r-user_t,
  • staff_u-staff_r-staff_t, und so weiter.

Wenn eine Rolle angegeben ist, aber kein Domänentyp explizit genannt wird, wird die Domäne automatisch aus der Rolle abgeleitet.

Standardrollen

Für jede Rolle existieren in der targeted/default-Policy in der Regel eine zugehörige Startdomäne und ein passender Benutzer. Die wichtigsten typischen Szenarien sind:

  • unconfined_r: Die Standardrolle für gewöhnliche Benutzer. Sie schränkt Übergänge in andere Domänen praktisch nicht ein. Sie ist mit der Domäne unconfined_t verknüpft.
  • user_r: Eine strikt eingeschränkte Benutzerrolle. Sie verbietet die Ausführung von su oder sudo, blockiert die Ausführung von Binärdateien aus /tmp und aus Home-Verzeichnissen. Sie ist mit der Domäne user_t verknüpft.
  • staff_r: Eine Rolle für Junior-Administratoren. Sie ähnelt user_r, erlaubt aber das Erhöhen von Privilegien über sudo, um in eine administrative Rolle zu wechseln. Sie ist mit staff_t verknüpft.
  • sysadm_r: Die Rolle des Systemadministrators. Sie erlaubt die Systemverwaltung und den Übergang in Domänen von Systemdiensten, um diese neu zu starten. Sie ist mit sysadm_t verknüpft.

Systemdienste

Wenn systemd einen Dienst startet, läuft der Prozess in der Regel in der Systemrolle system_r: 

system_u:system_r:httpd_t:s0

Die Isolation der Zugriffe von Diensten wird hier ausschließlich über die Domänen geregelt.

Default Role & Context

Nachdem ein Linux-Benutzer einem SELinux User zugeordnet wurde, muss das System entscheiden, in welchem SELinux-Kontext seine erste Benutzershell oder Sitzung gestartet wird.

Hier werden die Mechanismen zur Bestimmung der Default Role (Standardrolle) und des Default Context (Startkontext) betrachtet.

Der Ablauf zur Zuweisung des Startkontexts beim Login sieht wie folgt aus:

  1. Der Benutzer gibt Login und Passwort ein.
  2. Das PAM-Subsystem arbeitet die Konfiguration ab (insbesondere das Modul pam_selinux.so).
  3. PAM prüft das Mapping (semanage login -l), um festzustellen, welcher SELinux User diesem Linux-Benutzer zugeordnet ist (zum Beispiel Linux user joe -> SELinux user staff_u).
  4. Anschließend fragt PAM die SELinux-Konfiguration ab, um zu bestimmen, welche Rolle und welche Domäne für diesen Benutzer staff_u standardmäßig (default) sind.
  5. Der Benutzer erhält seinen Startkontext (zum Beispiel staff_u:staff_r:staff_t:s0) und bekommt Zugriff auf die Shell.

default_contexts

Die wichtigste Datei für die Auswahl der initialen Domäne für eine bestimmte Rolle beim Login ist /etc/selinux/<POLICY>/contexts/default_contexts.

Format der Einträge: 

{source_context} {target_context} {target_context2} {target_context3}
  • Es werden einige Zeilen betrachtet:
system_r:sshd_t:s0 user_r:user_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 unconfined_r:unconfined_t:s0
staff_r:staff_sudo_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0

Wenn ein Dienst mit der Rolle system_r und der Domäne sshd_t (also faktisch der sshd-Daemon) die Erzeugung eines Prozesses initiiert, dürfen diesem nur bestimmte Kontexte zugewiesen werden, und für jeden dieser Kontexte ist ein entsprechender Typ (eine Domäne) definiert.

Ebenso gilt
Wenn ein Prozess mit der Rolle staff_r und der Domäne staff_sudo_t einen Unterprozess erzeugt, dann dürfen diesem nur streng definierte Kontexte zugewiesen werden: sysadm_r:sysadm_t und staff_r:staff_t.

Wichtiger Hinweis

Neben dem globalen default_contexts existieren auch benutzerspezifische Dateien im Verzeichnis /etc/selinux/targeted/contexts/users/. Wenn sich dort eine Datei mit dem Namen eines konkreten SELinux-Benutzers befindet (zum Beispiel staff_u), liest das System zuerst diese Datei; findet es dort keine passende Regel, greift es auf das globale default_contexts zurück.

default_type

Ein weiterer Mechanismus zur Zuordnung einer Domäne zu einer bereits bekannten Rolle, der von einigen SELinux-Werkzeugen verwendet wird – zum Beispiel von newrole.

Die Datei befindet sich unter folgendem Pfad: /etc/selinux/<POLICY>/contexts/default_type

Analyse von RBAC mit seinfo

seinfo ist ein Werkzeug zum Lesen und Analysieren der bereits kompilierten aktiven SELinux-Policy.

Für das Thema RBAC sind in seinfo vor allem drei Entitäten von Interesse:

  • SELinux user
  • role
  • domain / type

Verwendung

Um Rollen in der Policy anzuzeigen, wird seinfo mit dem Parameter -r verwendet. 

seinfo -r

Dieser Befehl gibt die Liste der in der aktiven Policy definierten Rollen aus.

  • Für eine detailliertere Ausgabe der Rollen und der mit ihnen verknüpften Domänen wird zusätzlich der Parameter -x verwendet.
seinfo -r -x

Hier lässt sich erkennen, auf welche Domänen die Benutzersitzung für jede Rolle beschränkt ist.

Beispielausgabe
...
role dbadm_r types { chkpwd_t dbadm_dbusd_t dbadm_t mysqld_t run_init_t updpwd_t };
role guest_r types { chfn_t chkpwd_t guest_dbusd_t guest_t loadkeys_t nscd_t passwd_t updpwd_t };
role logadm_r types { auditctl_t chkpwd_t logadm_dbusd_t logadm_t run_init_t updpwd_t };
role nx_server_r types { nx_server_ssh_t nx_server_t };
...

Die Ausgabe kann eingeschränkt werden, indem die gewünschte Rolle direkt nach -r angegeben wird. 

seinfo -r user_r -x

Ebenfalls nützlich ist die Anzeige detaillierter Informationen über Benutzer. 

seinfo -u -x

Die Ausgabe dieses Befehls macht sichtbar, welche konkreten Rollen welchem SELinux User zugewiesen werden können.

Beispielausgabe
Users: 9
   user guest_u roles guest_r level s0 range s0;
   user root roles { staff_r sysadm_r system_r } level s0 range s0 - s0:c0.c1023;
   user staff_u roles { staff_r sysadm_r } level s0 range s0 - s0:c0.c1023;
   user sysadm_u roles sysadm_r level s0 range s0 - s0:c0.c1023;
   user system_u roles system_r level s0 range s0 - s0:c0.c1023;
   user unconfined_u roles { system_r unconfined_r } level s0 range s0 - s0:c0.c1023;
   user user_u roles user_r level s0 range s0;
   user xdm roles { system_r xdm_r } level s0 range s0;
   user xguest_u roles xguest_r level s0 range s0;

Rollenwechsel

Nach der Analyse der Policy-Struktur stellt sich die nächste praktische Frage: Wie wird in eine andere bereits erlaubte Rolle gewechselt, oder wie wird ein einzelnes Programm in einem anderen zulässigen Kontext gestartet?

newrole

newrole erzeugt eine neue Benutzershell in einem anderen SELinux-Kontext.

Dieses Werkzeug wird verwendet, wenn der aktuelle Login-Kontext bereits existiert, aber ohne erneute Anmeldung in eine andere Rolle gewechselt werden soll, zum Beispiel:

  • die aktuelle Sitzung startet etwa als staff_u:staff_r:staff_t:s0
    • anschließend wird eine neue untergeordnete Shell bereits im Kontext staff_u:sysadm_r:sysadm_t:s0 gestartet

Verwendung

Beispiel für einen Rollenwechsel unter dem Benutzer bob, der standardmäßig auf staff_u gemappt ist: 

$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ newrole -r sysadm_r
Password:
$ id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

Wenn kein Typ explizit angegeben wird, wird der Standardwert verwendet.

  • In einigen Fällen ist es sinnvoll, sowohl Rolle als auch Typ explizit anzugeben:
newrole -r system_r -t httpd_t

Dieses Werkzeug ist kein Mittel zur Umgehung der Policy. newrole arbeitet innerhalb der bereits bestehenden RBAC-Einschränkungen.

runcon

Während newrole eine neue Shell startet und den Kontext der gesamten untergeordneten Sitzung ändert, startet runcon einen einzelnen konkreten Befehl in dem angegebenen Kontext.

Verwendung

Beispiel für den Start von id -Z im Kontext staff_r:staff_t: 

runcon -r staff_r -t staff_t -- id -Z

Es kann auch ein vollständiger Kontext übergeben werden: 

runcon staff_u:staff_r:staff_t:s0 -- id -Z

Wichtiger Hinweis

Unter Debian und in einer Reihe anderer SELinux-Konfigurationen kann runcon selbst für genau denselben Kontext, der dem Benutzer bereits zugewiesen ist, mit Permission denied fehlschlagen. Der Grund ist, dass runcon eine explizite Kontextsetzung für die Klasse process verwendet und von der Permission setexec in der aktiven Policy abhängt.

Ob runcon verwendet werden darf, lässt sich wie folgt prüfen (am Beispiel von staff_t): 

sesearch -A -s staff_t -t staff_t -c process -p setexec

sudo und SELinux-Rollen

In einem SELinux-System beschränkt sich sudo nicht nur auf den Wechsel der effektiven UID. Wenn SELinux unterstützt wird, kann es an der Bildung des Ziel-Sicherheitskontexts (target security context) des gestarteten Prozesses beteiligt sein, insbesondere – die SELinux-Rolle (role) und den SELinux-Typ (type) festlegen.

Somit wird sudo zu einem Integrationspunkt zwischen zwei unabhängigen Mechanismen:

  • der Privilegiendelegation auf Ebene des klassischen Unix/Linux-Modells;
  • der Kontrolle des zulässigen Ausführungskontexts auf Ebene der SELinux-Policy.

sudo wird in SELinux auch als Mechanismus zum Starten eines Prozesses mit einer bestimmten Rolle und einem bestimmten Typ verwendet.

Hierfür werden Kommandozeilenparameter verwendet:

  • -r — SELinux-Zielrolle
  • -t — SELinux-Zieltyp

Sowie SELinux-spezifische Parameter in sudoers:

  • ROLE=...
  • TYPE=...

SELinux-Parameter für sudoers

Die Konfiguration zum Festlegen von Rolle und Typ für einen bestimmten Benutzer bei jedem Aufruf von sudo in seinem Namen sieht wie folgt aus: 

bob ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t /usr/bin/systemctl
  • der Benutzer bob hat das Recht, /usr/bin/systemctl über sudo auszuführen
  • der Befehl muss in der SELinux-Rolle sysadm_r ausgeführt werden
  • der Prozess muss im SELinux-Typ sysadm_t erstellt werden

Darüber hinaus ist die Festlegung von Standardparametern über Defaults möglich: 

Defaults role=sysadm_r
Defaults type=sysadm_t

sudo verwendet beim Ausführen des Befehls die angegebenen Werte als default role/type, sofern diese nicht überschrieben werden durch:

  • einen anderen Eintrag in sudoers
  • die Kommandozeilenparameter -r und -t

Praxis

Wechsel in eine andere Rolle über sudo

Als Beispiel erstellen wir den Benutzer joe, dem der Wechsel von der Rolle staff_r zu sysadm_r zur Verfügung stehen wird.

Überprüfen wir zunächst sofort, ob es staff_u erlaubt ist, die Rolle sysadm_r zu verwenden: 

semanage user -l | grep staff_u

Erstellen des Benutzers und des Mappings (Zuweisung) Linux-User - SELinux-User: 

adduser joe
semanage login -a -s staff_u joe

semanage login legt den anfänglichen Parameter für den SELinux-User fest, von dem bereits die Menge der zulässigen Rollen und der Startkontext abhängen: 

staff_u:staff_r:staff_t:s0-s0:c0.c1023

Wiederherstellen der Labels des Home-Verzeichnisses: 

restorecon -R -F -v /home/joe

Dieser Schritt ist nach einer Änderung der SELinux-Identität des Benutzers nützlich, damit das Home-Verzeichnis und die darin eingebetteten Objekte die erwarteten Dateikontexte erhalten.

Erstellen einer Regel in /etc/sudoers.d/: 

cat << EOF > /etc/sudoers.d/10-selinux
joe ALL=(ALL:ALL) TYPE=sysadm_t ROLE=sysadm_r ALL
EOF

Diese Regel verlangt explizit, dass der Befehl in einem Kontext mit der angegebenen Rolle und Domäne ausgeführt wird.

Wir versuchen, uns als Benutzer joe anzumelden, und überprüfen die Kontexte vor und nach der Rechteausweitung über sudo: 

joe@server:~$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
joe@server:~$ sudo -i
[sudo] password for joe:
root@server:~# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

Wir versuchen, einen Neustart von sshd durchzuführen: 

systemctl restart sshd

Ohne eine Regel in sudoers, die den Rollenwechsel erlaubt, wäre die Sitzung im Kontext staff_u:staff_r:staff_t geblieben, was bedeutet, dass ein Neustart des Dienstes unmöglich geworden wäre.

Es ist wichtig zu verstehen, dass ein erfolgreicher Wechsel über sudo von gleich mehreren Bedingungen abhängt:

  • Der Linux-User muss dem korrekten SELinux-User zugeordnet sein
  • Der SELinux-User muss Zugriff auf die erforderliche Rolle haben
  • sudoers muss die erforderlichen Felder ROLE= und TYPE= enthalten
  • Die Richtlinie (Policy) muss den entsprechenden Übergang zulassen

Rollenspezifische Booleans

Rollenspezifische Booleans als Konfiguration des Rollenverhaltens

Hier wird gezeigt, wie Booleans als Mittel zur Feinabstimmung des zulässigen Verhaltens der Domäne, durch die eine bestimmte Rolle implementiert wird, verwendet werden.

Role booleans

Die wichtigste Gruppe von Schaltern (Booleans) für Rollen in RHEL ist die Familie *_exec_content. Sie steuern, ob die entsprechende Benutzerdomäne ausführbare Dateien und Skripte aus Verzeichnissen ausführen darf, in denen der Benutzer Schreibrechte hat (normalerweise das Home-Verzeichnis mit dem Typ user_home_t und temporäre Ordner mit dem Typ user_tmp_t).

Die wichtigsten Booleans dieser Gruppe
  • guest_exec_content/xguest_exec_content — für Gastdomänen (guest_t, xguest_t)
  • user_exec_content — für normale Benutzer (user_t)
  • staff_exec_content — für Junior-Administratoren (staff_t)
  • sysadm_exec_content — für Systemadministratoren (sysadm_t)

Das Deaktivieren dieser Booleans (auf off stellen) ist ein Schutz vor Exploits und Malware. Selbst wenn ein Angreifer (oder der Benutzer selbst) ein Skript nach /tmp oder ~ herunterlädt, lässt das System die Ausführung nicht zu, da der Prozess nicht das execute-Recht für diese Dateitypen besitzt.

User booleans

Während die Gruppe *_exec_content die Codeausführung streng kontrolliert, steuern andere Benutzerschalter (User booleans) den Zugriff auf Systemressourcen, das Netzwerk und die Interaktion mit Diensten.

Sie ermöglichen es dem Administrator, grundlegenden Rollen gezielt Systemprivilegien zu gewähren oder zu entziehen, ohne root-Rechte vergeben oder neue Richtlinien schreiben zu müssen.

Die wichtigsten Booleans dieser Gruppe
  • user_dmesg — ob es normalen Benutzern (user_t) erlaubt wird, Kernel-Logs über den Befehl dmesg zu lesen
    • Die Deaktivierung ist nützlich zum Schutz vor Informationslecks, da in den Systemprotokollen oft Hardware-Daten, Speicheradressen und andere für einen Angreifer potenziell nützliche Informationen auftauchen.
  • user_ping — ob es Benutzern (user_t) erlaubt wird, den Befehl ping zu verwenden (Erstellen von Raw-Sockets)
    • Die Deaktivierung ist nützlich, um die Netzwerkaktivität einzuschränken. Wenn der Boolean auf off gesetzt ist, kann ein kompromittiertes Konto eines normalen Benutzers das interne Unternehmensnetzwerk nicht scannen, keinen ICMP-Flood auslösen oder das ICMP-Protokoll zur verdeckten Exfiltration gestohlener Daten verwenden.
  • user_tcp_server — Ausführen eigener Netzwerkdienste
    • Die Deaktivierung ist nützlich, um eine Vielzahl verschiedener Netzwerkbedrohungen, wie z.B. Backdoors, zu verhindern.
  • staff_use_svirt — ob es Junior-Administratoren (staff_t) erlaubt wird, virtuelle Maschinen zu verwalten (libvirt)
    • Die Deaktivierung ist nützlich für die klassische Umsetzung des Prinzips der geringsten Privilegien.

Übungen zu RBAC

Praxis

Zuerst erstellen wir einen normalen Systembenutzer mit sudo-Rechten (nennen wir ihn alice): 

useradd -m alice
passwd alice
usermod -aG sudo alice

Nun erstellen wir eine neue Entität in der SELinux-Richtlinie. Nennen wir sie custom_staff_u. Bei der Erstellung müssen wir angeben, welche Rollen diesem Benutzer zur Verfügung stehen werden: 

semanage user -a -R "staff_r sysadm_r" custom_staff_u

Überprüfen wir, ob der Benutzer erstellt und die Rollen korrekt angewendet wurden: 

semanage user -l | grep custom_staff_u

Verknüpfen wir unseren Linux-Benutzer alice über ein Mapping mit dem soeben erstellten SELinux-Benutzer custom_staff_u: 

semanage login -a -s custom_staff_u alice
semanage login -l

Als Nächstes weisen wir die Standardrolle staff_r zu.

Dazu muss die Datei /etc/selinux/<POLICY>/contexts/users/custom_staff_u mit folgendem Inhalt erstellt werden: 

system_r:local_login_t:s0        staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
system_r:sshd_t:s0              staff_r:staff_t:s0 sysadm_r:sysadm_t:s0

Nach der Änderung des Mappings für den neuen Benutzer ist es wichtig, die Dateikontexte in seinem Heimatverzeichnis zu aktualisieren, damit sie dem neuen SELinux-Benutzer entsprechen: 

restorecon -R -F -v /home/alice

Nun prüfen wir, wie unsere Konfiguration in der Praxis funktioniert.

Überprüfung des Default Context (Standardkontexts)

Wir verbinden uns über SSH (oder über die physische Konsole).

Überprüfung 

id -Z
sudo -i

Wir erhalten Zugriffsfehler, gelangen aber dennoch in die Root-Shell. Versuchen wir, den sshd-Dienst neu zu starten 

systemctl restart sshd

Und wir erhalten einen Fehler, da solche Operationen für die Domäne staff_t verboten sind.

Rollenwechsel

Da wir bei der Erstellung von custom_staff_u die Verwendung der Rolle sysadm_r erlaubt haben, kann alice eine Erhöhung ihrer Berechtigungen im Rahmen von SELinux anfordern 

newrole -r sysadm_r -t sysadm_t

Überprüfung 

id -Z
sudo -i

Wir versuchen, den sshd-Dienst neu zu starten 

systemctl restart sshd

Abschluss

Nach Abschluss der Arbeiten ist es zur Aufrechterhaltung einer sauberen Konfiguration wichtig, die erstellten Verknüpfungen korrekt löschen zu können.

Zuerst löschen wir das Mapping (andernfalls lässt das System das Löschen des SELinux-Benutzers nicht zu) 

semanage login -d alice

Dann löschen wir den benutzerdefinierten SELinux-Benutzer selbst: 

semanage user -d custom_staff_u

Schließlich löschen wir den Benutzer: 

userdel -r alice

Bereinigung der verbleibenden Dateien: 

rm /etc/selinux/<POLICY>/contexts/users/custom_user_u

Hinweis

Autorisierungsdienst

Während dieser Manipulationen kann der Autorisierungsdienst ausfallen, da ein Benutzer mit der Rolle staff_r beim Ausführen von sudo -i versucht, auf /root zuzugreifen.

Als vorübergehende Lösung des Problems können Sie den Dienst neu starten: 

systemctl restart systemd-logind

In der Praxis ist es korrekter, die Berechtigungen über die sudoers-Datei zu erweitern anstelle von newrole

← Zurück
Weiter →
Abgerufen von „https://wiki.foxtom.de/index.php?title=Linux/SELinux/06_Benutzer&oldid=163679“