Frage:
Ist "sudo" fast nutzlos?
Wernight
2020-06-08 12:28:49 UTC
view on stackexchange narkive permalink

Sobald ein Angreifer eine Shell als Sudoer-Benutzer hat (oder nur einen lokalen Prozess ausreichend kompromittiert hat), kann er / sie eines der vielen Tools zur Eskalation von Berechtigungen verwenden, um sich sogar automatisch als apt code zu setzen > oder eine andere von root aufgerufene Verarbeitung, um root Zugriff zu erhalten (siehe auch Was kann ein Angreifer in diesem Szenario tun? (nicht beschreibbarer bashrc, Profil usw.)).

Was bringt sudo , wenn kleinere Nutzdaten nicht blockiert oder etwas schwieriger gemacht werden? Es scheint, dass der Fokus auf SELinux und dergleichen liegen sollte.

Bearbeiten: Es gibt zwei Seiten dieser Frage (ich hätte genauer sein sollen). Zunächst, was ich ursprünglich für einen Standard-Linux-Desktop-Benutzer gemeint habe. Eine ziemlich andere Antwort könnte für eine Maschine gegeben werden, die von jemand anderem verwaltet wird.

* "... er / sie kann eines der vielen Tools zur Eskalation von Berechtigungen verwenden ..." * - Sie scheinen anzunehmen, dass dies generische Tools sind, die definitiv auf dem Zielsystem funktionieren.Diese Tools basieren jedoch auf nicht behobenen Fehlern oder Fehlkonfigurationen.Sie funktionieren nicht auf einem ordnungsgemäß aktualisierten und ordnungsgemäß konfigurierten System.Grundsätzlich fragen Sie, ob sudo nutzlos ist, wenn ohnehin alle Systeme kaputt sind.Diese Grundannahme ist aber schon falsch.
Es ist viel einfacher als Sie denken, wenn Sie in Ordnung sind, ein bisschen zu warten;siehe @reed's-Beispiel nur für eine und die verknüpfte Frage für einen naiven Schutz dagegen.Beachten Sie, dass für Corp-Maschinen ein begrenzter Sudoer Schutz bieten kann.
Guter Punkt (und gute Antwort), aber dies setzt voraus, dass der Benutzer "sudo" anstelle von "/ usr / bin / sudo" aufruft.Zugegeben, die meisten Benutzer werden dies jedoch so tun.
Ich wollte nur sagen, dass ich von dem Atem der Antworten hier beeindruckt bin.Von sudo in den meisten Distributionsstandards (mein ursprünglich angenommener Bereich) bis zu sudo power mit einem (lokalen oder entfernten) separaten Administratorkonto (der Standardbenutzer hat also sudo eingeschränkt oder nicht);und andere viele hier beschriebene Situationen.
Für das, was es wert ist, kann sudo so konfiguriert werden, dass es weitaus detailliertere Berechtigungen gewährt als nur "Root-Zugriff auf alles".Die meisten nutzen diese Funktionalität jedoch nicht.
@Ajedi: Die Ops-Frage sollte lauten: "Ist" sudo "fast nutzlos, wenn faule Administratoren unsichere Konfigurationen bereitstellen?"
Hatten Sie in Ihrer Bearbeitung außer "Erstens" noch etwas anderes?Ich suchte nach einem "Zweitens" ..
Sie haben hier nur eine halbe Frage.Die eigentliche Frage ist "Ist" sudo "im Vergleich zu was fast nutzlos?".`sudo` ist in Bezug auf die Sicherheit definitiv besser als` su`, und beides ist weitaus besser, als sich jederzeit nur als `root` anzumelden.Haben Sie eine andere Möglichkeit, legitimen Benutzern Zugriff auf Administratorfunktionen zu gewähren, während Sie nicht autorisierten Zugriff blockieren, als "su" / "sudo" / root-Login, von dem Sie glauben, dass es besser ist als "sudo"?Wenn nicht, dann ist es zumindest die "am wenigsten nutzlose" dieser drei Optionen.
Wie würden Sie ohne "sudo" jemanden dazu bringen, Ihnen ein Sandwich zu machen?
@Wernight, Es scheint, als würden Sie (und viele Kommentatoren) ein Einzelbenutzersystem annehmen.Zusätzlich zu detaillierten Berechtigungen erhalten Sie auch ein Protokoll darüber, wer was getan hat.
Sudo war der erste Versuch der Branche, für Konsolenbenutzer "standardmäßig sicher" zu sein.(Alle Benutzer waren "Konsolen", nur an einem anderen Kabel, das an einen seriellen Mux angeschlossen war.)
https://security.stackexchange.com/questions/187502/do-sudo-and-profile-bashrc-enable-trivial-privilege-escalation/187508#187508 ist eine Lektüre wert.
Elf antworten:
#1
+173
reed
2020-06-08 14:34:07 UTC
view on stackexchange narkive permalink

