{"id":13160,"date":"2025-07-21T22:30:00","date_gmt":"2025-07-21T20:30:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=13160"},"modified":"2025-07-25T13:08:20","modified_gmt":"2025-07-25T11:08:20","slug":"einstieg-in-sudo","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/einstieg-in-sudo\/","title":{"rendered":"Einstieg in „sudo“ f\u00fcr Raspberry Pi & andere GNU\/Linux-Systeme"},"content":{"rendered":"

Viele Anleitungen enthalten Befehle mit vorangestelltem sudo<\/code>. Sie blind zu \u00fcbernehmen, kann gef\u00e4hrlich werden. Im folgenden Beitrag erf\u00e4hrst du, was das ist, wie es funktioniert und wie das Werkzeug zur Verbesserung der Sicherheit genutzt werden kann. Dieser richtet sich an Raspberry Pi Nutzer gleicherma\u00dfen wie alle anderen, die GNU\/Linux auf PCs, Servern oder sonstigen Ger\u00e4ten einsetzen.<\/p>\n

Warum arbeiten wir nicht einfach<\/em> als Root\/Admin?<\/h2>\n

Ein Nutzer sollte nur so viele Rechte besitzen, wie er ben\u00f6tigt – das ist seit Jahrzehnten ein bew\u00e4hrter Grundsatz. Wer im Alltag mit einem privilegierten Konto (root\/Administrator) arbeitet, geht ein hohes Risiko ein. Immerhin hat jedes damit gestartete Programm uneingeschr\u00e4nkt volle Rechte auf dem gesamten System. Fehler oder Sicherheitsl\u00fccken in der genutzten Software k\u00f6nnen damit weitreichende Folgen haben. Allerdings ben\u00f6tigt man f\u00fcr bestimmte Aufgaben volle Rechte: Beispielsweise die Installation von Software oder um Dienste (neu) zu starten – kurz alle Aufgaben, die sich global auf das System auswirken, statt nur<\/em> den angemeldeten Benutzer. Wie macht man das, ohne st\u00e4ndig mit einem Root-Benutzer zu arbeiten?<\/p>\n

Man k\u00f6nnte im Alltag einen normalen Nutzer verwenden und nur f\u00fcr die administrativen Aufgaben zu Root wechseln. Daf\u00fcr existiert das GNU\/Linux Werkzeug su<\/code>: Es meldet vereinfacht gesagt einen anderen Nutzer in der laufenden Sitzung an. Als Benutzer X angemeldet l\u00e4sst sich so zeitweise eine Konsole mit Benutzer Y \u00f6ffnen. Ohne \u00dcbergabe eines Benutzernamens \u00f6ffnet su<\/code> eine Root-Shell.1<\/a><\/sup> Das hat jedoch mehrere Nachteile. So landen eingegebene Befehle in der Bash-Historie von root, statt unserem eigenen Benutzer. Dies kann an verschiedenen Stellen problematisch sein – etwa wenn Programme Dateien in das Benutzerprofil ablegen. Ein Programm, dass nur an einer einzigen Stelle Root-Rechte ben\u00f6tigt (z.B. zum einmaligen Anlegen systemweiter Konfigurationsdateien), muss somit im ung\u00fcnstigsten Falle st\u00e4ndig mit vollen Rechten laufen.<\/p>\n

Nicht jeder Student sollte volle Root-Rechte haben – sudo regelt das<\/h2>\n

Ein weiteres Problem: Um su nutzen zu k\u00f6nnen, wird das Passwort des Nutzers root<\/em> ben\u00f6tigt. Damit hat die betreffende Person uneingeschr\u00e4nkte Rechte. Das mag f\u00fcr Administratoren noch akzeptabel sein, bei Studenten beispielsweise schon schwieriger. Bereits Anfang der 1980er Jahre entstand sudo f\u00fcr das damals g\u00e4ngige Unix, um Root-Rechte f\u00fcr einzelne Befehle zu erlauben. Insbesondere jene, die keine oder eine \u00fcberschaubare Gefahr f\u00fcr das System darstellen. Darunter k\u00f6nnten z.B. das Einspielen von Software-Aktualisierungen oder Neustarten von (harmlosen) Diensten fallen. Auf einem lokalen Arbeitsplatz\/Test-PC wohl auch das Neustarten, was standardm\u00e4\u00dfig als normaler Benutzer nicht per Kommandozeile m\u00f6glich ist. Das Konzept setzte sich durch, sodass sudo<\/code> auch zu GNU\/Linux portiert wurde, nachdem Linux 1991 erschien.<\/p>\n

u-labs@pi4:~ $ reboot\nCall to Reboot failed: Interactive authentication required.<\/code><\/pre>\n
Sudo kann noch mehr: Das sind die wichtigsten Funktionen<\/h2>\n
Soll ein Befehl mit erh\u00f6hten Rechten ausgef\u00fchrt werden, gen\u00fcgt es nach der einmaligen Einrichtung f\u00fcr den angemeldeten Benutzer meist, sudo<\/code> davor zu schreiben. Im Gegensatz zu su<\/code> entf\u00e4llt die l\u00e4stige manuelle An- und Abmeldung als Root. Intern passiert etwas \u00e4hnliches, das den Arbeitsfluss aus Nutzersicht nicht unterbricht. Au\u00dferdem landet alles im Bash-Verlauf des normalen Nutzers. Man kann sogar einstellen, ob zur Best\u00e4tigung ein Passwort eingegeben werden muss – wenn ja, in welchem Intervall.<\/p>\n
Der gr\u00f6\u00dfte Vorteil von sudo sind die umfangreichen Einstellungsm\u00f6glichkeiten, welche im Detail den Rahmen dieses Einstiegsbeitrages sprengen w\u00fcrden. Ich fokussiere mich daher im Folgenden auf die grunds\u00e4tzliche Funktionsweise mit einfacheren Beispielen. Ebenfalls interessant k\u00f6nnen die Protokolle von sudo sein. Damit l\u00e4sst sich nachvollziehen, welcher Nutzer sudo wof\u00fcr genutzt hat. Oder nutzen wollte, da unberechtigte Aufrufe ebenfalls aufgezeichnet werden.<\/p>\n
Wie kann ich sudo konfigurieren?<\/h2>\n
Grunds\u00e4tzlich brauchst du daf\u00fcr root-Rechte. Einige einsteigerfreundliche Distributionen sind automatisch so voreingestellt, dass sie dem von dir bei der Installation angelegten Nutzer automatisch Sudo-Rechte gew\u00e4hren – hierzu z\u00e4hlt unter anderem das Raspberry Pi OS. Man kann es leicht wie folgt testen:<\/p>\n
u-labs@pi5:~ $ sudo whoami\nroot<\/code><\/pre>\n
M\u00f6glicherweise werdet ihr bei manchen Distributionen zur Eingabe des Passworts eures Kontos aufgefordert. Falls root<\/em> als Ausgabe erscheint, k\u00f6nnt ihr sudo verwenden. Andernfalls erscheint eine Fehlermeldung:<\/p>\n
student@pi5:~$ sudo whoami\n[sudo] password for student: \nstudent is not in the sudoers file.<\/code><\/pre>\n
In diesem Falle bleibt dir nur die direkte Anmeldung mit dem root Benutzerkonto, um zumindest dein normales Konto erst einmal zu berechtigen. Wie das funktioniert, schauen wir uns im folgenden Abschnitt an. Anschlie\u00dfend kann die weitere, ggf. detailliertere Einrichtung von deinem regul\u00e4ren Nutzer geschehen.<\/p>\n
Was erlaubt dir sudo? So konfigurierst du Berechtigungen<\/h2>\n
Die Haupt-Konfiguration erfolgt \u00fcber \/etc\/sudoers<\/code>.2<\/a><\/sup> Man sollte sie allerdings nicht direkt bearbeiten: Im Falle von (versehentlichen) Syntaxfehlern funktioniert sudo nicht mehr richtig. Um das zu reparieren, ist eine direkte Anmeldung als root n\u00f6tig. Das kann aufw\u00e4ndiger werden, insbesondere falls es sich um ein entferntes System handelt, welches die Anmeldung als root zur Sicherheit verbietet. Daher besser das daf\u00fcr vorgesehene Werkzeug visudo<\/code> verwenden: Es speichert \u00c4nderungen zuerst in eine tempor\u00e4re Datei und pr\u00fcft, ob man sich an die Regeln der Konfigurationssprache gehalten hat. Falls nein, lassen sich Fehler korrigieren, bevor diese in \/etc\/sudoers<\/code> landen:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Wie man am Name vermuten kann, verwendet visudo<\/code> standardm\u00e4\u00dfig den Texteditor vi<\/code> (bzw. heute eher vim<\/code>). Da die Umgebungsvariable EDITOR respektiert wird, startet es – je nach Konfiguration durch die Distribution und den Benutzer – m\u00f6glicherweise einen anderen Editor, etwa Nano auf dem Raspberry Pi OS. visudo<\/code> muss als root aufgerufen werden.<\/p>\n
sudo EDITOR=nano visudo<\/code><\/pre>\n
Bei vielen Distributionen findest du hier Voreinstellungen. Zwei davon sind daf\u00fcr zust\u00e4ndig, dass wir auf einem frisch installierten Raspberry Pi OS mit unserem eigenen Benutzer ohne Passwort oder weitere Einstellungen sudo verwenden k\u00f6nnen:<\/p>\n
%sudo   ALL=(ALL:ALL) ALL<\/code><\/pre>\n
Damit darf jedes Mitglied der sudo Gruppe uneingeschr\u00e4nkt jegliche administrativen Befehle ausf\u00fchren. Standardm\u00e4\u00dfig wird man jedoch nach dem Passwort des angemeldeten Nutzers gefragt. Das geschieht beim Raspberry Pi OS nicht, weil sudo zus\u00e4tzlich alle Konfigurationsdateien in \/etc\/sudoers.d l\u00e4dt. Dort wiederum legt der Einrichtungsassistent vom RPIOS die Datei \/etc\/sudoers.d\/010_pi-nopasswd<\/code> an:<\/p>\n
u-labs ALL=(ALL) NOPASSWD: ALL<\/code><\/pre>\n
Durch NOPASSWD: ALL<\/code> erlaubt es, alle Befehle ohne Passworteingabe sofort auszuf\u00fchren. Grunds\u00e4tzlich beginnt die Zeile mit einem Benutzername (hier u-labs<\/em>) oder dem Name einer Gruppe (mit vorangestelltem Prozentzeichen: %sudo<\/code> im vorherigen Beispiel). Es folgen m\u00f6gliche Einschr\u00e4nkungen auf den Rechnername (Host), Zielbenutzer\/Gruppe, optional zus\u00e4tzliche Anweisungen mit Doppelpunkt (etwa NOPASSWD:<\/code>) und schlussendlich den oder die Befehle. ALL<\/em> dient als Platzhalter f\u00fcr keine Beschr\u00e4nkungen.<\/p>\n
[Benutzer\/Gruppe] [Rechnername]=[Zielbenutzer\/Zielgruppe] [Optionen:] [Erlaubter Befehl]<\/code><\/pre>\n
Bereits bei diesem grunds\u00e4tzlichen Aufbau der Regeln wird deutlich, dass sudo<\/code> viel mehr M\u00f6glichkeiten bietet, als nur<\/em> einzelne Befehle mit Root-Rechten auszuf\u00fchren. Man kann einem Benutzer A beispielsweise auch erlauben, bestimmte Befehle als Nutzer B zu starten. Ein Befehl kann ohne Eingabe des Passwortes erfolgen, f\u00fcr einen anderen (sensibleren) dagegen wird dies erzwungen.<\/p>\n
Praktische & einfache Beispiele<\/h2>\n
Die Liste lie\u00dfe sich fortsetzen, schauen wir uns stattdessen einfachere Regeln an konkreten Beispielen an. Ich habe daf\u00fcr einen Benutzer namens student<\/em> angelegt – ganz simpel mit useradd<\/em>, sodass dieser keine besonderen Rechte besitzt. Auf dem Testsystem wurde ein Apache2 Webserver installiert und als Systemd-Dienst gestartet. Der student<\/em> Benutzer darf den Dienst nicht neu starten – was allerdings sinnvoll sein k\u00f6nnte, etwa um auf einem Testsystem Konfigurations\u00e4nderungen anzuwenden.<\/p>\n
student@pi5:~$ systemctl restart apache2\n==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====\nAuthentication is required to restart 'apache2.service'.\nAuthenticating as: ,,, (u-labs)\nPassword:\n\nstudent@pi5:~$ sudo systemctl restart apache2\n[sudo] password for student: \nSorry, user student is not allowed to execute '\/usr\/bin\/systemctl restart apache2' as root on pi5.<\/code><\/pre>\n
Um ihm dies mit sudo zu erlauben, gen\u00fcgt folgende Zeile:<\/p>\n
student ALL=(root) NOPASSWD: \/usr\/bin\/systemctl restart apache2<\/code><\/pre>\n
Damit darf er an jedem Rechner mit dieser Konfiguration als root ohne Passworteingabe den Befehl systemctl restart apache2<\/code> ausf\u00fchren. Weder Neustart noch neu Anmelden sind daf\u00fcr notwendig, die \u00c4nderung ist sofort wirksam:<\/p>\n
student@pi5:~$ sudo systemctl restart apache2\nstudent@pi5:~$ systemctl status apache2\n\u25cf apache2.service - The Apache HTTP Server\n     Loaded: loaded (\/lib\/systemd\/system\/apache2.service; enabled; preset: enabled)\n     Active: active (running) since Mon 2024-05-13 23:49:12 CEST; 5s ago<\/code><\/pre>\n
Wichtig zu wissen: Sudo wertet den gesamten Befehl aus und erfordert eine exakte \u00dcbereinstimmung. Die Systemd-Unit von Apache2 ist ein Dienst (Service), daher k\u00f6nnten wir ihn vollqualifiziert \u00fcber apache2.service<\/code> ansprechen. Unser student<\/em> darf das allerdings nicht, weil wir ihm lediglich systemctl restart apache2<\/code> erlaubt haben:<\/p>\n
student@pi5:~$ sudo systemctl restart apache2.service\n[sudo] password for student: \nSorry, user student is not allowed to execute '\/usr\/bin\/systemctl restart apache2.service' as root on pi5.<\/code><\/pre>\n
Dementsprechend sind andere Operationen wie z.B. systemctl stop apache2<\/code> ebenfalls verboten. M\u00f6chten wir Start & Stop ebenfalls erlauben, k\u00f6nnen mehrere Befehle mit Komma getrennt werden:<\/p>\n
student ALL=(root) NOPASSWD: \/usr\/bin\/systemctl restart apache2, \/usr\/bin\/systemctl start apache2, \/usr\/bin\/systemctl stop apache2<\/code><\/pre>\n
Solche und komplexere Muster lassen sich mit regul\u00e4ren Ausdr\u00fccken abbilden. Was sich zwischen ^ und $ befindet, wird als regul\u00e4rer Ausdruck ausgewertet.3<\/a><\/sup> Alle drei Systemd-Operationen f\u00fcr Apache lassen sich daher einfacher mit einem ODER (|) erlauben:<\/p>\n
student ALL=(root) NOPASSWD: \/usr\/bin\/systemctl ^(restart|start|stop) apache2$<\/code><\/pre>\n
Durch ein Ausrufezeichen lassen sich einzelne Befehle verbieten. Folgendes Beispiel erlaubt alle Systemd-Operationen, sodass alles zwischen systemctl<\/code> und apache2<\/code> stehen darf. Anschlie\u00dfend wird der Stop-Aufruf aber als einziger Verboten.<\/p>\n
student ALL=(root) NOPASSWD: \/usr\/bin\/systemctl ^(.+) apache2$, !\/usr\/bin\/systemctl stop apache2<\/code><\/pre>\n
Sicherheit: Wie man die Regeln manchmal \u00fcber Umwege umgehen kann<\/h2>\n
Dieses Szenario zeigt jedoch, wie gef\u00e4hrlich solche universellen Platzhalter sein k\u00f6nnen. Folgender Aufruf umgeht die Einschr\u00e4nkung:<\/p>\n
student@pi5:~$ sudo systemctl stop ab apache2\nFailed to stop ab.service: Unit ab.service not loaded.\nstudent@pi5:~$ sudo systemctl status apache2\n\u25cb apache2.service - The Apache HTTP Server\n     Loaded: loaded (\/lib\/systemd\/system\/apache2.service; enabled; preset: enabled)\n     Active: inactive (dead) since Tue 2024-05-14 00:13:19 CEST; 2s ago<\/code><\/pre>\n
Wie ist das m\u00f6glich? Systemd akzeptiert den Namen mehrerer Dienste und f\u00fchrt in diesem Falle die Operation nacheinander auf alle aus. Fehlende Dienste verursachen keinen Abbruch, er f\u00e4hrt mit dem n\u00e4chsten fort. Da nur systemctl stop apache2<\/code> explizit ausgeschlossen wurde (das wird wie erwartet verweigert), nicht aber weitere Dienste dazwischen, greift die Ausnahme nicht.<\/p>\n
student@pi5:~$ sudo systemctl stop apache2\nSorry, user student is not allowed to execute '\/usr\/bin\/systemctl stop apache2' as root on pi5.<\/code><\/pre>\n
Man sollte mit Platzhaltern und insbesondere Regex daher aufpassen. Falls notwendig, die gew\u00fcnschten Optionen stattdessen auflisten. Das vorherige Beispiel mit entferntem stop<\/em>, also \/usr\/bin\/systemctl ^(restart|start) apache2$<\/code>, ist sicherer: Es erlaubt nur systemctl restart apache2<\/code> und systemctl start apache2<\/code>, sodass der Trick nicht funktioniert.<\/p>\n
Die zweite Gefahr besteht darin, ganze Programme zu erlauben, die wiederum direkt oder indirekt das Ausbrechen erm\u00f6glichen. Ein Beispiel sind Texteditoren:<\/p>\n
student ALL=(root) NOPASSWD: \/usr\/bin\/nano<\/code><\/pre>\n
Damit darf der einfache Editor Nano als root gestartet werden. Der Editor hat somit unbegrenzte Schreibrechte auf dem gesamten System. Beispielsweise k\u00f6nnte er in \/etc\/sudoers.d<\/code> eine Konfigurationsdatei anlegen, die seinem Nutzer uneingeschr\u00e4nkt volle Rechte gibt. Oder bestehende Skripte \u00fcberschreiben, die auf anderem Wege gewollt von root ausgef\u00fchrt werden. \u00dcber m\u00e4chtigere Editoren wie vim ist es sogar m\u00f6glich, direkt Code (Shell, Python, …) auszuf\u00fchren. GTFOBins sammelt derartige legitime Funktionen, die in Kombination mit weitreichenden sudo-Regeln zur Rechteausweitung missbraucht werden k\u00f6nnen.4<\/a><\/sup><\/p>\n
Es ist nicht zu untersch\u00e4tzen, welche m\u00e4chtigen und oft unerwarteten Funktionen in vermeintlich simpler Software stecken k\u00f6nnen. Ein Beispiel ist tar zum Entpacken der gleichnamigen Archive. Dies bietet Checkpoints, um w\u00e4hrend des (ent) packens regelm\u00e4\u00dfig bestimmte Befehle auszuf\u00fchren, als eine Art Status.5<\/a><\/sup> Dar\u00fcber l\u00e4sst sich Code ausf\u00fchren und so etwa eine Konsole starten:6<\/a><\/sup><\/p>\n
sudo \/bin\/tar -cf \/dev\/null \/dev\/null --checkpoint=1 --checkpoint-action=exec=\/bin\/sh<\/code><\/pre>\n
Damit sudo sicher ist, sollte man sich daher vor der Freigabe einer Anwendung genauer \u00fcber deren M\u00f6glichkeiten informieren und die ausf\u00fchrbaren Befehle soweit wie m\u00f6glich einschr\u00e4nken. Im Zweifel hinterfragen bzw. komplexe Anwendungen gar nicht erst freigeben. Manche Dinge sind schlicht nicht abbildbar, wenn man gewisse Verkettungen bedenkt. Darf der Nutzer z.B. auf die Unit-Dateien eines Systemd-Dienstes schreiben, kann er sie ver\u00e4ndern und damit indirekt mehr Rechte erhalten. Hier ist auch f\u00fcr das umfangreiche sudo eine Grenze erreicht, bei der nur noch eines hilft: Das Systemd-Unit wird in diesem Beispiel vom Haupt-Administrator (dir) angelegt – nur du hast die Rechte darauf, f\u00fcr \u00c4nderungen m\u00fcssen andere involvierte Personen auf dich zukommen. <\/p>\n
In diesem Beispiel v\u00f6llig unproblematisch, da man Systemd-Units nach dem Anlegen in der Regel nicht mehr anpasst bzw. dies bei Notwendigkeit anderweitig l\u00f6sen kann, etwa \u00fcber Startskripte. Nachdem Systemd dieses Skript mit einem im Unit festgelegten eingeschr\u00e4nkten Nutzer startet, l\u00e4sst sich die Rechteausweitung auf root damit bei sauberer Konfiguration vermeiden.<\/p>\n
Protokollierung<\/h2>\n
Wenn mehrere Nutzer sich (z.B. mit su<\/code>) als root anmelden d\u00fcrfen, ist schwer nachvollziehbar, wer etwas ver\u00e4ndert hat. Hier helfen die Audit-Logs von sudo: Sie protokollieren, welcher Nutzer wann einen Befehl als anderer Nutzer ausgef\u00fchrt hat. Auch blockierte Versuche werden erfasst. Bei regelm\u00e4\u00dfigen Auswertung  l\u00e4sst sich damit (versuchter) Missbrauch erkennen.<\/p>\n
sudo journalctl -f \/usr\/bin\/sudo\nMay 13 00:12:21 pi5 sudo[12957]:  student : TTY=pts\/3 ; PWD=\/home\/student ; USER=root ; COMMAND=\/usr\/bin\/systemctl restart ab apache2\n[...]\nMay 13 00:19:19 pi5 sudo[13018]:  student : command not allowed ; TTY=pts\/3 ; PWD=\/home\/student ; USER=root ; COMMAND=\/usr\/bin\/systemctl stop apache2<\/code><\/pre>\n
Was davon brauche ich tats\u00e4chlich?<\/h2>\n
So umfangreich und n\u00fctzlich die M\u00f6glichkeiten von sudo<\/code> auch sind – f\u00fcr den PC zuhause, einen Heimserver oder auch gemieteten (virtuellen) Server im Internet hat man in der Regel einen einzigen Administrator. Damit reicht ein kleiner Teil von sudo bereits aus. Vielleicht soll auf einem System noch jemand anders Zugriff haben, weil die Person an bestimmten Projekten mitarbeitet. Hier k\u00f6nnen weitere Teile sinnvoll sein – etwa dem Nutzer erlauben, einzelne Dienste neu zu starten.<\/p>\n
Raspberry Pi Beispiel: GPIO-Ports per Web steuern<\/h2>\n
Beim Lesen mancher Anleitung k\u00f6nnten Raspberry Pi Nutzer auf eine Idee kommen: GPIO-Ports werden oft als Root-Nutzer angesprochen, beispielsweise mit sudo. Wenn ich diese per Web steuern m\u00f6chte, muss mein Webserver (bzw. zumindest der PHP-Interpreter) als root laufen. Das ist eine sehr schlechte Idee, da eine Sicherheitsl\u00fccke in PHP oder meiner Anwendung mit vollen Rechten ausgenutzt werden k\u00f6nnte. Also beschr\u00e4nke ich den daf\u00fcr \u00fcblicherweise eingesetzten Nutzer www-data per sudo, damit er nur auf die GPIO-Pins zugreifen darf.<\/p>\n
Ein weiterer Einsatzzweck: Man m\u00f6chte \u00fcber die Web-Oberfl\u00e4che den Raspberry Pi herunterfahren. Hierf\u00fcr sind Root-Rechte auf \/usr\/sbin\/shutdown<\/code> n\u00f6tig.<\/p>\n
Quellen<\/h2>\n
# pete may change passwords for anyone but root on the hp snakes\npete            \nHPPA = \/usr\/bin\/passwd ^[a-zA-Z0-9_]+$, !\/usr\/bin\/passwd root<\/code><\/pre>\n
    \n
  1. https:\/\/manpages.debian.org\/bookworm\/manpages-de\/su.1.de.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
  2. https:\/\/wiki.ubuntuusers.de\/sudo\/Konfiguration\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
  3. https:\/\/www.sudo.ws\/posts\/2022\/03\/sudo-1.9.10-using-regular-expressions-in-the-sudoers-file\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
  4. https:\/\/gtfobins.github.io\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
  5. https:\/\/www.gnu.org\/software\/tar\/manual\/html_section\/checkpoints.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
  6. https:\/\/www.thehacker.recipes\/infra\/privilege-escalation\/unix\/sudo<\/a> \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    Viele Anleitungen enthalten Befehle mit vorangestelltem sudo. Sie blind zu \u00fcbernehmen, kann gef\u00e4hrlich werden. Im folgenden Beitrag erf\u00e4hrst du, was das ist, wie es funktioniert und wie das Werkzeug zur Verbesserung der Sicherheit genutzt werden kann. Dieser richtet sich an Raspberry Pi Nutzer gleicherma\u00dfen wie alle anderen, die GNU\/Linux auf PCs, Servern oder sonstigen Ger\u00e4ten …<\/p>\n","protected":false},"author":5,"featured_media":15474,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/manpages.debian.org\/bookworm\/manpages-de\/su.1.de.html<\/a>\",\"id\":\"b022e85b-3549-45e8-ae8e-25b226532bdd\"},{\"content\":\"https:\/\/wiki.ubuntuusers.de\/sudo\/Konfiguration\/<\/a>\",\"id\":\"6ecc1d64-8717-4318-8108-541218923a2f\"},{\"content\":\"https:\/\/www.sudo.ws\/posts\/2022\/03\/sudo-1.9.10-using-regular-expressions-in-the-sudoers-file\/<\/a>\",\"id\":\"03573d57-b89b-4270-86ef-b2cc9d5d2706\"},{\"content\":\"https:\/\/gtfobins.github.io\/<\/a>\",\"id\":\"6074a7b6-1c1a-4c45-9a83-f544d1209048\"},{\"content\":\"https:\/\/www.gnu.org\/software\/tar\/manual\/html_section\/checkpoints.html<\/a>\",\"id\":\"439cd0fd-7bae-49a8-a603-f51b9149a552\"},{\"content\":\"https:\/\/www.thehacker.recipes\/infra\/privilege-escalation\/unix\/sudo<\/a>\",\"id\":\"d0930c64-0f8f-4fe3-8060-97e4ca41a06a\"}]"},"categories":[74,391],"tags":[],"class_list":["post-13160","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-linux-server"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13160","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=13160"}],"version-history":[{"count":14,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13160\/revisions"}],"predecessor-version":[{"id":15460,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13160\/revisions\/15460"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/15474"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=13160"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=13160"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=13160"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}