Wer unter Linux vor verschlossenen Türen steht, greift meist mit su oder sudo zu Root-Rechten. Wesentlich feinfühliger und flexibler lassen sich die Rechte mit PolicyKit erteilen.

Unter Linux sind die Machtverhältnisse klar geregelt: Ausschließlich der allmächtige Nutzer root darf die Systemeinstellungen verstellen, normale Anwender bleiben auf ihrem Desktop eingesperrt. Im Alltag erweist sich diese Zweiteilung oft als hinderlich, beispielsweise wenn man nur mal eben einen USB-Stick einbinden oder die falsch tickende Systemuhr stellen möchte. Teilen sich mehrere Benutzer einen PC, muss dann sogar jedes Mal der menschliche root anrücken.

Abhilfe verspricht das noch relativ junge Projekt PolicyKit [1]. Es bietet eine unabhängige Rechteverwaltung, die ganz ähnlich wie die Telefonauskunft funktioniert: Linux-Programme können dort anrufen und nachfragen, ob ein Benutzer eine bestimmte Systemfunktion ausführen darf.

Fräulein vom Amt

Genau das passiert beispielsweise auch unter Ubuntu, wenn Sie die Systemuhr stellen möchten. Bevor das ziemlich zugeknöpfte Fenster hinter System | Systemverwaltung | Datum und Uhrzeit irgendwelche Änderungen zulässt, ist zunächst ein Klick auf das Schloss-Symbol fällig. Damit fragen die Zeit- und Datumseinstellungen bei PolicyKit an, ob Sie überhaupt berechtigt sind, die Uhr einzustellen.

PolicyKit beantwortet diese Frage mit einem Blick in sein Regelwerk. Dort steht geschrieben, dass Sie die Zeit nur dann ändern dürfen, wenn Sie zur Gruppe der Administratoren gehören und sich mit Ihrem Passwort ausweisen können. PolicyKit bittet daraufhin den Desktopmanager Gnome, das Passwort abzufragen. Der leistet umgehend Folge und öffnet das Fenster aus Abbildung 1. Sobald PolicyKit alle Informationen beisammen hat, gibt es den Zeit- und Datumseinstellungen grünes Licht, woraufhin diese wiederum sämtliche Funktionen freischalten.

Abbildung 1: Das Freischalten der Uhreneinstellungen erfolgt unter Gnome über PolicyKit.

Auf diese Weise lassen sich mit PolicyKit gezielt Rechte erteilen oder entziehen. Beispielsweise könnte man dem Benutzer carlo ausnahmsweise gestatten, an der Uhr zu drehen – alle anderen Systemfunktionen blieben für ihn weiterhin tabu. Im Gegensatz zu su oder sudo erhalten die beteiligten Anwendungen dabei keinerlei Root-Rechte. carlo könnte folglich über das Uhren-Fenster weder die Zeitzone ändern, noch auf andere Teile des Systems zugreifen.

Abbildung 2: Zunächst aktiviert der Client einen Systemdienst (1). Dieser fragt dann via D-Bus PolicyKit um Erlaubnis (2), das wiederum bei Bedarf ein Passwort vom Nutzer einfordert (3).

Zahlenrätsel

Die schöne neue PolicyKit-Welt besitzt allerdings auch ein paar Makel. So müssen sowohl die Anwendungen als auch die Distributionen PolicyKit unterstützen. Einigermaßen flächendeckend ist das im Moment nur unter Ubuntu der Fall. OpenSuse 11.2 und Fedora 12 verlangen für die meisten Systemeinstellungen weiterhin das Root-Passwort. In OpenSuse dient PolicyKit lediglich dazu, die Software-Aktualisierungen durch einen beliebigen Benutzer einspielen zu lassen.

Darüber hinaus wurde das System mit Version 0.9.1 komplett umgekrempelt, die neueren PolicyKit-Fassungen arbeiten nicht mehr abwärtskompatibel. Folglich mussten erst alle Entwickler ihre darauf basiereren Anwendungen anpassen oder umschreiben. Die Distributionen greifen deshalb teilweise zur Holzhammermethode und bringen sowohl eine alte als auch die aktuelle Version mit. Letztere erhält zur besseren Unterscheidung häufig den inoffiziellen Namen PolicyKit-1 oder kurz polkit-1.