Sudo hat keinen wirklichen Sicherheitszweck gegen einen böswilligen Dritten. Also ja, es ist für diesen Zweck grundsätzlich nutzlos. In der Vergangenheit glaubte ich, es sei tatsächlich eine Sicherheitskontrolle, um eine Eskalation von Privilegien zu verhindern und Angriffe zu erschweren, weil einige Leute weiterhin darauf bestehen, dass dies auch diesen Zweck hat, aber das ist tatsächlich falsch. Tatsächlich haben Sie im Moment nur eine Antwort auf Ihre Frage erhalten, und diese Antwort verbreitet diesen Mythos. Der einzige Zweck von sudo besteht darin, Sie vor sich selbst zu schützen, dh zu vermeiden, dass Ihr System versehentlich durcheinander gebracht wird. Das Erlangen aller Berechtigungen mit einem Klick oder einem Tastendruck kann gefährlich sein, während sudo Sie zumindest dazu zwingt, Ihr Passwort bewusst einzugeben. Und wenn Sie (oder ein Programm oder Skript) versehentlich Systemdateien oder Dateien anderer Benutzer berühren, ohne bewusst sudo zu verwenden, erhalten Sie eine Benachrichtigung "Erlaubnis verweigert". Letztendlich handelt es sich also nur um ein Verwaltungstool und nicht um eine Sicherheitskontrolle, die Sie vor einem Angriff schützen soll.

Hier ist ein sehr einfaches Beispiel dafür, warum sudo keinen wirklichen Schutz bietet gegen bösartigen Code:

  # Nutzlast erstellen: sudo durch aliaspayload ersetzen = 'fake_sudo () {# Simulieren Sie ein sudo-Eingabeaufforderungsecho -n "[sudo] -Kennwort für $ {USER}:" read -s Passwort echo # Führen Sie Ihren Befehl aus, damit Sie zufrieden sind. echo "$ password" | sudo -S "$ @" # Mach mein böses Zeug mit deinem Passwort Echo "Fertig mit deinem Befehl, jetzt könnte ich $ Passwort verwenden, um zu tun was ich will"} alias sudo = fake_sudo '# Schreibe die Nutzdaten in die bashrc config fileecho " $ payload ">> ~ / .bashrc  

Dies ist ein sehr einfaches Beispiel für Code, den ein Angreifer auf Ihrem Computer ausführen kann. Es ist nicht perfekt, es behandelt nicht einmal jeden Fall (es funktioniert nicht gut, wenn Sie das falsche Passwort eingeben), aber es zeigt Ihnen nur, dass sudo durch einen Angreifer ersetzt werden kann. Wenn Sie dieses Skript ausführen, wird beim nächsten Öffnen Ihres Terminals und Ausführen von sudo tatsächlich fake_sudo ausgeführt. Ein Angreifer kann Ihre Programme durch Aliase ersetzen oder die Binärdateien ersetzen (schädliche Versionen in ~ / bin einfügen oder wo immer sie in Ihrem Pfad ausgeführt werden können) usw.

