Doas ist eine Alternative zu dem für den Desktop-Anwender oft völlig überfrachteten Platzhirschen Sudo, wenn es darum geht, Befehle mit den Rechten eines anderen Users auszuführen.

Bei Unix und Linux gilt seit jeher die strikte Trennung bei der Vergabe der Rechte zwischen alltäglichen und administrativen Aufgaben. Letztere waren ursprünglich dem Superuser-Account vorbehalten. Sind Sie als Superuser, meist root genannt, eingeloggt, dürfen Sie alles bis hin zum Löschen des gesamten Systems mittels des Befehls rm -rf /.

Sudo seit 1980

Um zu verhindern, dass Studenten der Universität New York nicht benötigte Rechte erhalten, haben Admins bereits um 1980 das Tool Sudo entwickelt. Der Name steht für “Superuser Do”. Es erlaubt, einem Anwender, der Mitglied der Gruppe sudo ist, für begrenzte Zeit oder bestimmte Tools Root-Rechte zu verleihen. Dazu stellen Sie einem Befehl, dessen Ausführung diese Rechte benötigt, sudo voran. Anschließend geben Sie zum Autorisieren Ihr User-Passwort ein.

Sudo kam mit der zunehmenden Verbreitung von Ubuntu ab 2005 immer mehr in Mode und gehört heute bei den meisten Distributionen zum Standard. Das Werkzeug ermöglicht einem Admin, einzelnen Usern auf einer Maschine bestimmte Rechte zu erlauben und andere zu verweigern. Listing 1 zeigt einen Standardeintrag für die Konfigurationsdatei /etc/sudoers.

root ALL=(ALL:ALL) ALL

Dass bedeutet vereinfacht: Der User darf alle Befehle, die Root voraussetzen, mit Sudo ausführen. Um zu verstehen, was die vier Vorkommen von ALL bedeuten, ist es nötig, tief in die Dokumentation einzusteigen. Die Rechtevergabe bei Sudo lässt sich darüber hinaus unter anderem als rollenbasierte Zugriffskontrolle [1] sowie über Mandatory Access Control [2] regeln oder per LDAP und den Verzeichnisdienst Network Information Service (NIS) konfigurieren.

Daraus und aus weiteren fortgeschrittenen, mit Sudo realisierbaren Strategien für die Zugriffskontrolle resultiert eine sehr komplexe Konfigurationsdatei, die Einsteiger schnell überfordert und verleitet unter Umständen zu Fehlern, die Auswirkungen auf das System haben. Die Gesamtgröße der Anwendung liegt mittlerweile bei 412 000 Codezeilen.

Zu mächtig für zu Hause

Was auf einem Enterprise-Server mit vielen Usern durchaus sinnvoll wäre, erscheint uns auf heimischen Desktop-Systemen recht deplatziert. Wenn Sie also zu den Anwendern zählen, die Sudo auf Ihrem System lediglich nutzen, um zeitweise Root-Rechte für die Systemadministration zu erlangen, dann ist Sudo für Ihren Bedarf stark überfrachtet.

Aufgrund seiner mächtigen Funktionen ist das Programm zudem geradezu ein Hacker-Magnet. In der Vergangenheit wurden in Sudo des Öfteren sicherheitskritische Bugs aufgedeckt, zuletzt im Januar 2021 [3]. Diese Fehler blieben aufgrund der Komplexität des Codes bis zu zehn Jahren unentdeckt.

Da die überwiegende Mehrheit der Anwender nur einen minimalen Bruchteil der mächtigen Optionen von Sudo nutzt, bietet es sich an, eine Alternative zu verwenden. Bereits auf Ihrem System vorhanden ist der echte Root-Account, den Sie mit su - aufrufen. Hier müssen Sie allerdings Sorge tragen, dass Sie sich mit exit wieder ausloggen, wenn Sie die Root-Rechte nicht mehr benötigen. Gerade auf Mehrbenutzer-Systemen verbietet es sich aus Sicherheitsgründen, einen Root-Account offen zu lassen.

Tu es als?