Mit ihr stellt auch der grafische Rechteeditor aus Abbildung 3 nur noch Makulatur dar. Er funktioniert ausschließlich unter einem alten PolicyKit bis einschließlich Version 0.9.0. Wer in die Rechtevergabe eingreifen möchte, muss derzeit wohl oder übel zum guten alten Texteditor greifen. Doch das ist weniger aufwändig, als es im ersten Moment klingt.

Abbildung 3: Dieser komfortable Rechteeditor funktioniert nur bis zur PolicyKit-Version 0.9.0.

Herr im Haus

PolicyKit-1 unterscheidet zwischen normalen Nutzern und Administratoren. Letztere dürfen wie root standardmäßig an allen Schrauben des Systems drehen. Wer zu ihnen gehört, bestimmen die Konfigurationsdateien im Verzeichnis /etc/polkit-1/localauthority.conf.d. Im Auslieferungszustand liegt hier nur die Datei 50-localauthority.conf mit dem Eintrag:

[Configuration]
AdminIdentities=unix-user:0

Damit fordert PolicyKit für sämtliche Aktionen, die einem Administrator vorbehalten bleiben (AdminIdentities) das Passwort des Benutzers (unix-user) mit der User-ID 0 an. Dabei handelt es sich um den allseits bekannten Benutzer root. Nach der Installation von PolicyKit bleibt folglich erst einmal alles beim Alten. Unter Ubuntu überschreibt eine zweite Konfigurationsdatei namens 51-ubuntu-admin.conf diese Regel mit folgendem Inhalt:

[Configuration]
AdminIdentities=unix-group:admin

Demnach gehören hier sämtliche Mitglieder der Benutzergruppe admin automatisch zu den privilegierten Administratoren. Diese Vorgabe könnten Sie jetzt einfach an Ihre Bedürfnisse anpassen. Beim nächsten Systemupdate würde die Datei jedoch wieder in ihren Ausgangszustand versetzt, die ganze Arbeit wäre dann umsonst gewesen. Glücklicherweise wertet PolicyKit die Konfigurationsdateien in lexikografischer Reihenfolge aus. Eine eigene Konfigurationsdatei schaltet demnach alle anderen aus, wenn ihr Dateiname mit einer größeren Zahl beginnt.

Um beispielsweise auch noch die Benutzer anton und berta außerplanmäßig zu Administratoren zu erheben, erstellen Sie im Verzeichnis /etc/polkit-1/localauthority.conf.d die Datei 60-meinekonfig.conf und hinterlassen in ihr die Zeilen:

[Configuration]
AdminIdentities=unix-group:admin;unix-user:anton;unix-user:berta

Wie die Datei genau heißt, spielt keine Rolle. Der Name muss lediglich mit einer höheren Zahl (im Beispiel 60) als die der übrigen starten. Die zukünftigen Administratoren reihen Sie durch ein Semikolon getrennt hinter AdminIdentities= auf. Bei anton und berta handelt es sich um einzelne Personen, weshalb Sie ihnen jeweils noch ein unix-user: voranstellen. Analog kennzeichnet unix-group: eine ganze Benutzergruppe.

Wer hat an der Uhr gedreht?

Wer welche Systemfunktionen aufrufen darf, bestimmen entsprechende Regeln, die PolicyKit als “Authorization Entries” bezeichnet. Diese sammelt das Verzeichnis /etc/polkit-1/localauthority in seinen Unterordnern. Eigene Regeln gehören in das Verzeichnis 50-local.d, die Inhalte der übrigen Ordner nennt die Tabelle “Ordner für Authorization Entries”.

Damit auch der normale Benutzer carlo an der Uhr drehen darf, erstellt man hier eine neue Konfigurationsdatei. Sie bekommt die Endung .pkla für “PolicyKit Local Authority”. Der eigentliche Dateiname ist wieder nebensächlich: PolicyKit wertet einfach alle .pkla-Dateien in diesem Verzeichnis in lexikografisch aufsteigender Reihenfolge aus. Sie sollten den Namen jedoch so wählen, dass Sie später noch auf seinen Inhalt schließen können. Für den Uhrmacher carlo erhält die Datei jetzt den Inhalt aus Listing 1.