Dies ist nicht einmal eine echte "Eskalation von Berechtigungen", da ein Benutzer, der sudo ausführen kann, um root zu werden, bereits über alle Berechtigungen verfügt. Ein wirklicher nicht privilegierter Benutzer sollte nicht über sudo -Funktionen verfügen. Um eine echte Trennung der Berechtigungen zu erreichen, sollten Sie Verwaltungsaufgaben auf einem völlig separaten Konto ausführen.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/109111/discussion-on-answer-by-reed-is-sudo-almost-useless).
Das Aufrufen von "sudo" -Protokollen in "/ var / log / secure" oder "/ var / log / auth.log" hängt von Ihrem System ab.Das sagt Ihnen, wer Ihr System durcheinander gebracht hat oder möglicherweise gefährdet ist.In Verbindung mit einer ordnungsgemäß konfigurierten "sudoers" -Datei kann ein böswilliger Akteur diese Protokolle nicht löschen oder ändern.Wenn Sie noch einen Schritt weiter gegangen sind und nur Aktionen in der "sudoers" -Datei zulassen, die der Benutzer benötigt, und sonst nichts, ist die potenzielle Oberfläche für einen Angriff sehr gering, selbst bei einem "fake_sudo" wie oben gezeigt.
@SnakeDoc `sudo` kann dies, aber die meisten Benutzer möchten` sudo` für die ganz andere Aufgabe der Authentifizierung, um das System zu verwalten.Zumindest meiner Erfahrung nach tun dies diejenigen, die * denken *, dass sie "sudo" auf diese Weise verwenden, normalerweise nicht.Um zu verhindern, dass "sudo" -Nutzer Aktionen ausführen können (einschließlich des Änderns von Protokollen), ist es kein "Schritt weiter", Benutzer auf eine kleine, sorgfältig kuratierte Whitelist in "sudoers" zu beschränken.Es ist wichtig.Viele, vielleicht die meisten Befehle können verwendet werden, um Berechtigungen zu eskalieren.In der Praxis umfasst dies jeden Befehl, der einen Ausgabedateinamen als Argument akzeptiert (z. B. "nmap") und vieles mehr.
@EliahKagan Das macht "sudo" nicht nutzlos - es macht viele Systeme falsch konfiguriert.Machen Sie das Tool nicht für die Fehler des Benutzers verantwortlich.
Dies scheint sudo in dieselbe Kategorie wie ./executable zu bringen
Haben "wir" nicht das gleiche Manko?
@Rodney, im Grunde ja
Wenn Sie dem Benutzer uneingeschränkten Root-Zugriff gewähren, hilft dies nicht gegen einen Angreifer, der dieses Konto entführt hat. Sie können jedoch sudo viel feiner einrichten.Mit festen Befehlen (wenn Sie auf die Umgebung achten) können Sie LOB-Benutzern erlauben, einige privilegierte Aktionen auszuführen, und der Angreifer ist auch auf diese beschränkt.Ein typisches Beispiel wäre das Starten oder Stoppen eines Daemons / Dienstes für eine Geschäftsanwendung (obwohl systemctl dies heutzutage mit Policykit tun kann).
Beachten Sie, dass das Beispiel "fake_sudo" das Kennwort eines einzelnen Benutzerkontos erfasst, das Sie bereits ausreichend kompromittiert haben, um in sein Ausgangsverzeichnis zu schreiben.Obwohl dies definitiv schlecht ist, ist dies immer noch weniger schlecht als die Alternativen: Benutzer melden sich direkt als "root" an, und Sie haben das Ausgangsverzeichnis kompromittiert.oder Benutzer eskalieren regelmäßig mit "su" und Sie erfassen das Root-Passwort mit einem ähnlichen "fake_su".Zumindest auf diese Weise hat der Systemadministrator Hinweise darauf, welches Konto kompromittiert wurde.
Nach dieser Logik haben alle Sicherheitssoftware und Gegenmaßnahmen jemals "keinen wirklichen Sicherheitszweck gegen einen böswilligen Dritten", denn ja, sobald Sie einen Benutzer dazu bringen können, eine ausführbare Datei in einer beliebigen Umgebung auszuführen, liegt höchstwahrscheinlich ein Fehler voreine hinterhältige Möglichkeit, von dort aus Root-Zugriff zu erhalten. Es geht darum, es schwieriger zu machen.sudo schützt in fast allen Situationen sinnvoll vor böswilligen Angriffen / verlangsamt sie, selbst in Ihrem eigenen Beispiel kann es für einen Standard-Desktop-Benutzer leicht Wochen zwischen den Aufrufen von sudo dauern.
@user2979044, nicht wirklich, da einige "Sicherheitskontrollen" tatsächlich viel schwieriger zu umgehen sind und manchmal Zero-Days oder kontinuierliche Erforschung von Anti-Erkennungsmustern erfordern.Stattdessen ist diese Art, Sudo zu "umgehen", wirklich trivial, war schon immer trivial und wird auch weiterhin trivial sein.Da es sich nicht um eine Sicherheitskontrolle für die vom OP angeforderten Zwecke handelt.Beachten Sie, dass das OP tatsächlich ein Szenario erwähnt hat, in dem der Angreifer, der Code ausführen kann, den typischen Linux-Desktop und Probleme im Zusammenhang mit der Eskalation von Berechtigungen.Deshalb halte ich meine Antwort für angemessen.
Ja @reed, Wenn ein Angreifer bereits vollen Konto- und Systemzugriff erhalten hat und die Möglichkeit hat, beliebigen Code auszuführen, ist es trivial, den Rest des Systems zu pwnen.In anderen Nachrichten ist der Himmel blau.
#2
+121
Bob Coggeshall
2020-06-10 03:26:25 UTC
view on stackexchange narkive permalink

Ich bin Mitautor von sudo. Es wurde in den frühen 80er Jahren speziell geschrieben, um die Notwendigkeit zu berücksichtigen, die Integrität einer gemeinsam genutzten Ressource (A VAX-11/750 unter BSD UNIX) vor ihren Benutzern (der Fakultät der CS-Abteilung von SUNY / Buffalo) zu schützen. Zu dieser Zeit war die einzige andere Option "su", bei der jeder ein einziges Passwort teilen musste. Wäre ein Unglück aufgetreten, wäre es schwierig oder unmöglich gewesen, die Forensik zu durchforsten und festzustellen, wer der Täter mit den fetten Fingern war ...

Ich denke, Sudos offensichtlicher dauerhafter Nutzen besteht darin, dass er den Befehlszeilenbenutzer daran erinnert Sie sind dabei, etwas zu tun, das eine gewisse Sicherheit im Ergebnis verdient, bevor sie tippen. Zugegeben, in einigen Implementierungen, wie den großen Himbeer-Pi-Distributionen, in denen kein Passwort abgefragt wird, dient es lediglich als Stempel. Gehen Sie also zur Abbildung.

Ich glaube immer noch, dass Best Practices für die Implementierung von Anwendungen unter UNIX-abgeleiteten Betriebssystemen vorschreiben, dass Sie sie unter einer Nicht-Root-ID ausführen. Wenn Sie root benötigen, sollte dies unter kontrollierten Umständen erfolgen. Stellen Sie sich sudo als die Art und Weise vor, wie Befehlszeilenbenutzern unter kontrollierten Umständen Root-Zugriff gewährt wird. Das ist alles.

