ubuntuusers.de

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.

Für Ubuntu ab 24.04 lese den Artikel PolicyKit[6].

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 entsperren.png 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 oder polkitd haben.

  • Nur root darf in diesen Ordnern Dateien anlegen oder entfernen, dh. Dateirechte der Ordner dürfen maximal 755 oder verschärfend 555 bzw. 550 lauten.

  • Nur root darf in diesen Ordnern Dateien ändern, dh. Dateirechte für Dateien in den Ordnern dürfen maximal 644 oder verschärfend 640 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:

Es gibt auch nach 22.04 ein Paket policykit-1 in den Paketquellen, welches allerdings ab 24.04 anders arbeitet als das in diesem Artikel beschriebene, siehe hierzu Artikel PolicyKit[6]!

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, und

  • ResultAny 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:

  1. 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.

  2. 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.

  3. 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.

  • root – Erklärung des Begriffs "root"

Externe Verweise:

Diese Revision wurde am 19. April 2025 00:38 von RuhigesKätzchen erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Sicherheit, System, ungetestet