[Carlo darf die Uhr einstellen]
Identity=unix-user:carlo
Action=org.gnome.clockapplet.mechanism.settime
ResultActive=yes
ResultInactive=no
ResultAny=no

Zunächst steht in den eckigen Klammern eine frei wählbare Beschreibung. Anschließend folgt hinter Identity= der oder die Benutzer, für die alle nachfolgenden Rechteänderungen gelten. Mehrere Benutzer und Gruppen notieren Sie hier jeweils durch ein Semikolon getrennt nach dem bereits bekannten Schema mit unix-users: beziehungsweise unix-group:.

In der nächsten Zeile folgt der Name der betroffenen Systemfunktion beziehungsweise Aktion. org.clockapplet.mechanism.settime steht beispielsweise für die Uhreinstellungen unter Gnome. Welche Aktionen PolicyKit sonst noch kennt und wie diese heißen, verrät der Kommandozeilenbefehl pkaction --verbose. Die entsprechende Liste fällt je nach Distribution relativ lang aus. Zum bequemeren Studium leitet der Befehl

$ pkaction --verbose > liste.txt

sie in die Textdatei liste.txt um. Eine weitere Hilfe liefert unter Gnome das Fenster zur Passwortabfrage aus Abbildung 4. Unter Details nennt es die Aktion, die der Benutzer gerade auslösen möchte.

Abbildung 4: Das Fenster mit der Passwortabfrage nennt unter Gnome die angefragte Aktion und den Anbieter des Systemdienstes.

Innerhalb der .pkla-Datei fassen Sie bei Bedarf mehrere Aktionen mit dem Platzhalter * zusammen. Beispielsweise verändert die Angabe

Action=org.gnome.clockapplet.mechanism.*

auf einen Schlag die Rechte aller Aktionen, die mit org.gnome.clockapplet.mechanism. beginnen. Damit ausgestattet, darf carlo sowohl die Uhrzeit einstellen als auch die Zeitzone ändern.

Justitia

Die letzten drei Zeilen der Regel in Listing 1 biegen schließlich die Rechte um. Möchte carlo die Aktion aus einer laufenden Sitzung heraus ausführen, zieht PolicyKit die Einstellung ResultActive= heran. Mit einem yes dürfte carlo die Uhrzeit ohne weitere Rückfragen direkt umstellen, bei auth_self müsste er hingegen erst noch sein eigenes Passwort preisgeben. Im Fall von auth_self_keep würde sich PolicyKit das Passwort sogar noch ein paar Sekunden merken. Sollte carlo in dieser Zeit noch einmal die Uhr umstellen wollen, müsste er sein Passwort nicht noch einmal eintippen.

Die Angabe auth_admin verlangt schließlich das Passwort eines Administrators. Hier kommen alle Benutzer in Frage, die hinter AdminIdentities= in der Datei /etc/polkit-1/localauthority.conf.d/60-meinekonfig.conf stehen – in unserem Beispiel also anton und berta. Sämtliche weiteren möglichen Werte für ResultActive zeigt die Tabelle “PolicyKit: Berechtigungsarten”. Nach dem gleichen Schema kümmert sich ResultInactive um Anfragen, die aus einer inaktiven Sitzung stammen, ResultAny unterscheidet nicht zwischen aktiven und inaktiven Sitzungen.

Nach dem gezeigten Schema fügen Sie jetzt der .pkla-Datei jetzt weitere derartige Abschnitte hinzufügen und so die Rechte weiter verfeinern. In der Praxis fasst man normalerweise alle zu einer Aktion gehörenden Regeln in einer eigenen Datei zusammen und benennt sie dann wie die Aktion. Die Anpassungen für carlo würden Sie folglich als org.gnome.clockapplet.mechanism.pkla speichern.

Alles oder nichts

Neue Regeln wendet PolicyKit umgehend und ohne Neustart an. Unter Ubuntu bleibt im Beispiel mit der Uhrzeit allerdings die erhoffte Wirkung aus: Canonical hat die Systemeinstellungen so umgebogen, dass ein Klick auf das Schloss-Symbol die Aktion org.freedesktop.systemtoolsbackends.set anfragt. Damit berta die Uhrzeit ändern kann, müssten Sie folglich die dritte Zeile von Listing 1 folgendermaßen ändern:

Action=org.freedesktop.systemtoolsbackends.set

