Sudo ist ein mächtiger Befehl, der Administratoren in die Lage versetzt, aufwändige Systemadministrations-Infrastrukturen mit verfeinerten Berechtigungen und Kontrollmechanismen aufzubauen. so lässt sich unter anderem fein granuliert festlegen, wer welche Befehle damit ausführen darf. So kann man einem User oder einer Gruppe erlauben, das System zu aktualisieren, ihm aber verwehren, Konfigurationsdateien in /etc zu editieren und vieles mehr.
Sudo überdimensioniert
Für Desktop-Einzelplatzsysteme ist Sudo in den allermeisten Fällen völlig überdimensioniert, denn dort geht es meist nur um zeitweise Root-Rechte für die Systemadministration. Dabei kann der unbedarfte Anwender bei falschen Einträgen in der umfangreichen Sudoers-Konfigurationsdatei leicht die Sicherheit des Systems unbemerkt schwächen. Mit der zunehmenden Verbreitung von Ubuntu ab 2005 kam Sudo auf Desktop-Systemen immer mehr in Mode und setzte sich mit der Zeit durch. Viele Distributionen, die früher einen echten Root verwendeten, liefern heute Sudo standardmäßig aus.
Mehr Übersicht
Bei OpenBSD wurde vor rund 5 Jahren doas als einfacher Ersatz für Sudo entwickelt und wird mittlerweile bei einigen BSD-Distributionen als Standard eingesetzt. Im Vergleich zu den rund 3,4 MByte, die Sudo belegt, ist doas mit 40 KByte um einiges kleiner. Ist die Konfigurationsdatei bei Sudo ziemlich überladen und für Neueinsteiger unübersichtlich, so reicht bei doas für die allermeisten Fälle eine Zeile, auch bei Mehrbenutzersystemen. Mit doas lassen sich bei Bedarf aber auch komplexer gegliederte Berechtigungssysteme erstellen. Der Code von doas wird auf Github gepflegt und ist schnell mit make und make install oder checkinstall gebaut.
Anschließend wird (falls die Distribution keine bietet) als Root eine Konfigurationsdatei mit nano /etc/doas.conf (oder dem Editor eurer Wahl) erstellt und anschließend im einfachsten Fall mit der Zeile permit [user] as root versehen, wobei [user] durch den zu berechtigenden User ersetzt wird. Damit lassen sich Befehle einfach als Root ausführen, indem man dem Befehl doas voranstellt anstelle von sudo.
Mit oder ohne Passwort
Wird doas kurz darauf wieder verwendet, wird das Passwort erneut abgefragt und nicht wie bei Sudo für eine Weile gespeichert. Soll das Passwort gar nicht abgefragt werden, so lautet die Zeile permit nopass [user] as root. Auf Mehrbenutzersystemen werden Mitglieder der Gruppe wheel mit der Zeile permit :wheel autorisiert. Weitere Optionen sind der Manpage zu entnehmen.
Ich finde dieses Theater rund um sudo nur noch lächerlich. Es war weder jemals notwendig, noch doas als Alternative dazu. Der traditionelle Weg mittels su war stets in Ordnung, und letztlich können auch mittels su bei Bedarf einzelne Kommandozeilen als Root abgesetzt werden. Dazu ist su ebenfalls sehr klein. Wo ist also das Problem? Ist der direkte Login als Root nicht mehr cool genug, dass man hier stets das Rad neu erfinden muss? Ich bin absolut kein Fan davon, auf dieser Ebene partielle Privilegien an verschiedene Nutzer zu delegieren, anstatt das professionell auf Basis von MAC samt MLS zutun. Darüber hinaus kann zur Administration auch mit Key-Escrow gearbeitet werden, indem zufällig generierte Root-Passwörter genutzt werden, die bspw. einmalig oder periodisch in mehrere Segmente unterteilt, und je nach Administrator via E-Mail etc. zugestellt werden. Es sind also stets mehrere Administratoren zum Login erforderlich, womit auch sichergestellt wird das hier im Anschluss keine dubiosen Eingaben getätigt werden. Funktioniert bei uns in der Firma recht gut.
Na, müssen wir wieder um Linuxprobleme herumfrickeln? Da doch lieber direkt OpenBSD installieren…
Je nach Distribution findet man die Config auch unter /etc/doas.conf.
Moechte man das Verhalten von sudo haben, dass das Passwort fuer einige Zeit gemerkt wird, dann muss man in der Config das Keyword persist einfuegen.
Beispiel:
Ich meine gelesen zu haben, dass persist nur bei BSD funktioniert. Ich kann es aber mal testen. Eine Config gibt es bei Debian nicht, die muss man selbst anlegen.
Unter Void Linux funktioniert das persist Keyword. Moeglicherweise ist das aber abhaengig von der verwendeten Version.
Ich hab es eben bei Debian Unstable (siduction) getestet. persist hat hier keine Wirkung. Leider verhindert doas dort auch die auto completion im Terminal. Da muss ich mal reinschauen, woran das liegt.
EDIT: Unten auf “Weiterlesen” klicken, damit der Code richtig formatiert angezeigt wird!
Unter Void Linux habe ich eine Datei mit folgendem Inhalt angelegt, damit auto completion in der bash funktioniert:
# bash completion for doas(8) -*- shell-script -*- _doas() { local cur prev words cword split _init_completion -s || return local i mode=normal [[ $mode == normal ]] && for ((i = 1; i <= cword; i++)); do if [[ ${words[i]} != -* ]]; then local PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin local root_command=${words[i]} _command_offset $i return fi if [[ ${words[i]} == -@(!(-*)e*|-edit) ]]; then mode=edit break fi [[ ${words[i]} == \ -@(user|other-user|group|close-from|prompt|!(-*)[uUgCp]) ]] && ((i++)) done case "$prev" in --user | --other-user | -!(-*)[uU]) COMPREPLY=($(compgen -u -- "$cur")) return ;; --group | -!(-*)g) COMPREPLY=($(compgen -g -- "$cur")) return ;; --close-from | --prompt | -!(-*)[Cp]) return ;; esac $split && return if [[ $cur == -* ]]; then local opts=$(_parse_help "$1") COMPREPLY=($(compgen -W '${opts:-$(_parse_usage "$1")}' -- "$cur")) [[ ${COMPREPLY-} == *= ]] && compopt -o nospace return fi if [[ $mode == edit ]]; then _filedir fi } && complete -F _doas doas # ex: filetype=shDanke dafür, ich muss mir diesbezüglich erst mal die
bash_completionbei Debian anschauen.> Für Desktop-Einzelplatzsysteme ist Sudo in den allermeisten Fällen völlig überdimensioniert
Auch dort muss ich typischerweise nur eine einzige Zeile einfügen …
> wird das Passwort erneut abgefragt
… um genau das zu erreichen. Die restlichen Defaults passen für mich (Debian):
Defaults timestamp_timeout=0Dennoch gut, eine leichtgewichtige Alternative zu haben (zumal von OpenBSD).
Ich kann mich noch gut an meinen ersten Besuch in Visudo erinnern. Das ist noch nicht allzu lange her, denn ich habe bis vor Kurzem am echten Root festgehalten. Das war schon recht verwirrend am Anfang. Leider kommt man heute stellenweise nicht mehr ohne Sudo aus. Ich hatte mehrfach Situationen, die mit Root nicht zu lösen waren und die auf Sudo beharrten. Mal schaun, wie das mit Doas klappt. Das läuft seit einigen Wochen auf einem Notebook, bisher funktioniert es gut als Dropin Replacement für Sudo.
Die Schwestern der Boas, pff.
Ich würde doas wie jeden anderen Shell-Befehl auch im normalen Text klein schreiben.
So ein paar Zusatzinfos wären nicht schlecht. Bspw. liegt doas nicht in den Debian-, Ubuntu-, Fedora-Repositories, auch nicht in Ubuntu-PPAs, wohl aber als opendoas in den Arch-Repositories. Upstream-URL linkt auf einen Fork eines anderen seit Jahren nicht mehr angefaßten github-Repos. Beim Fork passiert seit 9 Monaten aber auch nichts mehr. Das muß die eine sagenumwobene Software sein, die absolut fehlerlos und nicht verbesserbar ist.
Wie auch immer, ich hab’s eben mal spaßeshalber (verwenden werde ich’s nicht) aus dem git in einer noch herumliegenden LBionic-VM kompiliert, aber im letzten Schritt des bekannten “Dreisatzes” Ubuntu-typisch mit checkinstall statt “make install”. So erhält man ein .deb-File.
Entsprechendes “/etc/doas.conf” dazu – funktioniert.
Mea culpa, mir ist im Artikel offensichtlich ein Absatz abhandengekommen, in dem ich auf das Repository Bezug nehme, mit dessen Code ich doas gebaut habe. Das von mir verlinkte Repo ist tatsächlich in aktiver Entwicklung. Ich habe den Artikel eben nochmals um die fehlenden Informationen ergänzt. Auf axebase.net ist eine Installationsanleitung zu finden, die sich auf ein anderes Repository bezieht.
Als Paranoiker habe ich damit angefangen, in der sudo-config
zu setzen.
D.h. wenn sudo zur Passworteingabe auffordert, wird nicht nach dem eigenen, sondern nach dem root-Passwort (bzw. nach dem des angeforderten Users) gefragt.