Sudo Grundlagen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „;Was macht sudo Führt einen Befehl mit den Rechten eines anderen Benutzers aus (Standard: root), basierend auf Berechtigungen in <code>/etc/sudoers</code>. <…“)
 
 
Zeile 31: Zeile 31:
 
''<code>wheel</code> bei Rocky/RHEL-Systemen, <code>sudo</code> bei Debian/Ubuntu. Der Schalter <code>-a</code> (append) ist entscheidend — ohne ihn werden alle bisherigen Gruppen des Benutzers überschrieben.''
 
''<code>wheel</code> bei Rocky/RHEL-Systemen, <code>sudo</code> bei Debian/Ubuntu. Der Schalter <code>-a</code> (append) ist entscheidend — ohne ihn werden alle bisherigen Gruppen des Benutzers überschrieben.''
  
;Warum das funktioniert
+
;Warum das funktioniert — Analyse der sudoers-Zeile
In <code>/etc/sudoers</code> steht üblicherweise eine Zeile wie:
+
In <code>/etc/sudoers</code> steht standardmäßig eine Zeile wie:
 
<pre>
 
<pre>
 
%wheel ALL=(ALL) ALL
 
%wheel ALL=(ALL) ALL
 
</pre>
 
</pre>
Das <code>%</code> kennzeichnet eine Gruppe. Diese Zeile erlaubt allen Mitgliedern der Gruppe <code>wheel</code>, mit <code>sudo</code> jeden Befehl (<code>ALL</code>) als jeden Benutzer (<code>(ALL)</code>) auf jedem Host auszuführen. Wer der Gruppe beitritt, wird dadurch effektiv zum Admin — ganz ohne eigenen Eintrag in der sudoers-Datei.
+
Das ist die erste Frage, die man sich hier stellen sollte: was bedeuten diese Teile eigentlich? Aufgeschlüsselt:
 +
 
 +
{| class="wikitable"
 +
! Teil !! Bedeutung
 +
|-
 +
| <code>%wheel</code> || Gilt für alle Mitglieder der Gruppe <code>wheel</code> (das <code>%</code> markiert eine Gruppe, kein einzelner Benutzer)
 +
|-
 +
| <code>ALL</code> (1.) || Gilt auf allen Hosts (relevant bei einer sudoers-Datei, die auf mehrere Maschinen verteilt wird)
 +
|-
 +
| <code>(ALL)</code> || Darf als jeder beliebige Zielbenutzer ausführen (auch als root)
 +
|-
 +
| <code>ALL</code> (2.) || Darf jeden beliebigen Befehl ausführen
 +
|}
 +
 
 +
Wer der Gruppe <code>wheel</code> beitritt, wird dadurch effektiv zum Admin — ganz ohne eigenen Eintrag in der sudoers-Datei. Bei jedem <code>sudo</code>-Aufruf muss sich der Benutzer aber mit seinem eigenen Passwort authentifizieren. Das ist die Standard-Einstellung auf den meisten Distributionen (Rocky, Debian, Ubuntu) und der empfohlene Ausgangspunkt.
 +
 
 +
;Variante mit NOPASSWD — und warum das gefährlich ist
 +
Manche Systeme (z. B. Cloud-Images) tragen stattdessen ein:
 +
<pre>
 +
%wheel ALL=(ALL) NOPASSWD:ALL
 +
</pre>
 +
Gleiche Struktur, nur mit einem zusätzlichen vierten Teil: <code>NOPASSWD:ALL</code> bedeutet, kein Passwort nötig, für ALLE Befehle. Jedes Gruppenmitglied bekommt damit vollständige Root-Rechte für beliebige Befehle, ganz ohne Passwortabfrage.
 +
 
 +
''Kritischer Punkt: Wird ein solches Konto kompromittiert, ist sofort das ganze System kompromittiert — es gibt keine zweite Hürde. Von dieser Konfiguration wird abgeraten.''
 +
 
 +
;Bessere Alternative: NOPASSWD nur für ausgewählte Befehle, mit benanntem Alias
 +
<pre>
 +
Cmnd_Alias SERVICE_MGMT = /usr/bin/systemctl restart httpd, /usr/bin/systemctl restart sshd
 +
%wheel ALL=(ALL) ALL
 +
%wheel ALL=(ALL) NOPASSWD: SERVICE_MGMT
 +
</pre>
 +
Hier wird das Prinzip der minimalen Rechtevergabe sichtbar gemacht:
 +
* Zeile 1 definiert einen <code>Cmnd_Alias</code> — eine benannte Gruppe von Befehlen, die dokumentiert, wofür NOPASSWD überhaupt gilt.
 +
* Zeile 2 verlangt für alle Befehle weiterhin ein Passwort (Standardschutz).
 +
* Zeile 3 hebt diese Passwortpflicht gezielt nur für die in <code>SERVICE_MGMT</code> gelisteten Befehle auf, z. B. für automatisierte Neustarts eines Dienstes.
 +
 
 +
Der Vorteil gegenüber <code>NOPASSWD:ALL</code>: Selbst bei kompromittiertem Account bleibt der Schaden auf die explizit freigegebenen Befehle begrenzt, und der <code>Cmnd_Alias</code>-Name macht in der Datei selbst dokumentiert sichtbar, welche Ausnahme warum existiert.
  
 
;Gruppenmitgliedschaft prüfen
 
;Gruppenmitgliedschaft prüfen
Zeile 56: Zeile 92:
 
sudo -l
 
sudo -l
 
</syntaxhighlight>
 
</syntaxhighlight>
 
;Passwortfreies sudo für bestimmte Befehle
 
In <code>/etc/sudoers.d/</code> eine eigene Datei anlegen:
 
<pre>
 
benutzername ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd
 
</pre>
 
''Best Practice: nie global NOPASSWD setzen, sondern auf einzelne Befehle beschränken.''
 
  
 
;Letzte sudo-Aktionen nachvollziehen
 
;Letzte sudo-Aktionen nachvollziehen

Aktuelle Version vom 14. Juli 2026, 10:33 Uhr

Was macht sudo

Führt einen Befehl mit den Rechten eines anderen Benutzers aus (Standard: root), basierend auf Berechtigungen in /etc/sudoers.

sudo systemctl restart httpd
Als anderer Benutzer ausführen
sudo -u benutzername befehl
Root-Shell öffnen
sudo -i

(lädt die Root-Umgebung, im Gegensatz zu sudo -s, das die aktuelle Shell-Umgebung behält)

sudoers-Datei sicher bearbeiten
visudo

Niemals direkt mit einem Editor öffnen — visudo prüft die Syntax vor dem Speichern und verhindert, dass man sich aussperrt.

Benutzer zur sudo-Gruppe hinzufügen (Admin-Rechte vergeben)

Damit ein Benutzer sudo nutzen darf, muss er Mitglied der entsprechenden Gruppe sein. Diese Gruppe ist standardmäßig bereits in /etc/sudoers mit vollen Rechten eingetragen.

usermod -aG wheel benutzername

wheel bei Rocky/RHEL-Systemen, sudo bei Debian/Ubuntu. Der Schalter -a (append) ist entscheidend — ohne ihn werden alle bisherigen Gruppen des Benutzers überschrieben.

Warum das funktioniert — Analyse der sudoers-Zeile

In /etc/sudoers steht standardmäßig eine Zeile wie:

%wheel	ALL=(ALL)	ALL

Das ist die erste Frage, die man sich hier stellen sollte: was bedeuten diese Teile eigentlich? Aufgeschlüsselt:

Teil Bedeutung
%wheel Gilt für alle Mitglieder der Gruppe wheel (das % markiert eine Gruppe, kein einzelner Benutzer)
ALL (1.) Gilt auf allen Hosts (relevant bei einer sudoers-Datei, die auf mehrere Maschinen verteilt wird)
(ALL) Darf als jeder beliebige Zielbenutzer ausführen (auch als root)
ALL (2.) Darf jeden beliebigen Befehl ausführen

Wer der Gruppe wheel beitritt, wird dadurch effektiv zum Admin — ganz ohne eigenen Eintrag in der sudoers-Datei. Bei jedem sudo-Aufruf muss sich der Benutzer aber mit seinem eigenen Passwort authentifizieren. Das ist die Standard-Einstellung auf den meisten Distributionen (Rocky, Debian, Ubuntu) und der empfohlene Ausgangspunkt.

Variante mit NOPASSWD — und warum das gefährlich ist

Manche Systeme (z. B. Cloud-Images) tragen stattdessen ein:

%wheel	ALL=(ALL)	NOPASSWD:ALL

Gleiche Struktur, nur mit einem zusätzlichen vierten Teil: NOPASSWD:ALL bedeutet, kein Passwort nötig, für ALLE Befehle. Jedes Gruppenmitglied bekommt damit vollständige Root-Rechte für beliebige Befehle, ganz ohne Passwortabfrage.

Kritischer Punkt: Wird ein solches Konto kompromittiert, ist sofort das ganze System kompromittiert — es gibt keine zweite Hürde. Von dieser Konfiguration wird abgeraten.

Bessere Alternative
NOPASSWD nur für ausgewählte Befehle, mit benanntem Alias
Cmnd_Alias SERVICE_MGMT = /usr/bin/systemctl restart httpd, /usr/bin/systemctl restart sshd
%wheel	ALL=(ALL)	ALL
%wheel	ALL=(ALL)	NOPASSWD: SERVICE_MGMT

Hier wird das Prinzip der minimalen Rechtevergabe sichtbar gemacht:

  • Zeile 1 definiert einen Cmnd_Alias — eine benannte Gruppe von Befehlen, die dokumentiert, wofür NOPASSWD überhaupt gilt.
  • Zeile 2 verlangt für alle Befehle weiterhin ein Passwort (Standardschutz).
  • Zeile 3 hebt diese Passwortpflicht gezielt nur für die in SERVICE_MGMT gelisteten Befehle auf, z. B. für automatisierte Neustarts eines Dienstes.

Der Vorteil gegenüber NOPASSWD:ALL: Selbst bei kompromittiertem Account bleibt der Schaden auf die explizit freigegebenen Befehle begrenzt, und der Cmnd_Alias-Name macht in der Datei selbst dokumentiert sichtbar, welche Ausnahme warum existiert.

Gruppenmitgliedschaft prüfen
groups benutzername

oder

id benutzername
Admin-Rechte wieder entziehen
gpasswd -d benutzername wheel
Eigene Rechte prüfen
sudo -l
Letzte sudo-Aktionen nachvollziehen
journalctl _COMM=sudo

oder distributionsabhängig:

grep sudo /var/log/auth.log