Wie die Aktion schon in ihrem Namen verrät, würden Sie damit jedoch berta den Zugriff auf alle anderen Systemeinstellungen ermöglichen. Sie dürfte nicht nur die Uhrzeit einstellen, sondern auch in die Benutzerverwaltung eingreifen. Unter Ubuntu wäre es daher einfacher, berta gleich in die Gruppe der Administratoren aufzunehmen.

Startrampe

Mit PolicyKit können Sie normalen Benutzern auch das Ausführen von Systemprogrammen gestatten. Dabei springt pkexec an die Stelle des bekannten sudo. Beispielsweise startet der Befehl

$ pkexec --user berta /usr/bin/apt-get

den Paketmanager im Rechtekontext der Benutzerin berta (siehe auch Kasten “Passwortfallen”). Die Anwendung läuft dabei grundsätzlich in einer minimalen und sicheren Umgebung. Dadurch lässt sich zwar kein fremder Programmcode einschleusen, umgekehrt ist es aber auch nicht möglich, X11-Programme unter einem anderen Benutzer zu starten.

$ pkexec --user berta apt-get install gnuchess

pkexec apt-get install gnuchess

Standardmäßig dürfen nur Administratoren ein Programm via pkexec starten, also alle in der Konfigurationsdatei /etc/polkit-1/localauthority.conf.d/60-meinekonfig.conf aufgeführten Personen. Um auch dem normalen Benutzer carlo das Starten von Programmen zu gestatten, erstellen Sie einfach eine neue Regel. Die entsprechende Aktion heißt hierbei org.freedesktop.policykit.exec (Listing 2).

[Programmausführung über pkexec erlauben]
Identity=unix-user:carlo
Action=org.freedesktop.policykit.exec
ResultActive=yes
ResultInactive=no
ResultAny=no

Damit dürfte carlo jedoch sämtliche Programme über pkexec aufrufen. Soll er ausschließlich apt-get mit seinem Passwort starten dürfen, muss eine weitere, spezielle Konfigurationsdatei her.

Aktionsbündnis

PolicyKit kann nur dann eine Anfrage beantworten, wenn es die entsprechende Aktion kennt. Eine Anwendung muss folglich die von ihr angebotenen Systemfunktionen erst einmal PolicyKit mitteilen. Dazu verpackt sie die notwendigen Informationen in eine oder mehrere XML-Dateien, die sie wiederum im Unterverzeichnis /usr/share/polkit-1/actions parkt. Dort finden Sie beispielsweise in der Datei org.gome.clockapplet.mechanism.policy alle Aktionen des Gnome-Uhren-Applets, die eine Authentifizierung via PolicyKit verlangen.

Auch beim Start des Programms /usr/bin/apt-get handelt es sich um nichts weiter als eine Aktion. Um sie zu regulieren, müssen Sie hier eine weitere XML-Datei hinzufügen – deren Inhalt zeigt Listing 3.

<?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>
  <vendor>Linux New Media AG</vendor>
  <vendor_url>http://www.linuxnewmedia.de</vendor_url>
  <action id="de.linuxnewmedia.beispiel.run-apt-get">
    <description>run apt-get</description>
    <description xml:lang="de">apt-get ausführen</description>
    <message>Authentication is required to run the program apt-get</message>
    <message xml:lang="de">Sie müssen sich ausweisen, um das Programm apt-get ausführen zu können</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_self_keep</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/apt-get</annotate>
  </action>
</policyconfig>

Der Aufbau fällt etwas komplizierter aus als bei den bislang angesprochenen Konfigurationsdateien. Das kryptische Zeichengewirr am Anfang ist für jede XML-Datei Pflicht. Zwischen <vendor> und </vendor> steht der Herausgeber oder Entwickler, dessen Internetadresse in <vendor_url>. Als nächstes folgt die Definition der auszuführenden Aktion. Hinter <action id= erhält diese zunächst einen eindeutigen Namen, den PolicyKit auch als Action ID bezeichnet. Sie dürfen die Bezeichnung frei wählen, solange sie aus Zahlen, Kleinbuchstaben, Punkten und Bindestrichen besteht. Für gewöhnlich verwendet man die rückwärts gelesene URL des Herstellers und hängt dann den Namen der Aktion an.