Haben Sie eine Möglichkeit zu überprüfen, ob Sie ein Sudo-Co-Autor sind?Ihr Name wird auf https://www.sudo.ws/contributors.html nicht erwähnt
@Shadow https: // www.sudo.ws / Contributors.html listet nur die Mitwirkenden seit 1993 auf, als Todd C. Miller begann, Sudo zu pflegen.Die Seite, nach der Sie suchen, ist https://www.sudo.ws/history.html, auf der erwähnt wird: * "Sudo wurde erstmals um 1980 von Bob Coggeshall und Cliff Spencer am Institut für Informatik von SUNY / konzipiert und implementiert.Büffel."*
Es wird heute noch in dieser Funktion verwendet.Viele Unternehmenskunden kombinieren sudo mit Remote-Protokollierung, um zu überprüfen, wer was getan hat.Sie können auch su + auditd ausführen, dies ist jedoch etwas komplexer.
Großartig, danke.Hoffentlich haben Sie das nicht falsch verstanden, aber im Internet gibt es viele Leute, die behaupten, Menschen zu sein, die sie nicht sind.
Genau aus diesem Grund hat meine Firma unsere Administratoren dazu gebracht, "sudo" zu verwenden.(Und das Root-Passwort so geändert, dass 'su' nicht für den Root-Zugriff verwendet werden kann).Wenn etwas nicht mehr funktionierte, gab es Sudo-Protokolle, damit wir sehen konnten, wer es getan hat und was sie getan haben.
@Shadow: "Du hast kein Sudo geschrieben", Bob: "Sudo habe ich", Shadow: "Ok, du hast es getan"
Ausgezeichnet, danke Bob für die Antwort und das Co-Authoring von sudo.Wie bei allem hat es seine Vor- und Nachteile, und es liegt an uns, herauszufinden, wie wir es auf eine Weise nutzen können, die sich positiv auf die Sicherheit auswirkt.
#3
+51
John Zhau
2020-06-08 12:51:38 UTC
view on stackexchange narkive permalink

Nein, sudo ist nicht nutzlos.

Als Benutzer (Ziel)

Normalerweise, wenn Sie es sind Unter Linux agieren Sie als Nicht-Root-Benutzer. Viele Dinge, wie die Installation von Paketen mit apt , benötigen die Berechtigung root / sudo , um verwendet zu werden. Die Binärdatei sudo gibt dem normalen Benutzer die Berechtigung, Aktionen auf der Ebene root wie apt install zu verwenden.

Sie sollten nicht Linux ständig als root verwenden. Dies liegt daran, dass der Angreifer, wenn Sie kompromittiert werden, root Zugriff auf Ihr System hat, was bedeutet, dass er so ziemlich alles auf Ihrem System tun kann. Stattdessen führen Sie Linux als Nicht-Root-Benutzer aus, sodass der Angreifer selbst dann, wenn Ihr Konto kompromittiert wird, nicht sofort auf root zugreifen kann.

Natürlich kein System ist absolut sicher und irgendwo in Ihrem System kann etwas ausgenutzt werden. Die Verwendung eines sudoers -Kontos anstelle von root ist ein Schritt zur Sicherung Ihres Systems, wie oben beschrieben.

Wenn Sie sagen "Der Hacker wird es bekommen." Warum sollte ich überhaupt sudo verwenden? ", das ist wie zu sagen:" Wenn jemand in mein Haus kommt, kann er (irgendwie) trotzdem meinen Schmuck bekommen. Warum sollte ich einen Safe oder Schlösser benutzen? ". Es ist eine zusätzliche Schutzschicht. Wir suchen nicht nach "einer Sperre, die alles schützen kann" , sondern nach "vielen Sperren, um zusätzliche Sicherheit zu bieten, falls einige von ihnen kaputt gehen" .

sudo ist ein Schutz. Sie können Programme auf Root-Ebene nur dann ausführen, wenn Sie dies benötigen. Es ist so, dass Sie nur manchmal die Tür zu Ihrem TOP SECRET -Zimmer öffnen, anstatt immer es offen zu lassen, auch wenn es immer offen ist (immer läuft) als root) ist bequemer.

Wenn Sie ein legitimer Benutzer sind, führen Sie nicht jedes Mal, wenn Sie eine sudo -Aktion verwenden, Skripts zur Eskalation von Berechtigungen aus sudo .

Als Angreifer

Die sudo -Binärdatei kann genutzt werden, um Informationen zu erhalten oder sogar root -Zugriff zu erhalten. Manchmal haben die Benutzer in ihrer sudoers -Datei so etwas wie MY_USER ALL = (ALL) NOPASSWD: ALL . In diesem Fall können Sie als Benutzer MY_USER , Sie können alle sudo / root -Befehle ohne Kennwörter ausführen. Wenn Sie sudo -l ausführen, erhalten Sie möglicherweise auch Informationen darüber, welche Befehle Sie auch ohne Kennwort als root ausführen können. Ein Beispiel für eine solche Fehlkonfiguration wäre USERNAME ALL = (ALL) NOPASSWD: / bin / vi , mit dem Sie vi als root ohne Kennwort als Benutzer ausführen können BENUTZERNAME . Dies ist eine Möglichkeit, Berechtigungen manuell zu eskalieren.

Jedes zusätzliche Programm kann einige zusätzliche Sicherheitslücken aufweisen. Wenn Tomcat ausgeführt wird, wird das System in Tomcat-Exploits eingeführt. sudo ist möglicherweise nur ein anderes Programm, das Sie für Ihre Ausnutzung verwenden können.

Wie erhalten Sie Ihrer Meinung nach mit diesen praktischen Skripten / Tools zur Eskalation von Berechtigungen Root-Zugriff? Viele von ihnen verwenden sudo auf die eine oder andere Weise.

