Wie funktioniert sudo intern arbeiten? Wie ist es möglich, dass es root werden kann, ohne das Root-Passwort zu haben, im Gegensatz zu su ? Welche Systemaufrufe usw. sind an dem Prozess beteiligt? Ist es nicht eine klaffende Sicherheitslücke in Linux (z. B. warum konnte ich eine stark gepatchte sudo das hat einfach irgendein normales sudo gemacht getan, aber nicht nach dem Passwort des nicht privilegierten Benutzers gefragt)?
Ich habe login und su internals gelesen. Ich habe auch gelesen Wie soll sudo verwendet werden? aber trotz des Titels befassen sie sich hauptsächlich mit den Unterschieden zwischen su und sudo .
Akzeptierte Antwort:
Wenn Sie sich die ausführbare Datei sudo ansehen :
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
Sie werden feststellen, dass es die Berechtigungsbits ---s--x--x enthält . Diese lassen sich wie folgt aufschlüsseln:
-|--s|--x|--x
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only the setuid bit is enabled for user who owns file
--x - only the group execute bit is enabled
--x - only the other execute bit is enabled
Wenn also bei einem Programm das Setuid-Bit aktiviert ist (auch als SUID bezeichnet), bedeutet dies, dass, wenn jemand dieses Programm ausführt, es mit den Anmeldeinformationen des Benutzers ausgeführt wird, dem die Datei gehört, auch bekannt als. root in diesem Fall.
Beispiel
Wenn ich den folgenden Befehl als Benutzer saml ausführe:
$ whoami
saml
$ sudo su -
[sudo] password for saml:
Sie werden feststellen, dass die Ausführung von sudo läuft eigentlich als root:
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
setuid-Mechanismus
Wenn Sie neugierig sind, wie SUID funktioniert, werfen Sie einen Blick auf man setuid . Hier ist ein Auszug aus der Manpage, der es besser erklärt, als ich es könnte:
setuid() setzt die effektive Benutzer-ID des aufrufenden Prozesses. Wenn die
effektive UID des Anrufers root ist, werden auch die echte UID und die gespeicherte
set-user-ID gesetzt. Unter Linux ist setuid() wie
die POSIX-Version mit dem Feature _POSIX_SAVED_IDS implementiert. Dadurch kann ein
Set-User-ID-Programm (außer Root) alle seine Benutzerrechte
aufgeben, einige nicht privilegierte Arbeiten ausführen und dann wieder die ursprüngliche
effektive Benutzer-ID aktivieren auf sichere Weise.
Wenn der Benutzer root ist oder das Programm set-user-ID-root ist, ist besondere Sorgfalt
geboten. Die Funktion setuid() prüft die effektive Benutzerkennung
des Aufrufers und wenn es sich um den Superuser handelt, werden alle prozessbezogenen Benutzerkennungen
auf uid gesetzt. Nachdem dies geschehen ist, ist es für das Programm
unmöglich, Root-Privilegien wiederzuerlangen.
Das Schlüsselkonzept hier ist, dass Programme eine echte Benutzer-ID (UID) und eine effektive Benutzer-ID (EUID) haben. Setuid setzt die effektive Benutzer-ID (EUID), wenn dieses Bit aktiviert ist.
Verwandte:Ssh – Wie funktioniert tcp-keepalive in ssh?
Aus Sicht des Kernels ist also bekannt, dass in unserem Beispiel saml ist immer noch der ursprüngliche Eigentümer (UID), aber die EUID wurde mit dem Eigentümer der ausführbaren Datei festgelegt.
setgid
Ich sollte auch erwähnen, dass, wenn wir die Berechtigungen für den sudo-Befehl aufschlüsseln, die zweite Gruppe von Bits für Gruppenberechtigungen war. Die Gruppenbits haben auch etwas Ähnliches wie setuid namens set group id (auch bekannt als setgid, SGID). Dies macht dasselbe wie SUID, außer dass es den Prozess mit den Gruppenanmeldeinformationen anstelle der Besitzeranmeldeinformationen ausführt.
Referenzen
- setuid-Wikipedia-Seite
- setuid-Manpage