PolicyKit 0.105
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Achtung!
Dieser Artikel gilt nur für Ubuntu vor 24.04!
Ab Noble Numbat verwendet Ubuntu für Policykit eine spätere Version als 0.105
(konkret 124
) und damit sind nun die Regeln nicht mehr wie hier beschrieben, sondern als Funktionen in JavaScript zu formulieren.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
PolicyKit 🇬🇧 (aktueller offizieller Name polkit) ist ein im Hintergrund laufender Dienst, der es erlaubt, Berechtigung für die Nutzung von Systemkomponenten und Software selektiv festzulegen.
So kann man z.B. festlegen, dass beim Aufruf eines Programms nach dem Passwort eines Nutzer mit Root-Rechten[4] gefragt wird, auch wenn das Programm nicht mittels sudo
oder pkexec
gestartet wurde. Dies ist beispielsweise in Werkzeuge der Systemverwaltung von GNOME integriert und daran zu erkennen, dass bei vielen Anwendungen nicht mehr das Root-Passwort beim Start der Anwendung abgefragt wird, sondern dass die Anwendung durch einen Klick auf freigeschaltet wird oder ein Dialog zur Eingabe eines Passworts erscheint.
Mittels PolicyKit lassen sich Rechte fein verteilen. So kann man Benutzer bestimmen, denen bestimmte Aktionen erlaubt werden, für die normalerweise Root-Rechte[4] notwendig wären, ohne sie zu Administratoren[5] zu machen. Hintergründe und Details zur Implementierung von PolicyKit bietet die Dokumentation.
Sicherheit¶
Mit PolicyKit lassen sich zwar für ausgewählte Benutzer zusätzliche Rechte gezielt erteilen und damit die Benutzung des Systems komfortabler gestalten, allerdings erzeugt das falsche oder zu großzügige Setzen von Rechten erhebliche Sicherheitsrisiken, da manche Benutzer unter Umständen zu weitreichende Rechte im System haben!
Achtung!
Das System polkit ist extrem leicht auszuhebeln. Dazu muss lediglich ein Angreifer mit erweiterten Rechten eine Datei mit passendem Inhalt für eine Aktion oder für eine Regel im lokalen Dateisystem ablegen. Dies kann beispielsweise durch ein kompromittiertes Softwarepaket bei einem normalen Update erfolgen.
Es kann auch unbeabsichtigt geschehen, wenn der lokale Systemverwalter mit fehlenden Kenntnissen gepaart mit Ungeschick Inhalte oder Dateirechte von Aktionen, Regeln oder der diese enthaltenden Ordner ändert.
Unbedingt erforderlich bei allen Eingriffen in das System ist daher die Beachtung dieser grundsätzlichen Eigenschaften:
Alle zur Konfiguration des Systems polkit relevanten Ordner und Dateien müssen als Besitzer und Arbeitsgruppe
root
oderpolkitd
haben.Nur
root
darf in diesen Ordnern Dateien anlegen oder entfernen, dh. Dateirechte der Ordner dürfen maximal755
oder verschärfend555
bzw.550
lauten.Nur
root
darf in diesen Ordnern Dateien ändern, dh. Dateirechte für Dateien in den Ordnern dürfen maximal644
oder verschärfend640
bzw.440
lauten.
Installation¶
PolicyKit ist in der Standardinstallation von Ubuntu und einigen offiziellen Derivaten bereits standardmäßig installiert[1]:
policykit-1 ("framework for managing administrative policies and privileges" für 20.04 bzw. "transitional package for polkitd and pkexec" für 22.04 aus main)
Befehl zum Installieren der Pakete:
sudo apt-get install policykit-1
Hinweis:
Zusätzlich benötigt man noch einen Dialog für die Passwortabfrage (den Authentifizierungsagenten). PolicyKit selbst enthält einen solchen für die Kommandozeile[2] und manche Desktops wie Gnome haben davon eine grafische Version eingebaut. Bei anderen ist dafür, je nach Desktopumgebung, eines der folgenden Pakete erforderlich. Je nach Derivat ist das Paket standardmäßig bereits installiert.
Ubuntu, Xubuntu, Ubuntu Budgie, Kylin:
policykit-1-gnome („Authentifizierungsagent für PolicyKit“ aus universe)
Befehl zum Installieren der Pakete:
sudo apt-get install policykit-1-gnome
Lubuntu:
lxpolkit („LXDE-Authentifizierungsagent für PolicyKit“ aus universe)
Befehl zum Installieren der Pakete:
sudo apt-get install lxpolkit
LXQt:
lxqt-policykit („LXQt-Authentifizierungsagent für PolicyKit“ aus universe)
Befehl zum Installieren der Pakete:
sudo apt-get install lxqt-policykit
Ubuntu Mate:
mate-polkit („MATE-Authentifizierungsagent für PolicyKit-1“ aus universe)
Befehl zum Installieren der Pakete:
sudo apt-get install mate-polkit
Kubuntu:
polkit-kde-agent-1 („KDE-Dialoge für PolicyKit“ aus universe)
Befehl zum Installieren der Pakete:
sudo apt-get install polkit-kde-agent-1
Benutzung¶
⚓︎ Mit dem automatisch gestarteten und im Hintergrund laufenden Dienst polkitd kommt man normalerweise nur in Berührung, wenn man, wie in der Einleitung beschrieben, für eine bestimmte Aktion oder ein bestimmtes Programm erweiterte Rechte benötigt und dafür über den Dialog des Authentifizierungsagenten ein Passwort erfragt wird.
⚓︎
PolicyKit kennt Aktionen (englisch actions), für die definiert ist, welche Art von Authentifizierung (keine, als Benutzer, als Administrator) für ihre Ausführung erforderlich ist. Beschreibungen dieser Aktionen sind in XML-Dateien (Dateiname beliebig, aber Suffix .policy
erforderlich) im Verzeichnis
/usr/share/polkit-1/actions
hinterlegt. Hier sind sowohl Beschreibungen von Aktionen zu finden, welche Ubuntu standardmäßig mit bringt und eigene Aktionen müssen auch hier abgelegt werden, da es in der Version 0.105 von polkit noch keine weiteren Ordner dafür gibt.
⚓︎ PolicyKit kennt weiterhin Regeln, mit denen zusätzliche Rechte für Benutzer und Gruppen gesetzt - oder weggenommen - werden können.
Alle Versionen von Ubuntu vor Noble Numbat (24.04) verwenden für Regeln die "local authority"; dh. die Regeln müssen in INI-Dateien in einem Unterordner (z.B. 50-local.d/) in einem der folgenden Verzeichnisse
/etc/polkit-1/localauthority/
/var/lib/polkit-1/localauthority/
abgelegt werden. Der Dateiname kann im Prinzip beliebig gewählt werden, muss aber auf .pkla
enden. Die Dateien werden in Wörterbuchreihenfolge abgearbeitet, d.h. später abgearbeitete Dateien können Ergebnisse von vorher abgearbeiteten überschreiben. Damit man die Reihenfolge selber steuern kann, sollen die Namen der Ordner und der Dateien mit einer zweistelligen Zahl, ggf. mit führender 0
beginnen.
Neuere Versionen von PolicyKit (bei Ubuntu ab Noble Numbat)[6] ignorieren die vorstehend beschriebenen Dateien und erkennen nur in der Programmiersprache Javascript formulierte Regeln in anderen Verzeichnissen. Auch die Abarbeitung der Regeln erfolgt in neueren Versionen anders als hier für die alte Version 0.105 beschrieben.
PolicyKit bringt drei Kommandozeilenprogramme mit:
pkexec führt ein Programm mit den Rechten eines anderen Benutzers oder auch als root aus.
pkaction zeigt Aktionen gut lesbar an.
pkcheck prüft, ob ein Prozess für eine bestimmte Aktion autorisiert werden kann bzw. bereits ist..
Alle oben genannten Programme arbeiten nicht interaktiv, sondern ausschließlich mit Optionen. → Dokumentation
pkexec¶
Dieser Befehl erfüllt grundsätzlich die gleiche Aufgabe wie sudo, d.h. ein Programm wird mit Rechten eines anderen Nutzers - inklusive Root-Rechten[4] - ausgeführt, jedoch werden die Regeln und Aktionen beachtet, und somit ist ist eine Rechtesteuerung selektiver bzw. feingranularer als mit sudo
möglich.
Die allgemeine Syntax lautet[2]:
pkexec [OPTIONen] PROGRAMMNAME
Wird keine Option angegeben, wird PROGRAMMNAME
als root ausgeführt. Dazu muss man aus Sicht vom PolicyKit keine (!) Root-Rechte auf dem System haben, man wird allerdings entsprechend den Regeln nach einem Passwort gefragt, und zwar standardmäßig nach dem Passwort des ersten Benutzers in der Gruppe sudo
.
Mit der OPTION -u
kann man PROGRAMMNAME
aber auch mit den Rechten eines anderen Benutzers ausführen. So würde z.B.
pkexec -u otto PROGRAMMNAME
PROGRAMMNAME
als Nutzer otto
ausführen.
Eine Root-Shell[4] erhält man z.B. mit dem Befehl
pkexec bash -l
Weitere Details lese auch im Artikel PolicyKit/pkexec zu neueren, aber in der Bedienung weitgehend kompatiblen Versionen.
pkaction¶
Hiermit können hinterlegte Aktionen gut lesbar angezeigt werden.
Der Aufruf
pkaction
listet einfach die Namen aller Aktionen. Fügt man die Option --verbose
hinzu, erhält man detailliertere Informationen zu jeder Aktion.
Der Befehl
pkaction --action-id com.ubuntu.pkexec.gedit --verbose
zeigt nur Informationen für die Aktion mit der ID com.ubuntu.pkexec.gedit
.
Weitere Details lese auch im Artikel PolicyKit/pkaction zu neueren, in der Bedienung kompatiblen Versionen.
pkcheck¶
Siehe Artikel PolicyKit/pkcheck zu neueren, aber in der Bedienung kompatiblen Versionen.
Regeln bearbeiten¶
Über Regeln können zusätzliche Rechte für Nutzer und Gruppen für verschiedene Aktionen vergeben werde.
Dazu arbeitet man im Terminal[2] mit Root-Rechten[4] und legt ggf. eine neue Datei an:
sudo touch /etc/polkit-1/localauthority/50-local.d/99-gparted-otto.pkla
Diese Datei bearbeitet man mit einem Editor[3]; der folgende Inhalt würde z.B. dem Nutzer "otto" erlauben, GParted per pkexec auszuführen, wobei das Password von otto abgefragt wird:
1 2 3 4 5 6 | [extra permissions for gparted for user otto] Identity=unix-user:otto Action=com.ubuntu.pkexec.gparted ResultInactive=no ResultActive=auth_self ResultAny=no |
Die erste Zeile ist eine Kapitelüberschrift in einer INI-Datei, also ein in Klammern []
stehender beliebiger, aber einmaliger Text. Die 2. Zeile legt fest, für wen die Regel gilt; anstatt unix-user
kann man über unix-group
die Regel einer Gruppe zuweisen. Mehrere Benutzer können so angegeben werden: Identity=unix-user:otto;unix-user:susi
. Die 3. Zeile legt fest, für welche Aktion die Regel gilt. Die Zeilen mit Result…
bestimmen, was in verschiedenen Situationen geschehen soll:
ResultActive
gilt für die lokale aktive Sitzung, in der das Passwort des Benutzers erfragt werden soll.ResultInactive
gilt für eine lokale, nicht aktive Sitzung, undResultAny
gilt für eine nicht-lokale Sitzung;no
bedeutet ein nicht zu umgehendes Verbot der Aktion.
Eine weitergehende Erklärung zu Regeln liefert die Dokumentation.
Root-Rechte über PolicyKit¶
Wer einen Root-Account aktiviert hat (siehe Artikel sudo/Konfiguration (Abschnitt „Root-Passwort-einrichten“)) und bei sudo mit der targetpw
Option eingestellt hat, dass das Root-Passwort statt wie sonst bei Ubuntu üblich das Benutzer-Passwort eingegeben werden muss, möchte dies auch für PolicyKit so haben. Das geht beispielsweise durch eine Konfigurationsdatei /etc/polkit-1/localauthority.conf.d/60-root.conf mit folgendem Inhalt:
[Configuration] AdminIdentities=unix-user:0
Dokumentation¶
Eine gute Einführung bieten die Manpages zu den jeweiligen Programmen oder auch die Informationen auf der Projektseite vom PolicyKit.
Die Programme polkitd
, pkaction
und pkcheck
haben jeweils eine eigene Manpage:
man polkitd man pkaction man pkcheck
Hinweise zu Aktionen findet man in der übergeordneten Manpage und in der zu pkexec
:
man polkit man pkexec
Details zu den Regeln erklärt die Manpage für die "local authority":
man pklocalauthority
Man sollte die auf dem eigenen Rechner installierten, zur konkret verwendeten Version von polkit passenden Manpages bevorzugen.
Das "polkit Reference Manual" 🇬🇧 bei freedesktop.org enthält technische Informationen und auch die Manpages als HTML.
Problembehebung¶
pkexec startet Programm mit grafischer Oberfläche nicht¶
Das ist normalerweise genau so vorgesehen, weil der Zugriff eines fremden Benutzers F auf die grafische Oberfläche des anderen Benutzers B schwere Verwüstungen im Home-Verzeichnis von B anrichten kann, wodurch sogar die spätere Anmeldung von B scheitern kann. Das gilt erst recht, wenn der fremde Benutzer root ist.
Das Programm pkexec führt daher standardmäßig keine Programme aus, welche eine grafische Oberfläche benötigen. Beispielsweise scheitert der Aufruf
pkexec gedit
mit einer Fehlermeldung. Dies liegt daran, dass in der Umgebung des fremden Benutzers die für grafische Programme notwendigen Umgebungsvariablen DISPLAY
und XAUTHORITY
des aufrufenden Benutzers nicht verfügbar sind.
Für solche grafischen Programme, die bekanntermaßen trotz Zugriff auf ein fremdes Home-Verzeichnis kein Chaos in diesem anrichten, gibt es 3 Möglichkeiten für einen erfolgreichen Aufruf mit pkexec
:
Der Programmautor kann seine Software intern absichern und eine spezielle Beschreibung einer Aktion mitliefern, die
polkitd
über diese Absicherung informiert. Die grafischen Programme Synaptic und GParted gehen beispielsweise diesen Weg.Der Systemverwalter[5] kann für ein bestimmtes Programm anstelle des Programmautors eine solche Beschreibung einer Aktion erstellen und in dem von ihm betreuten System ablegen. Das sollte man nur dann tun, wenn man den Programmcode des grafischen Programms kennt und selber beurteilen kann, dass es kein Chaos in fremden Home-Verzeichnissen anrichtet. Diese Weg wird hier anschließend am Beispiel von gedit beschrieben, was sich aber eigentlich nicht für diesen Weg eignet. Von einer Anwendung wird daher abgeraten.
Der Anwender kann beim Aufruf die benötigten Umgebungsvariablen mitliefern. Das funktioniert technisch nur in einer auf Xorg basierenden Umgebung, und es erfordert beim Anwender entweder umfangreiche detaillierte Kenntnisse über das aufzurufende Programm oder fehlende Vernunft und fehlendes Verantwortungsbewusstsein.
Für die Wege 1 und 2 muss eine Datei mit einer Beschreibung einer Aktion angelegt werden[3][4]. Dabei müssen die im Anschnitt Sicherheit genannten technischen Anforderungen gelten. Für gedit könnte der Inhalt so aussehen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> <policyconfig> <action id="com.ubuntu.pkexec.gedit"> <message>Authentication is required to run the gedit Editor</message> <icon_name>gedit</icon_name> <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gedit</annotate> <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate> </action> </policyconfig> |
Nach dem Anlegen ist die Aktion direkt aktiv, das System muss nicht neu gestartet werden.
Der Aufbau der Datei ist weitestgehend logisch und selbsterklärend. Mit Dateien nach dem gleichen Schema können auch andere Programme mit grafischer Oberfläche via pkexec gestartet werden. Anzupassen sind jeweils die Zeilen 7, 8, 9 und 15. Die Zeile 16 ist die Zeile, die den Zugriff auf die grafische Oberfläche erlaubt.
Weiterführende Erklärung findet man in der Dokumentation.
Für den 3. Weg ist der Aufruf von pkexec:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY PROGRAMMNAME
PROGRAMMNAME
muss durch das gewünscht Programm ersetzt werden, also z.B. gedit
. Der Aufruf funktioniert so auch, wenn für PROGRAMMNAME
keine Aktion angelegt ist.
Links¶
root – Erklärung des Begriffs "root"
Externe Verweise:
Projektseite 🇬🇧
Dokumentation 🇬🇧 Für Ubuntu vor 24.04 ist 0.105 auszuwählen.
Polkit 🇬🇧 im Wiki von Arch Linux