Es ist heute sehr einfach, Wurzeln zu schlagen (@reed gab ein einfaches Beispiel).Es gibt keinen Safe, der es fast wegschließt.Es ist nur in einer Box, die leicht zu finden ist.
@Wernight In Anbetracht des Beispiels von Reed ist es eher so, als ob es einfach ist, root zu werden, wenn Sie Benutzerzugriff haben und der Benutzer es Ihnen gibt.Ja, sicher, wenn Sie Zugriff auf Benutzerebene haben, wird es verdammt viel einfacher, root zu werden. Wenn Sie die Interaktion mit dem Benutzer einbeziehen (und dieser Benutzer gibt Ihnen zufällig sein root-Passwort, weil er etwas tun möchte, das dies erfordertoder es ist ihm egal, dass ihre Maschine plötzlich danach fragt).
#4
+19
Pedro
2020-06-08 20:36:33 UTC
view on stackexchange narkive permalink

Sudo ist alles andere als nutzlos.

Ein Administrator kann Berechtigungen flexibel und detailliert zuweisen und verfügt über Optionen zur Rechenschaftspflicht (anständige Protokollierung). Es ist eine wesentlich bessere Lösung für die Verwendung von Gruppen.

Wenn Sie es mit SELinux vergleichen, ist die Leistung und Fähigkeit von sudo natürlich sehr hoch Kosten für die Implementierung und Konfiguration (und Wartung).

Umgekehrt können sie aus Sicht eines Angreifers Glück haben und ein Konto mit sudo -Rechten erfassen oder Fehlkonfigurationen ausnutzen . Der Aufwand, von einem Standardbenutzer mit sudo -Berechtigungen zu root zu eskalieren, kann jedoch erheblich sein. Andererseits wird keines dieser Probleme durch sudo selbst verursacht.

Die Wirksamkeit hängt jedoch vollständig von der Konfiguration ab. Es ist trivial, einen Host zu privesc, wenn ein kompromittiertes Standardkonto irgendetwas als root ohne Passwort ausführen darf. Es ist schwieriger, aber durchaus machbar, wenn es bestimmte Befehle ausführen darf, die manipuliert werden können und Sehr schwierig, wenn nur sorgfältig ausgewählte Binärdateien und Situationen als root ausgeführt werden dürfen.

Auch sudo kann verwendet werden, um das Ausführen von Befehlen als andere Benutzer zu ermöglichen als root , also ist dies eine andere Möglichkeit, sudo zu verwenden, die möglicherweise nicht zu einem vollständigen Systemkompromiss führt.

Ich denke, die Eskalation ist für einen Standard-Linux-Benutzer extrem einfach.Ich mache die ganze Zeit "sudo apt update" äquivalent.Der Administrator ist ein fairer Punkt, obwohl ich nicht glaube, dass die meisten Desktop-Benutzer die Protokollierung einrichten würden und sobald ein Angreifer "root" hat, könnte diese Person die Protokolle entfernen (aber das ist schwieriger, stimme ich zu).Das habe ich bisher noch nie eingerichtet.
Das hängt ganz von der Sudo-Konfiguration ab.Es ist trivial, wenn der Benutzer etwas als root ausführen darf, es ist schwieriger, aber durchaus machbar, wenn er bestimmte Befehle ausführen darf, die manipuliert werden können, und ziemlich schwierig, wenn nur sorgfältig ausgewählte Binärdateien und Situationen als root ausgeführt werden dürfen.Sudo kann auch verwendet werden, um das Ausführen von Befehlen als andere Benutzer als root zu aktivieren. Dies ist also eine andere Möglichkeit, sudo zu verwenden, die kein direkter Weg in root ist.
Selbst wenn das Ausnutzen trivial ist, hängt es davon ab, ob der Benutzer mit dem System interagiert (indem er einen "sudo" -Befehl eingibt und sein Kennwort angibt).Je nach System kann dies eine erhebliche Hürde für sich sein, insbesondere wenn das Ziel des Angreifers zeitkritisch ist.
Ich denke, dieser Thread hat sehr gute Punkte für Systemadministratoren, die einen Park oder eine Unternehmensmaschine warten.Ein solches Setup ermöglicht die Protokollierung und kann lokale Sudoer-Aktionen beispielsweise nur auf bestimmte Binärdateien beschränken.Ich bin nicht davon überzeugt, dass dies bei den meisten Benutzern von PCs der Fall ist (oder bei den Standardeinstellungen der Distribution).Immer noch sehr gute Punkte im Corporate Case.
@Wernight - Ich kann nicht mit anderen Distributionen sprechen, aber die Debian-Standardkonfiguration "sudo" beinhaltet die Protokollierung in "/ var / log / auth.log".Natürlich ist es eine ganz andere Frage, ob der durchschnittliche Heimanwender diese Protokolle jemals tatsächlich überprüfen wird ...
#5
+18
Eliah Kagan
2020-06-09 00:50:39 UTC
view on stackexchange narkive permalink

sudo ist genauso sicher oder unsicher wie seine beliebten Alternativen wie su .

Die beliebteste Alternative sudo bedeutet, dass einige oder alle Benutzer ihre Berechtigungen mit su erhöhen können. In den meisten Fällen ist dies allen Benutzern gestattet, solange sie das Kennwort des Zielbenutzers kennen. Im Gegensatz zu sudo , das fast immer so eingerichtet ist, dass ein eigenes Kennwort eines Benutzers erforderlich ist (und nur auf vertrauenswürdige Benutzer beschränkt ist), erfordert su das Kennwort des Zielbenutzers