Eine weitere Alternative ist das kleine Tool Doas. Es weist mit 4000 Zeilen lediglich ein Prozent der Zeilenzahl von Sudo auf und bietet damit bei auf Desktop-Systeme zugeschnittener reduzierter Funktionalität einen wesentlich kleineren Angriffsvektor.

Dass die Konfigurationsdatei im einfachsten Fall selbst bei Systemen mit mehren Benutzern mit einer einzigen in Umgangssprache verfassten Zeile pro User auskommt, ist ein weiteres Plus, das vor Fehlbedienung schützt. Mit Doas erstellen Sie bei Bedarf aber auch komplexer ausgelegte Berechtigungssysteme.

Aber zunächst zurück auf Anfang: Die Entwicklung von Doas begann vor rund sechs Jahren bei OpenBSD, als Ted Unangst antrat, 95 Prozent der Funktionalität von Sudo mit einer wesentlich kleineren Codebasis zu realisieren.

Mittlerweile ist das Tool bei einigen BSD-Distributionen Standard und in vielen Linux-Distributionen unter dem Paketnamen opendoas über die Repositories zu installieren [4]. Bei Linux kommt fast ausschließlich der Fork OpenDoas zum Einsatz, während bei den BSDs der Port Doas vorherrscht, der ebenfalls auf Linux, zusätzlich aber auf MacOS läuft [5].

In den Archiven

Das aktiv entwickelte OpenDoas liegt derzeit in Version 6.8.1 vor. Sollte Ihre Distribution das Paket als eine ältere Version oder gar nicht anbieten, wie etwa bei Debian 10, ist es möglich, es mittels Linux-Dreisatz selbst zu bauen. Dann müssen Sie sich aber zum Absichern um die Konfiguration von PAM kümmern [6].

Als Vorlage bietet sich hier die Datei /etc/pam.d/sudo an. Der Code von OpenDoas wird auf Github gepflegt [7]. Listing 2 zeigt, wie Sie OpenDoas aus den Quellen bauen. Schlägt dabei das letzte Kommando fehl, prüfen Sie ob Pfad und Dateiname passen.

# Vorbereitung:
sudo apt install build-essential checkinstall git byacc
# Bereitstellen
git clone git://github.com/Duncaen/OpenDoas --depth 1
cd OpenDoas
# Bauen
./configure --with-timestamp --mandir=/usr/share/man
make
checkinstall  -D --install=no --maintainer=user --pkgname=opendoas
# Installieren
sudo apt install /home/$USER/OpenDoas/opendoas_*.deb

Haben Sie OpenDoas auf dem System installiert, testen Sie es am besten, indem Sie einem entsprechenden Befehl einfach doas anstatt sudo voranstellen. Falls Sie eine Fehlermeldung erhalten, liegt dies vermutlich an Ihrer Distribution, denn einige Maintainer liefern OpenDoas ohne Konfigurationsdatei aus.

Diese ist aber samt dem notwendigen Eintrag für den aktuellen User schnell und mit nur einem Befehl erstellt (Listing 3, Zeile 2) (Abbildung 1). Bei Mehrbenutzersystemen würden Sie etwa alle Mitglieder der Gruppe admin (bei Ubuntu: wheel) mit dem Kommando aus Listing 3, Zeile 4 autorisieren.

#  Eigenen Benutzeraccount eintragen
echo "permit :$USER" | sudo tee /etc/doas.conf
# Gruppe admin als erlaubte Gruppe definieren
echo "permit :admin" | sudo tee /etc/doas.conf
# Befehl für aktuellen Benutzer verbieten
echo "deny :$USER apt update && apt dist-upgrade" | sudo tee /etc/doas.conf
# einsatz ohne Passwort für aktuellen Benutzer
echo "permit nopass :$USER" | sudo tee /etc/doas.conf
# Umgebungsvariablen erhalten
echo "permit keepenv :$USER" | sudo tee /etc/doas.conf

Abbildung 1: Meist reicht eine einzige Zeile in der Konfiguration, wenn es nur einen User auf dem System gibt.

Wollen Sie den Einsatz für einen anderen Nutzer konfigurieren, fügen Sie diesen entweder einer Gruppe hinzu oder ersetzen Sie bei den Befehlen in Listing 3 $USER durch den entsprechenden Account-Namen.

