Rechte mit PolicyKit unter Linux vergeben

Wer sich unter Linux mit administrativen Rechten beschäftigt, denkt meist an die drei Worte:

• root – der wahre Administrator unter Linux
• su – der Befehl, mit dem man unter Linux zu root wird
• sudo – der bisschen-root

Wer unter Linux Rechte ein wenig feinfühliger vergeben möchte, setzt sich dann lieber mit PolicyKit auseinander. Mit diesem Rechtesystem lassen sich Rechte an einzelnen Benutzern viel besser vergeben. So können Sie einem Benutzer das Recht geben, das System zu aktualisieren, aber trotzdem darf dieser nicht an Systemdateien arbeiten und vieles mehr. PolicyKit ist unter den meisten Linux-Distributionen sowieso vorinstalliert, also warum nicht nutzen?

Etwas muss aber gleich auch gesagt werden – man muss sich mit diesem Rechtesystem schon etwas befassen, um damit sinnvoll arbeiten zu können.

Wie funktioniert PolicyKit?

Nehmen wir an, Sie öffnen eine normale Benutzersoftware – im Beispiel ganz einfach etwa Discover, Ubuntu Software oder was auch immer. Diese Anwendungen dienen dazu, weitere Software zu installieren, das System zu aktualisieren oder um Software zu entfernen. Die Anwendungen lassen sich ohne administrative Rechte öffnen, etwas am System verändern können Sie damit jedoch nur mit dem root-Passwort oder wenn Sie in der sudo-Gruppe sind.

Die Software, also in diesem Fall Discover oder Ubuntu Software, bezeichnen wir hier als Client. Diese Clients sind unterpriviligierte Anwendungen – eben ohne administrative Rechte gestartet. Der unterprivilegierte Client ruft jetzt beispielsweise, um Software zu installieren, eine Funktion auf – diese Funktion nennt man unter PolicyKit Mechnism. Mechanism fragt jetzt bei PolicyKit nach, ob dieser Benutzer dies auch darf – der nötige Dienst von PolicyKit nennt sich nun ganz einfach „polkitd„. Ist der Benutzer dazu berechtigt, obwohl er nicht zu den administrativen Benutzern gehört, fragt das System nach dem Passwort des Benutzers – erledigt.

Ein weiteres Beispiel, Sie haben vom Administrator kein root-Passwort und sind auch nicht in der sudo-Gruppe – der Administrator kann Ihnen trotzdem das Recht geben, etwa die Uhrzeit anzupassen.

Jetzt sehen wir uns die Konfiguration an. Das Verzeichnis für die Konfiguration von PolicyKit liegt unter „/etc/polkit-1/„:

Für unsere Anpassengen, also für unsere Rechtevergaben, ist vor allem das Unterverzeichnis „localauthority.conf.d“ wichtig. Auf einem reinen Debian, ist vor allem bei einem root-System (nicht sudo), hier noch keine Konfiguration hinterlegt. Unter sudo-Systemen hingegen (meist) schon, also etwa Ubuntu.

Unter sudo-Systemen liegt hier zumeist zu Beginn nur eine einzige Datei namens „50-localauthority.conf„, deren Inhalt:

[Configuration]
AdminIdentities=unix-user:0

Unsere wichtigste Information – die zweite Zeile, in diesem Fall die Nummer „0„. Bei dieser Ziffer handelt es sich um die User-ID. Diese Zeile besagt nichts anderes als – bei administrativen Aufgaben – „AdminIdentities“ – fragt das System ausschließlich das Passwort des Administrators „root“ ab – dieser hat die UID „0„:

Wichtig, bei jedem Update des Systems und PolicyKit wird diese Datei überschrieben – diese Datei zu bearbeiten wäre also nicht sonderlich sinnvoll. Wir legen im selben Verzeichnis eine neue Datei mit einer höheren Nummer an (die natürlich nicht bereits vorhanden sein darf) – etwa:

nano 51-debian-meine-admin.conf

Die Nummer muss höher sein, denn nur dann ignoriert das System darunter liegende Dateien. Wir können jetzt wie im Bild oben schon beschrieben mit dem Befehl:

id

unsere User-ID abrufen – diese zeigt sich unter dem Eintrag „uid=„. Mit dem Befehl:

cat /etc/group

können wir alle bestehenden Gruppen anzeigen lassen:

Jetzt können wir beispielsweise, wie unter Rechte an Dateien und Verzeichnissen unter Linux beschrieben, eine neue Gruppe namens „admin“ anlegen (die Gruppe können Sie natürlich nennen wie Sie möchten) und Benutzer zu dieser Gruppe hinzufügen (die Gruppe darf natürlich nicht schon bestehen).

Jetzt könnten wir in unserer neu angelegten Datei (51-debian-meine-admin.conf), eine neue Konfiguration anlegen:

[Configuration]
AdminIdentities=unix-group:admin

Diese Benutzer dürfen jetzt mit ihrem eigenen Passwort administrative Aufgaben ausführen. Wir können statt einer Gruppe auch die bestehenden Benutzer angeben – um etwa die beiden Benutzer „robert“ und „katarina“ zu Administratoren zu machen:

[Configuration]
AdminIdentities=unix-user:robert;unix-user:katarina

Auch können wir eine Gruppe und zusätzlich Benutzer angeben:

[Configuration]
AdminIdentities=unix-group:admin;unix-user:robert;unix-user:katarina

Jetzt will man aber meist nicht, dass alle Benutzer am System schrauben können, wie diese wollen. Wir wollen diesen nur spezielle Rechte geben. Dazu dienen die weiteren Unterverzeichnisse – Regeln erstellen wir unter „/etc/polkit-1/localauthority/„, und zwar im Unterverzeichnis „50-local.d„.

Die darin enthaltenen Dateien haben die Endung „.pkla“ und beginnen wieder mit einer Zahl. Wie Sie die Dateien benennen ist egal – Sie sollten nur auf deren Inhalt schließen können, um die Übersicht nicht zu verlieren. Erst sehen wir uns die Unterverzeichnisse unter „/etc/polkit-1/localauthority/“ etwas genauer an:

• 10-vendor.d – Regeln vom Distributor der Distribution
• 20-org.d – Regeln des Vertreibers der Distribution
• 30-site.d – Regeln des Systems
• 50-local.d – Eigene Regeln
• 90-mandatory.d – ähnlich wie „20„

Damit wir mit PolicyKit arbeiten können, müssen wir wissen – was kann dieser Dienst eigentlich? Dazu starten wir den Befehl:

pkaction --verbose > regeln.txt

In der entstandenen Textdatei finden Sie vordefinierte Aktionen, wir können natürlich auch selbst welche erstellen. Wollen wir beispielsweise dem Benutzer „robert“ erlauben, mittels APT Software zu installieren. In diesem Fall erstelle ich die Datei „51-robert-apt.pkla„:

[APT für robert freischalten]
Identity=unix-user:robert
Action=de.linux.bibel.run.apt
ResultActive=yes
ResultInactive=no
ResultAny=no

PolicyKit kennt diese Aktion nicht, daher müssen wir dem Dienst zeigen, was wir damit meinen – dies regeln wir mit Dateien unter „/usr/share/polkit-1/actions/“ – hier finden wir auch schon einige Beispiele:

Anschließend sehen wir auch, wie es zur Konfigurationsdatei oben kommt. Dort erstellen wir jetzt eine neue XML-Datei, etwa „de.linux.bibel.run.apt.policy“ – wie wir sehen, muss die Datei mit der Endung „.policy“ versehen sein.

<?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://linux-bibel-oesterreich.at</vendor_url>
   <action id="de.linux.bibel.run.apt">
   <description>run apt</description>
   <description xml:lang="de">apt ausführen</description>
   <message>Authentication is required to run the program apt</message>
   <message xml:lang="de">Sie müssen sich ausweisen, um das Programm apt 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</annotate>
   </action>
</policyconfig>

robert kann anschließend mit seinem Passwort mittels APT Software am Terminal installieren:

pkexec apt install paket

Dies gelingt natürlich auch mit grafischen Anwendungen, etwa Synaptic. Sie brauchen sich nur die passende Aktion unter „/usr/share/polkit-1/actions/“ erstellen und die dazu passende Regel unter „/etc/polkit-1/localauthority/„.