Einige Leute gehen davon aus, dass dies su sicherer macht als sudo , aber nicht. su ist denselben Angriffen ausgesetzt wie sudo . Angenommen, Sie sind ein Benutzer, der manchmal su ausführt, um root zu werden. Angenommen, ein Angreifer, der das Kennwort von root nicht kennt und noch keine Aktionen ausführen kann, da der Root-Benutzer dennoch beliebigen Code als Ihr Nicht-Root-Konto ausführen kann. So wie dieser Angreifer es schaffen kann, dass Sie beim Ausführen von sudo seinen böswilligen Befehl ausführen, kann dieser Angreifer es auch so machen, dass Sie beim Ausführen von su ' Führen Sie den böswilligen Befehl erneut aus.

Das heißt, die Technik in reeds Antwort funktioniert genauso gut, um einen gefälschten su -Befehl einzuführen, der das Kennwort von erfasst Der Benutzer target (der, wenn su zur Verwaltung des Systems verwendet wird, normalerweise root ist).

Aber es ist möglich, es besser zu machen als beide, oder um das Risiko zu minimieren.

Sobald jemand Befehle wie Sie ausführen kann, kann er normalerweise willkürliche Änderungen am Verhalten Ihrer Shell vornehmen und so gefälschten sudo , su , doas oder andere Befehle zur Erhöhung von Berechtigungen.

Solange Sie jedoch die Interaktion mit einem gefälschten Anmeldebildschirm vermeiden können, können Sie dies durch getrennte administrative und nicht administrative Benutzerkonten abmildern. Das klingt nicht nach einer neuen Idee und ist es natürlich auch nicht, aber es ist überraschend, wie selten dies wirklich getan wird.

Ihr Administratorkonto könnte sei einfach das Root-Konto. Wenn Sie jedoch die Vorteile einer Nichtanmeldung als Root nutzen möchten, einschließlich der Protokollierung (um herauszufinden, was bei nicht böswilligen Fehlern schief gelaufen ist) und der Möglichkeit, Programme auszuführen, die nicht als Root ausgeführt werden sollen (die meisten) grafische Oberflächen), dann können Sie zwei Nicht-Root-Konten haben, von denen eines für die Verwaltung verwendet wird (in denen Sie je nach Bedarf sudo oder su ausführen) und das andere Dies ist nicht der Fall.

Dieses Konto sollte, wenn natürlich nicht Zugriffsdaten mit dem nicht administrativen Konto teilen. Sie sollten keine identischen oder ähnlichen Passwörter haben und separate Schlüsselpaare. Darüber hinaus dürfen Sie nicht vom nicht administrativen Konto zum administrativen Konto aufsteigen, aus demselben Grund dürfen Sie nicht vom nicht administrativen Konto zum Root aufsteigen.

Wenn Sie dies tun, gibt es sogar ein Argument für sudo gegenüber seinen Alternativen.

In diesem Setup gibt es einen Vorteil von sudo gegenüber su , obwohl dies kein entscheidender Vorteil ist. Sie können vermeiden, versehentlich das falsche Konto zu verwenden - das Konto, das für alle Arten anderer nicht administrativer Dinge verwendet wird, die es einem höheren Risiko aussetzen können -, um das System zu verwalten, indem Sie es so gestalten, dass es nur ein reguläres eingeschränktes Benutzerkonto ist Das ist nicht in der Datei / etc / sudoers aufgeführt und gehört keiner Gruppe an.

Sie können dieses Ziel aber auch mit su erreichen, indem Sie entweder die richtige Selbstdisziplin anwenden und sicherstellen, dass Sie niemals su von dem von Ihnen erstellten Konto aus arbeiten als nicht administrativ oder indem verhindert wird, dass als nicht administrativ bezeichnete Konten die Berechtigungen mit su erhöhen. (Eine Möglichkeit, dies auf einem GNU / Linux-System zu erreichen, ist AppArmor. Auf diese Weise hat Ubuntu verhindert, dass das Gastkonto su jemals erfolgreich verwendet hat - in früheren Versionen von Ubuntu, mit denen es ausgeliefert wurde Gastkonten aktiviert.)

Das Risiko, sudo oder su auf die übliche Weise zu verwenden, kann für Sie akzeptabel sein.

Trotz allem sage ich nicht, dass Sie dies unbedingt tun müssen. Es liegt an Ihnen oder gegebenenfalls an Ihnen und anderen Interessengruppen.

Für viele Menschen steigen die Risiken, die mit der Verwendung desselben Kontos für (a) verbunden sind sudo (oder ähnliche Mechanismen wie Polkit) oder su (oder ähnliche Mechanismen wie doas ), wie sie für (b) verwendet werden em> Nicht administrative Aufgaben wie das Ausführen eines Webbrowsers können aus Bequemlichkeitsgründen ein akzeptabler Kompromiss sein.

+1 für die Protokollierung, wer was getan hat.Das ist sehr praktisch für die spätere Forensik, selbst wenn es vollständig verinnerlicht ist.
#6
+17
Jörg W Mittag
2020-06-10 15:44:02 UTC
view on stackexchange narkive permalink

Der Punkt von sudo ist nicht , um das Erhöhen von Berechtigungen zu erschweren. Es ist in der Tat genau das Gegenteil: Es geht darum, es einfach zu machen, Berechtigungen zu erhöhen.

Indem Sie es einfach machen, Berechtigungen zu erhöhen, wenn Sie sie benötigen haben Benutzer weniger Anreize, mit erhöhten Berechtigungen immer zu arbeiten.

Wenn Sie es schwierig machen, Berechtigungen zu erhöhen, melden sich Benutzer einfach als root an die ganze Zeit. Durch die einfache Erhöhung der Berechtigungen "on-the-fly" werden Benutzer aufgefordert, sich als nicht privilegierte Benutzer anzumelden und die Berechtigungen nur für einen einzelnen Prozess für die Dauer dieses Prozesses zu erhöhen, anstatt ständig mit erhöhten Berechtigungen ausgeführt zu werden.

sudo ist im Grunde ein Usability -Tool, kein Sicherheitstool. Die Sicherheitseffekte von sudo sind Konsequenzen zweiter Ordnung der Usability-Effekte. Sicherheit ist nicht nützlich, wenn sie nicht verwendet werden kann.

In diesem Fall entspricht sudo in etwa der Benutzerkontensteuerung in Windows Vista +, die auch häufig als Tool zur Verhinderung der Erhöhung von Berechtigungen missverstanden wird. Tatsächlich ist es ein Werkzeug, um die Erhöhung von Berechtigungen zu vereinfachen. Vor der Einführung der Benutzerkontensteuerung war es für Windows-Benutzer völlig normal, sich immer bei einem Konto mit Administratorrechten anzumelden, da Windows ansonsten für alles andere als die grundlegende Verwendung im Büro unbrauchbar war.

Es gibt einen zusätzlichen Vorteil sudo über su oder als root anmelden, dh sudo kann so konfiguriert werden, dass ein Audit-Trail hinterlassen wird von welchem ​​Benutzer welcher privilegierte Befehl zu welcher Zeit ausgegeben hat.

Das fasst es gut zusammen.
#7
+9
Tom
2020-06-09 17:00:07 UTC
view on stackexchange narkive permalink

Wie alles in der Informationssicherheit ist sudo ein Trade-Off .

Lassen Sie uns die Alternativen untersuchen:

  • Ändern Sie das System so, dass das Für Befehle, für die Sie sudo verwenden, sind keine Berechtigungen auf Stammebene erforderlich.
  • Melden Sie sich als root an, um die erforderlichen Zugriffsrechte zu erhalten.
  • Verwenden Sie su, um zu a zu wechseln Root-Shell
  • Wenn der Befehl selbst als Root ausgeführt wird, unabhängig davon, wer ihn ausführt

, ohne auf die Details einzugehen, hoffe ich, dass Sie all diesen Alternativen zustimmen sind schlimmer als sudo . Es ist nicht perfekt, es kann angegriffen werden - aber es ist die beste unter diesen Alternativen.

Vergessen Sie in Bezug auf SELinux nicht, dass es relativ spät in die Show kam. Ich kann mich nicht erinnern, in welchem ​​Jahr (und zum Teufel, ich war dort, mein Name steht in den SELinux-Anmeldeinformationen), aber sudo datiert SELinux erheblich vor.

Und während SELinux ist Zweifellos die leistungsstärkere und sicherere Alternative. Die meisten Systemadministratoren sind nicht in der Lage, eine ordnungsgemäße SELinux-Sicherheitsrichtlinie zu schreiben.

Alles in allem ist sudo ist in vielen Fällen die am wenigsten schlechte. Es ist besser als nichts oder seine Alternativen, und das ist Grund genug. Keine Sicherheit ist sowieso perfekt.


Alles in allem ist die Hauptverwendung für sudo im Unternehmen nicht die Sicherheit, sondern die Rechenschaftspflicht . Wenn sich Administratoren mit einem persönlichen Konto anmelden und dann sudo für ihre tägliche Arbeit verwenden müssen, ist es trivial zu verfolgen, wer was getan hat. Und mit auditd können Sie sie weiter verfolgen, wenn sie auch su verwenden.

#8
+6
Martin Rosenau
2020-06-09 11:19:05 UTC
view on stackexchange narkive permalink

Dies hängt davon ab, wie Sie sudo :

konfigurieren. Auf einem Computer, der von verschiedenen Personen verwendet wird, können Sie sudo so konfigurieren, dass bestimmte Benutzer dies tun Zugriff auf bestimmte Befehle mit sudo :

Sie können sudo so konfigurieren, dass einige Benutzer einen bestimmten Befehl ausführen können (z. B. ip ) mit sudo - aber keinem anderen Befehl.

Die andere Sache ist, dass sudo so konfiguriert werden sollte, dass Sie gefragt werden für ein Passwort. Selbst wenn ein Angreifer Zugriff auf eine Konsole hat, wird er nach Ihrem Kennwort gefragt, wenn er den sudo-Beispielbefehl eingibt.

Sie können auch sudo konfigurieren Auf eine Weise, dass für bestimmte Befehle (z. B. ip ) kein Kennwort erforderlich ist und für alle anderen Befehle die Eingabe Ihres Kennworts erforderlich ist.

Außerdem ist es möglich, sudo in einer Weise, dass das für sudo erforderliche Kennwort von Ihrem Anmeldekennwort abweicht.

In diesem Fall hilft selbst Ihr Anmeldekennwort dem Angreifer nicht.

Wenn Sie jedoch sudo so konfigurieren, dass Sie alle Befehle ausführen können und nicht nach einem Kennwort gefragt werden, ist dies bei sudo der Fall keine Sicherheit bieten.

#9
+4
gmatht
2020-06-09 13:18:23 UTC
view on stackexchange narkive permalink