Das Gegenteil erreichen Sie mit dem Schlüsselwort deny in /etc/doas.conf. Damit verwehren Sie Usern bestimmte Rechte (Listing 3, Zeile 6). Auf Einzelplatzsystemen bietet es sich unter Umständen an, die Software gänzlich ohne Passwort zu verwenden (Listing 3, Zeile 8).

Meist ist es nicht ratsam, GUI-Anwendungen als root zu starten, aber Apps wie Gparted oder Krusader-Root brauchen schon beim Start diese Rechte. Um dieses grafischen Anwendungen mit Doas zu erlauben, kommt der Parameter keepenv ins Spiel (Listing 3, Zeile 10) (Abbildung 2)

Abbildung 2: Um mit Doas grafischen Anwendungen Root-Rechte zu verleihen, muss in der Konfiguration der Parameter keepenv stehen.

Ohne Passwort

Die Nutzung ohne Passwort ergibt Sinn, denn OpenDoas merkt sich im Gegensatz zu Sudo das Passwort nicht. Während es bei Sudo für 15 Minuten gespeichert wird, müssen Sie sich mit Doas theoretisch bei jedem Befehl erneut legitimieren.

Wollen Sie die von Sudo für 15 Minuten anhaltende Persistenz bei OpenDoas unter Debian und Derivaten haben, müssen Sie die Anwendung mit der Option --with-timestamp selbst kompilieren. Für Ubuntu ist das in jedem Fall nötig, hier ist Doas noch nicht in den Archiven (Abbildung 3).

Abbildung 3: Die Option persist steht nur bereit, wenn Sie Doas selbst aus den Quellen bauen. Dazu geben Sie dem Befehl ./configure den Parameter --with-timestamp mit.

Workaround

Ein weiterer Unterschied zwischen Doas und Sudo ist die bei den meisten Distributionen noch fehlende Auto-Komplettierung. Das führt dazu, dass die Shell etwa bei einem Debian-System Befehle nicht per Tabulator-Taste komplettiert, wenn Sie doas voranstellen. Das ist ärgerlich, wenn Sie daran gewöhnt sind. Ein Bug-Report des Autors ist noch nicht bearbeitet. Einen Workaround finden Sie im Kasten “Bash-Completion” (Abbildung 4).

Abbildung 4: Die Pfad-Variable schreiben Sie in die zweite Zeile der zuvor als Workaround erstellten Completion-Datei. Wenn Sie dann noch die Vorkommen von sudo mit doas ersetzen, funktioniert nach einem Neustart auch die Bash-Completion.

PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin

sudo touch /usr/share/bash-completion/completions/doas

Die bisher beschriebenen Optionen reichen für die meisten Bedürfnisse eines Desktop-Users aus. Dem Problem des Muskelgedächtnisses, das dazu führt, dass Sie automatisch sudo anstatt doas tippen, begegnen Sie mit einem Alias in der Datei .bashrc, indem Sie dort die Zeile alias sudo="doas" einfügen.

Man-Pages gibt es sowohl für den Befehl doas als auch für die Datei doas.conf. Letztere enthält Beispiele für fortgeschrittene Konfigurationen. Weiterführende Konzepte hat der Entwickler in seinem Blog veröffentlicht [8].

Fazit

Doas ist in Linux zu Unrecht so wenig bekannt. Es bietet eine schlanke Alternative zum überfrachteten Sudo und die umgangssprachliche Konfiguration stellt Anfänger vor kaum ein Problem. Lediglich die standardmäßig noch fehlende Bash-Completion und der Zwang, das Passwort bei jedem Befehl neu einzugeben, trüben das gute Bild etwas. Beide Probleme umschiffen Sie jedoch recht einfach.

Doas ist beim Autor seit rund einem Jahr im Einsatz, ohne dass es Anlass zur Kritik gibt. Besonders gefällt die simple Konfiguration und der Einsatz ohne Passwort auf Einzelplatzsystemen, die einen Arbeitsschritt überflüssig macht. (agr)