Zwischen <description> und </description> folgt eine Beschreibung der Aktion, <description xml:lang="de"> nimmt die deutsche Übersetzung auf. Analog dürfen Sie Beschreibungen für weitere Sprachen hinterlegen, ein gutes Beispiel dafür liefert die Datei org.gome.clockapplet.mechanism.policy. Den Text innerhalb von message zeigt später das Fenster zur Passwortnachfrage an. Auch hier liefert <message xml:lang="de"> die deutsche Fassung. Der defaults-Abschnitt gibt vor, welche Rechte standardmäßig gelten. Mit

<allow_active>auth_admin</allow_active>

führt pkexec das Programm erst dann aus, wenn der Benutzer der aktiven Sitzung (allow_active) ein Administrator-Passwort eingegeben hat (auth_admin). Diese Einstellungen können Sie später mit einer .pkla-Datei in /etc/polkit-1/localauthority/50-local.d für jeden Benutzer individuell überschreiben.

Dementsprechend sind zwischen allow_active sämtliche Werte aus der Tabelle “PolicyKit: Berechtigungsarten” erlaubt. Analog kümmert sich allow_inactive um Anfragen von inaktiven Sitzungen (und entspricht somit ResultInactive), während sich allow_any (als Pendant zu ResultAny) nicht um die Herkunft schert. Abschließend folgt noch hinter <annotate key="org.freedesktop.policykit.exec.path"> der Pfad zum entsprechenden Programm, im Beispiel zum Paketmanager apt-get.

Die fertige Aktionsbeschreibung speichern Sie unter der Endung .policy. Der eigentliche Dateiname ist wieder unwichtig, in der Regel wählt man ihn genau so wie die Aktions-ID.

Extrawurst

Anschließend richten Sie im Unterverzeichnis /etc/polkit-1/localauthority/50-local.d eine spezielle (Ausnahme-)Regel für den Benutzer carlo ein (Listing 4). Damit darf carlo ab sofort das Programm apt-get per pkexec starten, ohne sein Passwort eingeben zu müssen (Abbildung 5). pkexec prüft allerdings nicht, welche Parameter ein Benutzer dem Programm mit auf den Weg gibt. carlo könnte im Beispiel folglich irgendein beliebiges (Schad-)Paket einspielen.

[Programm apt-get für Carlo freischalten]
Identity=unix-user:carlo
Action=de.linuxnewmedia.beispiel.run-apt-get
ResultActive=yes
ResultInactive=no
ResultAny=no

carlo nur sein eigenes Passwort preisgeben, apt-get läuft anschließend dennoch mit Root-Rechten.” width=”300″ height=”233″ /> Abbildung 5: Mit entsprechend gesetzten Rechten darf auch ein normaler Benutzer Programme installieren. In diesem Fall muss carlo nur sein eigenes Passwort preisgeben, apt-get läuft anschließend dennoch mit Root-Rechten.

Fazit

Mit PolicyKit lassen sich äußerst flexibel maßgeschneiderte Zugriffsprofile erstellen. Im Gegensatz zu su und sudo erhält der Anwender nicht gleich einen Freifahrtschein für die gesamte Anwendung, sondern bleibt auf einzelne (System-)Funktionen beschränkt. Zudem muss er nicht umständlich auf der Kommandozeile hantieren, sondern gibt höchsten sein Passwort preis.

In komplexen Szenarien fallen die Regeln jedoch schnell unübersichtlich aus, das Erstellen und Warten via Texteditor ist alles andere als komfortabel. Darüber hinaus setzt PolicyKit ein weiteres Rechtemanagement auf das von Linux. Selbst wenn Sie carlo den Start eines Programms mit PolicyKit verbieten, kann er es eventuell weiterhin direkt oder über sudo ausführen. Sie müssen folglich sowohl die Einstellungen von PolicyKit als auch die herkömmlichen Rechte im Blick behalten.

Nicht zuletzt müssen Entwickler PolicyKit explizit in ihren Anwendungen unterstützen, die Desktopsysteme einen Passwort-Bildschirm bereitstellen und die Distributionen PolicyKit konsequent einsetzen. Wie die (noch) aktuellen Fassungen von OpenSuse, Fedora und Ubuntu zeigen, besteht zumindest beim zuletzt genannten Punkt noch reichlich Aufholbedarf.