Eine der Stärken von Linux liegt in allgemeinem daran, dass das System seit Urzeiten als Mehrbenutzersystem konzipiert ist. User starten Anwendungen im Rahmen ihrer Benutzerrechte, sodass diese in der Regel nichts am System ändern können. Malware beeinträchtigt somit höchstens den Datenbestand des Users, der diese ausführt. Dennoch machen wir Linuxer immer wieder gerne ein Türchen auf: Sobald wir beispielsweise einen Editor mit Root-Rechten starten, etwa um eine Konfigurationsdatei zu bearbeiten, führen wir diesen mitsamt dem kompletten Toolkit (also GTK oder Qt) mit administrativen Rechten aus. Dadurch läuft mehr Code mit administrativen Rechten, als eigentlich nötig, daran ändert auch der Aufruf des Programms mit gksu oder gksudo nichts.
Sudoedit, das bessere sudo $editor
Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.
$ sudo -e /etc/hosts $ sudoedit /etc/hosts
Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.
$ VISUAL=gedit sudoedit /etc/hosts $ EDITOR=nano sudoedit /etc/hosts
Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.
### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise ### über die ~/.bashrc oder $ grep EDITOR ~/.bashrc export EDITOR=/usr/bin/joe $ grep VISUAL ~/.xprofile export VISUAL=/usr/bin/gedit ### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder ### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor ### Joe oder Gedit. $ sudoedit /etc/hosts
Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.
Root-Rechte für Files aka Nautilus
Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.
In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.
In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.
Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.
Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.
Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.