Fast alles ohne einen sicheren Aufmerksamkeitsschlüssel ist "fast nutzlos".

Reed gibt eine hervorragende Antwort darauf, warum sudo (oder zumindest) seine Passwortfunktion) ist aus Sicherheitsgründen fast unbrauchbar. Dies ist jedoch nicht nur ein Fehler in sudo , bash oder sogar in der gesamten Unix-Umgebung. Es ist ein allgemeines Problem, höhere Berechtigungen mithilfe eines Kennworts ohne irgendeine Technik zu erhalten, um gefälschte Anmeldeaufforderungen zu vermeiden.

Beginnen Sie mit zsh , fish und sogar Über die Windows-Eingabeaufforderung können Sie anpassen, welcher Befehl ausgeführt wird. Wenn Sie also zu einer anderen Shell wechseln, wird ein Angreifer nicht daran gehindert, fake_sudo durch sudo zu ersetzen.

Dies ist nicht nur die Unix-Umgebung. Stellen Sie sich vor, Sie gehen in Windows zu Start> Profil ändern und geben das Administratorkennwort ein. Opps, ein Angreifer hat Explorer.exe durch fake_Explorer.exe ersetzt, das war nicht die echte Starttaste, die Sie gedrückt haben. Wieder hat der Angreifer Ihr Administratorkennwort.

Für diese Zwecke wird manchmal ein sicherer Aufmerksamkeitsschlüssel verwendet. Möglicherweise wurde manchmal ein Windows-Anmeldebildschirm mit der Aufschrift "Drücken Sie Strg-Alt-Entf" angezeigt, um sich anzumelden. Dies liegt daran, dass Strg-Alt-Entf direkt zum Betriebssystem wechselt und nicht von einer gefälschten Login-Shell gefälscht werden kann. Da Strg-Alt-Entf verwendet werden kann, um die Aufmerksamkeit des Betriebssystems sicher zu erregen, wird es als sicherer Aufmerksamkeitsschlüssel bezeichnet.

Es gibt einige Alternativen zu einem sicheren Aufmerksamkeitsschlüssel. Sie können beispielsweise ein Bild auswählen, das beim Anmelden angezeigt wird. Speichern Sie das Bild besser nicht dort, wo nicht privilegierte Prozesse es lesen können, oder zeigen Sie es dort an, wo nicht privilegierte Prozesse es scannen können. Daher muss der Anmeldebildschirm immer noch vom nicht privilegierten allgemeinen Arbeitskonto getrennt werden, wie dies bei Tools wie sudo nicht der Fall ist.

Angesichts der Tatsache, dass Administratoren in einem Unternehmen 99% ihrer Arbeit remote erledigen, macht es keinen Unterschied, ob sie einen Schlüssel haben oder nicht.
Ich denke, aber wenn ich remote arbeite, würde ich einen SSH-Schlüssel zur Authentifizierung anstelle eines Sudo-Passworts verwenden.Ich habe expliziter gemacht, dass ich nur über die Passwortauthentifizierung spreche.
Linux hat bereits SAK (Secure Attention Key) als Alt + SysRq + K (sofern nicht von Ihrer Distribution deaktiviert).Die * Implementierung * davon ist jedoch für den normalen Gebrauch nahezu unbrauchbar, weshalb sie in der Praxis nicht verwendet wird.Außerdem wird "sudo" häufig mit Remote-Hosts verwendet, und dort können Sie per Definition kein SAK haben.Wenn Sie auf das Remote-System zugreifen, müssen Sie dem Remote-System alle von Ihnen bereitgestellten Eingaben anvertrauen.Wenn Sie bei einer Eingabe ein Kennwort eingeben, muss das System sicher sein.
#10
+4
just_floating
2020-06-10 01:04:18 UTC
view on stackexchange narkive permalink

Ich hatte einmal das Problem, mich über SSH-Schlüssel bei meinem Server anzumelden und mein Passwort für die Verwendung mit sudo zu vergessen, was diese Idee nahe legt:

Ich nehme an, dass es Kompromisse gibt SSH-Anmeldeinformationen, beispielsweise von einer nicht gelöschten Festplatte in einem Müllcontainer wiederhergestellt, dann kann sudo hilfreich sein, da für die Ausführung von Administratorfunktionen ein Kennwort erforderlich ist. Ich habe keine Beweise, aber ich vermute, dass viele SSH-Schlüssel kein Passwort haben.

Ein realistischerer Angriffsvektor mit diesem sudo -Problem sind SSH-Schlüssel, die auf Github verbleiben.

#11
+4
James Tocknell
2020-06-10 13:11:38 UTC
view on stackexchange narkive permalink

Was bisher noch nicht erwähnt wurde, ist, dass sudo (über PAM) andere Mechanismen als ein Passwort und / oder eine 2-Faktor-Authentifizierung verwenden kann. Dies löst zwar nicht das Problem mit dem kompromittierten Konto, erschwert jedoch das Fälschen einer Eingabeaufforderung.

Darüber hinaus hat sudo seine Verwendungszwecke außerhalb der Bereitstellung eines vollständigen Root-Zugriffs. Es kann verwendet werden, um einem bestimmten Benutzer dies zu ermöglichen Führen Sie einen bestimmten Befehl aus, und keinen anderen als root oder sogar als anderen Benutzer. Ich bin mir nicht sicher, ob SELinux für diesen Anwendungsfall so einfach zu konfigurieren wäre.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...