14.4Prozesse unter einer anderen Identität ausführen (PolicyKit)
Die Grundidee des PolicyKits besteht darin, Programme in zwei Komponenten zu zerlegen: Der eine Teil enthält die Benutzeroberfläche und läuft mit gewöhnlichen Benutzerrechten. Der zweite Teil des Programms, der in der Nomenklatur des PolicyKits als mechanism bezeichnet wird, ist für Systemeingriffe zuständig und läuft mit root-Rechten. Diese Trennung hat den fundamentalen Vorteil, dass nicht mehr ein riesiges Programm mit root-Rechten laufen muss, sondern nur noch kleine Teile. Das reduziert mögliche Sicherheitsrisiken. Außerdem besteht theoretisch die Möglichkeit, dass verschiedene Benutzeroberflächen (z.B. ein Gnome- und ein KDE-Programm) auf ein einheitliches Set von Mechanismen zurückgreifen.
Die Kommunikation zwischen den beiden Komponenten erfolgt durch ein sogenanntes Bussystem, in der Regel über den »D-Bus«. Ob ein bestimmter Mechanismus ausgeführt werden darf oder nicht, entscheiden Funktionen der PolicyKit-Bibliothek, die auf eine zentrale Rechtedatenbank zurückgreifen. Für die Entscheidung werden drei Kriterien berücksichtigt:
-
Subjekt: Wer bzw. welcher Benutzer will Systemänderungen durchführen?
-
Objekt: Welches Objekt soll verändert werden (z.B. eine Datei, eine Partition oder eine Netzwerkverbindung)?
-
Aktion: Was soll gemacht werden (z.B. eine Partition in das Dateisystem einbinden)?
In vielen Fällen bemerkt der Benutzer gar nichts vom PolicyKit. Beispielsweise erlaubt die Standardkonfiguration bei den meisten aktuellen Distributionen dem Dateimanager, externe Datenträger in das Dateisystem einzubinden. Dazu ist keine weitere Authentifizierung erforderlich: Der Vorgang erfolgt automatisch, sobald der Datenträger angeschlossen wird.
Eine zweite Variante besteht darin, dass die PolicyKit-Regeln eine Autorisierung verlangen – beispielsweise zur Durchführung eines Updates mit dem PackageKit. In diesem Fall erscheint ein Authentifizierungsdialog. Bemerkenswert ist, dass sich das PolicyKit bei entsprechender Konfiguration die Authentifizierung merkt und in *.auths-Dateien in /var/lib/PolicyKit/ speichert. Wenn ein Benutzer sich also ein einziges Mal für einen bestimmten Vorgang authentifiziert hat, fragt PolicyKit in Zukunft nicht mehr nach.
Auf eine dritte Variante stoßen Sie bei diversen Gnome-Administrationswerkzeugen: Hier führt ein mit einem Vorhängeschloss gekennzeichneter Button zum Authentifizierungsdialog. Erst nach der Angabe des root- oder Benutzerpassworts können Systemveränderungen durchgeführt werden.
Die Konfiguration des PolicyKits erfolgt an folgenden drei Orten:
Bei der Grundkonfiguration gibt es distributionsspezifische Besonderheiten. Beispielsweise gibt /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf bei Ubuntu-Systemen allen Benutzern der admin- und sudo-Gruppen Administratorrechte. Unter Fedora gilt eine analoge Regel für wheel-Gruppenmitglieder.
Ein Bestandteil des PolicyKit-Pakets ist das Kommando pkexec. Es ist für die eigentliche Ausführung von Kommandos verantwortlich und wertet dabei die Policy-Konfiguration aus.
Für im Terminal auszuführende Kommandos funktioniert pkexec ohne weitere Konfiguration. Freilich wäre es noch einfacher, in diesem Fall su oder sudo zu verwenden.
Bei grafischen Programmen scheitert der Aufruf aber mit der Fehlermeldung cannot open display:
Abhilfe schafft hier nur das Einrichten einer weiteren PolicyKit-Konfigurations-datei /usr/share/polkit-1/actions/org.freedesktop.policykit.pkexec.policy. Die Datei gilt also für das Kommando pkexec. In dieser Datei muss für jedes Programm, dass pkexec ausführen darf, ein <action>-Block nach dem folgenden Muster eingerichtet werden: