Weil sudo ermöglicht eine viel feinkörnigere Steuerung als "als root anmelden und dann tun, was Sie wollen". Beispielsweise können Sie sudo konfigurieren so dass einige Benutzer nur bestimmte Befehle ausführen dürfen (wie Wrapper-Skripte oder "akzeptable" Binärdateien). Sie befürchten, dass ein Trojaner den Computer eines einzelnen Benutzers kompromittiert, aber sudo wurde erstellt, um die Protokollierung und Zugriffskontrolle auf einem Server zu ermöglichen, der von mehreren Personen verwaltet wird.
Auf einem Einzelbenutzersystem sind die wichtigen Dateien natürlich die Dateien des Benutzers, und sobald Sie Zugriff auf das Konto des Benutzers erhalten, haben Sie bereits Zugriff auf diese Dateien , also ist es nicht einmal mehr so wichtig, das Passwort zu bekommen. Selbst wenn das Passwort Ihr Ziel ist (sagen wir, Sie greifen jemanden an, der Passwörter wiederverwendet), gibt es viele Möglichkeiten, es zu bekommen, ohne sudo einzubeziehen; Zum Beispiel bin ich kürzlich auf 2 standardmäßig installierte Programme gestoßen, die Passwörter oder Passwortfehler im Klartext protokollieren.
Und schließlich ist es ratsam, möglichst nicht als root auszuführen, da die Folgen einer falschen Eingabe eines Befehls (rm_-rf_._/ ist ein offensichtliches Beispiel) sind nicht so schwerwiegend. Erfordert den zusätzlichen Schritt des Schreibens von sudo am Anfang eines Befehls, anstatt "zu vergessen, dass Sie als Root angemeldet sind, und etwas destruktives zu tun" kann einige einfache, aber schwerwiegende Fehler vermeiden.
Es gibt sinnvolle praktische Verwendungen für sudo, aber da sie bereits in anderen Posts ausreichend erklärt werden, werde ich hier nicht näher darauf eingehen. Ich verweise Sie jedoch auf sudoers(5) , das ist die sudo-Konfigurationsdatei. Es zeigt einige der umfangreichen Konfigurationsmöglichkeiten, die mit sudo möglich sind. Ich werde erklären, wann und warum Sie sudo nicht verwenden sollten, um von Ihrem normalen Benutzer zu root zu werden, aus reinen Sicherheitsgründen, abgesehen von der Bequemlichkeit.
Kurze Antwort: Es gibt keine Möglichkeit, sudo sicher zu verwenden, wenn Ihr normaler Benutzer möglicherweise kompromittiert ist. Verwenden Sie es nur aus Bequemlichkeit, nicht aus Sicherheitsgründen. Dasselbe gilt für su und alle anderen Programme, die verwendet werden können, um Ihren regulären Benutzer zu einem privilegierteren Benutzer zu machen.
Lange Antwort: Es ist nicht wahr, dass die Verwendung des vollständigen Pfads für sudo Sie vor einer bösartigen Umgebung schützt. Das ist ein weit verbreitetes Missverständnis. Eine Bash-Funktion kann sogar Namen entführen, die einen / enthalten am Anfang. Versuchen Sie Folgendes auszuführen:
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
Sie müssen Verwenden Sie nur Option 1, auch bekannt als Anmelden mit agetty oder logind auf einem anderen tty (beachten Sie, dass bei einigen Distributionen Xorg auf tty1 läuft, wie z. B. Fedora. Bei den meisten Distributionen ist tty1 jedoch ein Ersatz-tty und Xorg läuft auf tty7) . Allerdings müssen Sie sich darüber im Klaren sein, dass Malware ctrl entführen kann +alt +f1 und Ihnen einen gefälschten Bildschirm präsentieren, also müssen Sie die Secure Attention Key-Kombination (SAK, die alt ist +sysrq +k auf Linux-Systemen), wodurch alle Prozesse in diesem tty beendet werden. Dies beendet jeden gefälschten Anmeldebildschirm und bringt Sie nur zum echten. Wenn es keine gefälschten Anmeldebildschirme gibt, die versuchen, Ihr Root-Passwort zu stehlen (was hoffentlich der Fall ist), wird agetty einfach neu gestartet, was nur als blinkender Anmelde-Prompt erscheinen sollte. Auf einigen Systemen sind viele SysRq-Funktionen deaktiviert, einschließlich SAK. Sie können sie alle vorübergehend aktivieren, indem Sie die Ganzzahl 1 bis /proc/sys/kernel/sysrq schreiben . Der Wert von /proc/sys/kernel/sysrq ist ein Bitmap, also schauen Sie sich an, was es derzeit ist, und berechnen Sie, in was Sie es konvertieren müssen, um SAK-Unterstützung hinzuzufügen, bevor Sie es in /etc/sysctl.conf dauerhaft machen . Es kann eine schlechte Idee sein, es für immer auf 1 zu setzen (Sie wollen nicht, dass jeder in der Lage ist, alt zu verwenden +sysrq +e um xscreensaver zu töten, oder?).
Die Idee, dass Sie Ihren normalen Benutzer schützen und sudo oder su sicher verwenden können, ist eine sehr gefährliche Idee. Selbst wenn es möglich wäre, gibt es unzählige Möglichkeiten, Ihre laufende Sitzung zu kapern, wie z. B. LD_PRELOAD , eine Umgebungsvariable, die auf ein gemeinsam genutztes Objekt (Bibliothek) zeigt, das vom Programm zwangsweise geladen wird, um sein Verhalten zu ändern. Während es bei Setuid-Programmen wie su und sudo nicht funktioniert, funktioniert es bei bash und allen anderen Shells, die su und sudo ausführen und die alle Ihre Tastenanschläge sehen. LD_PRELOAD ist nicht die einzige Variable, die Programme entführen kann, die als Ihr Benutzer ausgeführt werden. LD_LIBRARY_PATH kann ein Programm anweisen, bösartige Bibliotheken anstelle Ihrer Systembibliotheken zu verwenden. Es gibt viele weitere Umgebungsvariablen, die verwendet werden können, um das Verhalten laufender Programme auf verschiedene Weise zu ändern. Grundsätzlich können, wenn Ihre Umgebungsvariablen kompromittiert werden können, Ihr Benutzer und alle als dieser Benutzer eingegebenen Tastenanschläge kompromittiert werden.
Wenn das nicht genug wäre, kann Ihr Benutzer in den meisten Distributionen ptrace() verwenden mit dem GETREGS oder PEEKTEXT/PEEKDATA Optionen zum Anzeigen des gesamten Speichers von Prozessen, die unter demselben Benutzer ausgeführt werden (z. B. der Bash-Prozess, der su oder sudo für Sie ausführt). Wenn Sie eine Distribution verwenden, die dies deaktiviert (z. B. durch Verwendung des Yama LSM), kann der Prozess möglicherweise immer noch mit process_vm_readv() in den Speicher Ihres Bash-Prozesses lesen und schreiben und process_vm_writev() beziehungsweise. Bei manchen Kerneln können Sie über /proc/pid/mem auch direkt in den Speicher schreiben , solange der Prozess, der darauf schreibt, derselbe Benutzer ist. Im Linux-Kernel gibt es überall unzählige Sicherheitschecks, um sicherzustellen, dass sich Prozesse nicht gegenseitig stören können. Sie beinhalten jedoch alle inter -Benutzerschutz, nicht intra -Benutzerschutz. Der Linux-Kernel geht davon aus, dass jeder einzelne Vorgang, der als Benutzer A ausgeführt wird, von Benutzer A als vertrauenswürdig eingestuft wird. Wenn Sie also als Benutzer A rooten, muss root genauso vertrauenswürdig sein wie dieser Benutzer.
Bevor ich überhaupt zu Xorg komme, möchte ich gleich zu Beginn sagen, dass Xorg keinen Schutz vor Keyloggern bietet. Das bedeutet, dass, wenn Sie sudo oder su in einem tty verwenden, während Xorg läuft, alle Prozesse, die unter demselben Benutzer laufen, Tastenanschläge ausspionieren (und einschleusen) können. Dies liegt daran, dass das Sicherheitsmodell des X11-Protokolls davon ausgeht, dass alles mit Zugriff auf das X11-Cookie vertrauenswürdig ist und dass auf dieses Cookie für alles zugegriffen werden kann, was unter Ihrem Benutzer ausgeführt wird. Es ist eine grundlegende Einschränkung des X11-Protokolls, die so tief verwurzelt ist wie das Konzept der UIDs unter Linux. Es gibt keine Einstellung oder Funktion, um dies zu deaktivieren. Das bedeutet, dass alles, was Sie in einer Xorg-Sitzung eingeben, einschließlich Eingaben in su oder sudo (oder Frontends wie gksu, gksudo, kdesu, kdesudo, pinentry usw.), von allem ausspioniert werden kann, das unter demselben Benutzer läuft, also Ihr Browser, Ihre Spiele , Ihr Videoplayer und natürlich alles, was von Ihrer .bashrc gegabelt wird. Sie können dies selbst testen, indem Sie Folgendes in einem Terminal ausführen und dann zu einem anderen Terminal wechseln und einen Befehl mit sudo.
ausführen$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Beachten Sie, dass, wenn dieser spezielle Test bei Ihnen nicht funktioniert, dies bedeutet, dass Sie den XTEST nicht haben Verlängerung aktiv. Auch wenn es nicht aktiv ist, ist es immer noch möglich, Tastaturereignisse mit XQueryKeymap() aufzuzeichnen . Die Lektion, die Sie lernen sollten, ist, dass es praktisch keinen Weg gibt um Ihr Passwort sicher mit su oder sudo über einen kompromittierten Benutzer einzugeben. Sie müssen unbedingt zu einem neuen tty wechseln und SAK verwenden und sich dann direkt als root anmelden.
Abgesehen von den Angaben der anderen Benutzer behält sudo auch die ursprüngliche Identität des Benutzers bei, der den Befehl ausführt. Das bedeutet, dass Sie verfolgen können, welche Benutzer-ID den Befehl ausgeführt hat. Wenn Sie root in einer Mehrbenutzerumgebung verwenden, können Sie die Ausführung eines Befehls nicht für einen einzelnen Benutzer verfolgen, da die UID 0 ist.