mit Sudo normalen Linux-Nutzern das Ausführen von Root-Kommandos erlauben.
Inhaltsverzeichnis
Szenario 1: Normale Nutzer können bestimmte Befehle mit Root-Rechten ausführen.
Früher hatte man Einstellungen hierzu in der Datei /etc/sudoers erstellt. Diese Methode ist allerdings veraltet. Stattdessen sollte man das kommando visudo nutzen.
Die Syntax mit der der User dann ein kommando mit root-Rechten ausführen kann ist sehr einfach.
sudo <auszuführender befehl> <user der das kommando ausführen können soll> <dateiname>
Folgende Zeile erlaubt beispielsweise einem User „marc“ mit entsprechenden Rechten, das kommando chown auf eine datei auszuführen
sudo /sbin/chown marc <dateipfad>
Nun würde der user nach einem Passwort gefragt werden. Wenn keine explizite Einstellung getätigt wurde, wird der User nach dem Passwort des Nutzers „root“ gefragt. das ist aber nicht praxistauglich, weil ein Systemadministrator ja nicht will, dass die kleinen Admin-Gehilfen, die für das Zurücksetzen von Passwörtern und das Neustarten von Daemons zuständig sind, das Passwort des root-Nutzers kennen. Damit die user ihr eigenes Passwort eingeben müssen, müssen wir im visudo kommando erstmal folgendeseinkommentieren: die Zeile
ALL ALL=(ALL) ALL
und die Zeile
‚Defaults targetpw‘
Achtung: Wenn wir nur Letztere auskommentieren und nicht die ALL-Zeile, dann haben unsere kleinen Helferlein root-Zugriffe auf ALLE kommandos im System, indem sie einfach ihr eigenes Passwort eingeben! das wollen wir nun wirklich vermeiden ;).
Da ihr euch jetzt für eine Variante zur Passworteingabe eurer Helferlein entschieden habt, müsst ihr nun noch Berechtigungen setzen, welcher User welche Komamndos ausführen darf. Das geschieht im visudo-kommando in der Sektion „user privilege specification“. hier können wir Rechte auf User- und Gruppenebene setzen. So sieht es normalerweise aus
# User privilege specification root ALL=(ALL) ALL # Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL # Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now
hier eine erklärung der Syntax dieser user Privilegien:
<Username> <Hostname_des_clientrechners>=<effektiver User> <auszufürhendes kommando>
vorsicht, mit dieser Zeile erlauben wir einem User Billy, dass er von jedem Client-Rechner aus alle kommandos mit root-Rechten ausführt:
billy ALL=(ALL) ALL
Wenn wir jetzt beispielsweise wissen, dass Billy eigentlich nur von einem Terminal im Serverraum aus administrieren soll und dieses Terminal den Hostnamen terminal.dafrk-blog.com hat, dann können wir sagen
billy terminal.dafrk-blog.com=(ALL) ALL
Was macht jetzt der effektive user?= nun der effektive User ist der User, der unser User billy beim Ausführen von sudo wird, wenn er das kommando ausführt. Steht hier (ALL), dann bedeutet dass, dass der user billy die identität von JEDEM user auf dem System annehmen kann, wenn er das richitge Passwort (seines oder das des jeweils anderen users) kennt. Meistens, und das ist auch die standardeinstellung, wird man beim ausführen von sudo einfach nur root, wenn man das richitge Passwort eingibt. Wenn man sudo aber mit dem Parameter -u ausführt, kann man die identität des Users, die man annehmen will, expliti angeben. mit folgendem kommando könnte billy beispielsweise chown als user peter ausführne
sudo -u peter /sbin/chown <dateiname>
Die aktuelle einstellung in visudo würde das erlauben, weil billy die identität eines jeden users annehmen darf.
eine sinnvolle Varainte, diese Konfiguration zu nutzen, ist beispielsweise, wenn wir drei Admingehilfen haben, und unser User Billy soll mit dem kommando kill die Prozesse seiner beiden anderen ADmingehilfen Peter und Joerg abschießen können
billy termina.dafrk-blog.com=(peter,joerg) /bin/kill
Jetzt kann billy zwar kein user root mehr werden, dafür die Identität von peter und joerg annehmen und in ihrem namen kill ausführen, um prozesse zu beenden, die sich aufgehangen haben.
um nun beispielswiese dem User Billy zu erlauben, dass er das Kommando /bin/chown als root ausführt und dabei entweder das root- oder sein eigenes Kennwort (welches haben wir weiter oben eingestellt) eingeben muss, müssne wir folgendes schreiben:
# User privilege specification root ALL=(ALL) ALL Billy ALL=PASSWD: /bin/chown
Wenn wir wollen, dass Billy das kommando nur mit bestimmten Parametern ausführen kann, müssen wir diese umständlich folgendermaßen auflisten
# User privilege specificationroot ALL=(ALL) ALL
Billy ALL=PASSWD: /bin/chown -R,/bin/chown -V,/bin/chown -R-V
hier erlauben wir einmal chown -R, chown -V und einmal chown -R -V. Wichtig ist, dass ihr euch also bewusst macht, dass ihr mehrere Parameter gleichzeitig extra definieren müsst!
Wir können auch einstellen, dass der User einige kommandos ohne die eingabe eines Passwortes ausführen kann. Wir könne beispielswiese einstellen, dass der user das kommando chown mit dem PArameter -R ohne Passwort ausführen kann und für alles andere ein passwort braucht.
Joe ALL=NOPASSWD: /bin/chown -R,PASSWD: /bin/chown -V,/bin/chown -R-V
Szenario 2: Der Systemadministrator loggt sich mit seinem Benutzer ein und wird nachträglich root.
Der vorteil hierbei ist, dass keiner der beteiligten Systemadministratoren wirklich das root-Passwort kennen muss und sich alle mit ihren eigenen privaten Schlüsseln über Public Key Authentication am Server anmelden können. einen Artikel zu public Key auhtentication habe ich hier einmal geschrieben.
in diesem Fall bietet sich tatsächlich eine solche Einstellung ein
Billy ALL=(ALL) ALL
jetzt kann billy als jeder user jeden command ausführen. Egientlich würde normalerweise eine solche Zeile genügen
Billy ALL=(root) ALL
sodass Billy als root alles ausführen kann. Aber in bestimmten Systemen, beispielswiese beim Apache Webserver oder bei SAP-Landschaftslösungen, werden Standarduser im Betriebssystem erstellt, die wiederum Systemvariablen und Einstellungen in ihrem Bash-profil haben, die zum Ausführen bestimmter kommandos gebraucht werden. Das bedeutet: Der Standarduser, der bei der installation des Servers angelegt wurde, kann mit einem Kommando etwas anfangen, der User root, der normalerweise alles kann, aber nicht. Deswegen muss ein Systemadministrator auch die Identität von Usern wie beispielsweise apache annehmen können, weshalb wir lieber die Erstere Variante nehmen. Alternativ kann man aber die benötigten identitäten allesamt in die klmamern schreiben, also neben root auch beispeilsweise den user apache hinzufügen. Das wäre die ganz korrekte variante, wenn man alle identitäten weiß, die man hier braucht.
Es ist für einen Systemadministrator ziemlich anstrengend, jedes kommando wie ein Admingehilfe mit sudo auszuführen
sudo -u befehl
deswegen nimmt man in diesem Szenario, nachdem man sich als normaler Benutzer eingeloggt hat, den Befehl su zu Rate. Man nimmt mit dem Befehl su zuerst die Identität des gewünschten Users an und führt dann erst – ohne die Eingabe von sudo vorne dran – die ganzen kommandos aus. will unser user billy nach seinem Login beispielsweise die Identität des SAP-Systemadministrationsnutzers id2adm annehmen und dann das kommando startsap -R sapnj ausführen, sieht das so aus:
su - id2adm startsap -R sapnj
Wenn man die Identität des Users root annehmen will, gibt man einfach nur ein
su - startsap -R sapnj
man schreibt also hinter dem Bindestrich keinen expliziten Benutzernamen mehr.
Wir können mit einem weiteren Tweak erzwingen, dass der Benutzer, wenn er sich einloggt, nichts ausführen kann außer das kommando su – um die entsprechende identitä des root anzunehmen. Somit können wir beispielsweise verhindern, dass ein Angreifer, der sich in den Account eines Admins einloggt, aber das root-Kennwort nicht weiß und daher nicht über su root werden kann, anderen schabernack macht, beispielsweise mit shutdown- h das System herunterfährt. dazu ändern wir usnere Zeile ab zu
Billy ALL=(root) /bin/su,/bin/su - (mit leerzeichen am Ende)
jetzt kann der Benutzer nichts anderes machen, als mit su die Identität zu wechseln. Alles andere müssen wir als root machen.
In manchen Linux-Distributionen gibt es Standardeinstellungen für die Gruppen %admin und %sudo. Demnach können alle mitglieder Gruppe %sudo alle kommandos ohne Eingabe von sudo ausführen und alle Mitglieder von %admin dürfen alle Identitäten im System ausführen. Das soll die Administration etwas erleichtern, weil man dann User einfach nur noch einer Gruppe hinzufügen muss. wir brauchen sowas aber nicht mehr, weil wir uns jetzt ja auskennen. Deswegen würde ich die Einträge entweder löschen oder genau so formatieren wie die einträge von Billy im oberen Beispiel, da die Standard-Einträge theoretisch ein kleines sicherheitsrisko darstellen.
Advanced Level: Nutzen von Alias zum Sparen von Schreibarbeit
Aliase ermöglichen es, sich SChreibart zu sparen. Ein Beispiel. Wir definieren in visudo folgende Aliase:
User_Alias ADMINS=tom,billy,peter User_Alias SAPERS=jimmy,rolf Cmd_Alias SAP=/proc/startsap,/proc/stopsap Host_Alias TERMINALS=terminal1.dafrk-blog.com,terminal2.dafrk-blog.com
Dann können wir biepsielswiese festlegen, dass alle user die im Alias ADMINS drin an allen Terminals im Alias TERMINALS in der identität aller user alle kommandos ausführen dürfne.
ADMINS TERMINALS=(ALL) ALL
und die SAP-Administratoren im Alias SAPERS dürfen alle Kommandos im Alias SAP ausführen.
SAPERS ALL=(ALL) SAP
Bie einem User-Alias können auch Gruppen eingebaut werden
User_alias ADMINS=%admins
Cool sidn noch Negationen. die folgende Zeile definiert einen Alias, in dem alle User im Alis USERS sind, sofern sie nicht gleichzeitig im Alias NOADMINS sethen
User_Alias ADMINS=USERS,!NOADMINS
Sonderfall: Runas-Alias
Es gibt noch eine weitere form von Alias – den Runas-Alias. Der funktioniert genau so wie ein User_Alias, nur dass er die user anhand ihrer UID identifiziert. Es ist beispielswiese möglich einem Linuxsystem einer einzigen UID zwie verschiedene Benutzernamen zuzuweisen. Für so einen Fall wäre das nützlich. Die uids werden dabei mit einer vorangehenden Raute geschrieben. Das verwirrt Administratoren häufig, weil sie das als kommentar missinterpretieren. der folgende alias spricht den User mit der UID 0 an, das ist immer der root-User in einem Linux-System.
Runas_Alias ROOT=#0
Wichtiges Schlusswort
Ein wichtiges schlusswort zu dem Thema ist, dass Sie als verantwortlicher systemadminstrator erzwignen, dass alle User ein starkes Passwort für Ihre Usersaccounts verwenden – und dass das Passwort für den root-User ebenfalls diese Richtlinien erfüllt. Sie sollten heutzutage ein Passwot aus mindestens 20 Zeichen Stärke mit einer Mixtur aus Großbuchstaben, Kleinbuchstaben, Zahlen und Sonderzeichen haben. Wenn Sie das einfach so Ihren Administrationsgehilfen und Mitadministratoren mitteilen, werden sich wahrscheinlich 80% davon nicht an diese richtlinie halten. Asu diesem Grund müssen Sie diese richtlinie erzwingen, indem sie sie in der Datei pam_cracklib.so einstellen.
Als erstes müssen Sie pam-cracklib aktivieren. das geht in der Datei /etc/pam.d/common-password bzw. /etc/pam.d/system-auth. die typische Konfiguration würde dabei so aussehen
password required pam-cracklib.so retry=6 minlen=20 difok=3 password required pam_unix.so md5 use_authtok
dies aktiivert pam_cracklib und setzt mehrere moduleparamter. ein User hat demnach maximal sechsmal die cahnce, ein Passwort einzugeben, bevor passwd den Anmeldevorgang abbricht. der minlen-Parameter sagt, dass wir Passwörter mit mindestens 20 Zeichen länge fordern. der difok-parmater setzt die minimule Anzahl an Zeicehn die sich vom letzten Passwort unterscheiden müssen. Eine Einstellung von 3 würde bedeuten, dass es nicht einfach möglich ist, einfach nur immer eine einzige Zahl an ein Passwort anzuhängen – man müsste wenn dann schon in Hunderterschritten arbeiten.
Die zweite zeile aktiviert das pam_unix modul. Das Argumetn md5 aktiviert dabei stnadard Linux MD5 passwort-Hashes.
Nun wolelnw ir einstellen, dass von jeder Zeicehnart (großbuchstbaen, Kleinbuchstaben, Zahlen und sonderzeichen) mindestens eine bestimmte Anzahl von Zeichen enthalten sein müssen. Dazu fügen wir folgende Parmater in der pam_cracklibn-Zeiel der Datei 7etc/pam.d/common-password ein:
lcredit=1 ucredit=-1, dcredit=-2, ocredit=-2
diese Zeile sagt aus, dass der User immer mindestens 1 Großbuchstbaen, mindestens 2 Zaheln und mindestens zwei Sonderzeicehn in seinem Passwort haben muss. Die 1 hinter den Kleinbuchstaben sagt aus, dass ein Kleinbuchstabe jeweils einen Punkt gibt – der User muss 20 Punkte mit seinem Passwort machen, damit er auf die geforderten 20 Zeichen aus dem minlen-Parameter kommt.
Jetzt wollenw ir noch sicherstellen, dass User nicht wieder ein Passwort nehmen können, welches sie bereits in der Vergangenheit schon einmal genutzt haben. Umd as sicherzustellen, müssen wir erstmal die datei /etc/security/opasswd erstellen. Die Datei braucht ein chown von root:root und einen chmod von 600.
Jetzt müssen wir noch die Passwort-Historie aktivieren indem wir in der pam_unix Zeile unserer Konfiguration die Option iremember=<x>“ hinzufügen, wobei x die Anzahl der zu merkenden vergangenen Passwörter eines Benutzers entspricht.
Jetzt wollen Sie vielleicht noch einstellen, dass die Passwörter ihrer User „ablaufen“ können uns nach einer gewissen Zeitspanne geändert werdne müssen. das geht in der Datei /etc/login.defs über die einstellung PASS_MAX_DAYS.
sie können nun noch nach Benutzern suchen, die ein leeres Passwort eingegeben haben
awk -F: '($2 == "") {print}' /etc/shadow
Desweiteren sollten Sie nach user-accounts suchen, die eine UID von 0 haben – diese sollte nämlich normalerweise nur der User root haben
awk -F: '($3 == "0") {print}' /etc/passwd
Ich hoffe dies war für euch eine hilfreiche Einführung in das Thema Sudo und erleichtert euch später den Administrationsalltag.
Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.
Erklärungen, bei denen man wieder eine Erklärung suchen muss sind sooo mühsam und mit ein Grund warum sich Linux bei all seinem Potential einfach nicht verbreiten wird. Als ITler, der auch immer wieder ein wenig mit Linux befasst ist bin ich es leid ständig so viel Zeit investieren zu müssen. Der Blogger, Forenuser etc., der die Erklärung erstellt mag auch viel Zeit investiert haben, geht aber allzu oft vom eigenen vorhandenen Wissen aus. Konkret bin ich jedenfalls noch nie über ein „visudo kommando“ gestolpert und müsste mich bereits ganz am Anfang des Artikels wieder weiter hangeln… verliere dabei den Fokus und letztlich auch die Lust mich weiter damit zu befassen. Das ist wirklich sehr sehr schade!