Das neue Sicherheitsmodell Policykit ermöglicht unter Ubuntu Hardy Heron eine bessere Feinabstimmung sicherheitsrelevanter Aufgaben, als das bislang mit Sudo möglich war.

Bei Desktop-Systemen gestaltet sich eine lupenreine Trennung zwischen Systemverwalter und Anwender schon deshalb schwierig, weil letzterer am heimischen PC meist beide Hüte auf hat. Da immer mehr Anwendungen tief in die Systemkonfiguration eingreifen, ist ein administrativer Zugriff aufs System beinahe unabdingbar. So erfordert schon das Einbinden eines Laufwerks den privilegierten Zugriff auf bestimmte Funktionen. Auch andere Geräte, wie etwa DVB-T-Empfänger, Bluetooth oder WLAN erfordern sowohl beim Einrichten als auch beim Konfigurieren administrative Rechte. In diesen Fällen bieten Sudo und Policykit geeignete Möglichkeiten, dem Anwender die notwendigen Legitimationen zu erteilen, ohne das System durch eskalierende Berechtigungen zu gefährden.

Sudo

Der konsequente Einsatz von Sudo sorgt unter Ubuntu dafür, dass der Anwender nur dann privilegierte Rechte in Anspruch nimmt, wenn er sie auch benötigt. Ubuntu richtet zwar das obligatorische Root-Konto ein, allerdings ohne ein Passwort dafür zu setzen. Trotzdem schränkt dieser Umstand den Anwender bei der Administration des Systems kaum ein, da er nur in seltenen Fällen eine vollständige Root-Umgebung benötigt.

Sämtliche Aufgaben, die einen privilegierten Zugriff erfordern, erledigt der Anwender mit dem vorangestellten Kommando sudo. Um grafische Programme mit administrativen Rechten zu laden, dient unter Gnome das Hilfsprogramm gksu und unter KDE kdesu. Möchten Sie Anwendungen mit privilegierten Rechten per Mausklick ausführen, setzen Sie diese Hilfsprogramme auch in Schnellstartverknüpfungen und Desktop-Links ein. So lädt der Aufruf gksu gedit nach Eingabe des Benutzerpassworts den Editor Gedit mit privilegierten Rechten.

Beim Aufruf schlägt Sudo in der Konfiguration /etc/sudoer nach, welcher Benutzer welche Ausführberechtigungen besitzt. Diese Datei darf nur mit mit dem Programm Visudo bearbeitet werden. Die wichtigsten Einträge in der Grundeinstellung sind:

root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

Sie erlauben dem Benutzer root und den Mitgliedern der Gruppe admin das Ausführen jedes Befehls auf dem System. Warum der Aufwand, wenn der Benutzer in der Gruppe admin ohnehin alles darf?

Auch wenn der Benutzer damit alle Kompetenzen besitzt, ist der Unterschied zwischen root und sudo sicherheitstechnisch gewaltig. So protokolliert Sudo sämtliche Aktionen in der Datei /var/log/auth.log. Programme, die im Benutzerkontext starten, sind entsprechend nicht in der Lage, unbemerkt Veränderungen am System vornehmen. Des weiteren erfordert jede Sudo-Sitzung die Eingabe des Passworts. Um nicht die ganze Macht zu übertragen, erlaubt Sudo darüber hinaus das feinere Einstellen der Berechtigungen. Folgender Eintrag in die Datei /var/log/auth.log legitimiert beispielsweise den Benutzer fred lediglich dazu, die Datei /var/log/auth.log mit dem Programm Less zu lesen:

fred    ALL=/usr/bin/less /var/log/auth.log

Der jeweiligen Anwendung spricht Sudo dabei vollständig das Vertrauen aus. Durch die Einschränkung auf bestimmte Parameter könnte man die Funktionen des Programms, wie zum Beispiel mit vim -R, auf das Lesen einschränken. Um den Zugriff auf Funktionen komplexerer Anwendungen und Funktionen zu delegieren, eignet sich Sudo allerdings nicht: Hier kommt Policykit ins Spiel.

Policykit

Das Sicherheitssystem Policykit wurde erstmals in Ubuntu 8.04 eingeführt und erlaubt die Feinabstimmung der Benutzerrechte für bestimmte Systemkonfigurationen und Programme. Es handelt sich dabei um eine XML-Skript-Sammlung, die Sie im Pfad /usr/share/Policykit/policy finden. Jedem Aktionspfad der GUI ist eine entsprechende XML-Datei zugeordnet, beispielsweise org.freedesktop.hal.storage.policy.

Die Laufzeitbibliothek Libpolkit bildet das Rückgrat des Policykit, mit deren Hilfe es die Autorisierung prüft und erteilt. Versucht zum Beispiel eine Anwendung ein Laufwerk zu mounten, wird die Anfrage an den Hardware Abstraction Layer (HAL) weitergeleitet (Abbildung 1, Punkt 1), der die Autorisierung über Libpolkit abwickelt (Punkt 2). Dabei kann die Antwort nicht nur “Ja” oder “Nein” lauten, sondern auch “Ja, falls sich die Anwendung authentisieren kann” (3). Ist eine Authentisierung notwendig, kommt der Authentisierungsagent (4) ins Spiel. Er fragt das Kennwort ab und gibt das Ergebnis einer erfolgreichen Authentisierung an die Autorisierungsdatenbank weiter (5). Bei der erneuten Autorisierungsprüfung (6) findet Libpolkit dann den Authentisierungsnachweis und gibt den Zugriff frei (7).

Abbildung 1: Die schematische Darstellung zeigt das Zusammenspiel der verschiedenen Komponenten bei der Rechtevergabe und Authentisierung mit Policykit.

Policykit unterscheidet zwei Bereiche: Die Benutzerumgebung und den Systemkontext. Der Systemkontext umfasst sämtliche Funktionen, die erweiterte Berechtigungen erfordern. Dazu zählen die Konfiguration das System sowie für Hardware- und Netzwerkkomponenten. Die Benutzerumgebung enthält Anwendungen, die auf die Systemkomponenten zugreifen. Der System-Message-Bus zeichnet als Vermittler für den Informationsaustausch zwischen den beiden Welten verantwortlich. Damit proprietäre Protokolle diese Kontrolle nicht unterwandern, stellt HAL ein einheitliches Protokoll zur Verfügung. So ist das Einbinden von Hardware wesentlich einfacher, da die Anwendungen sich auf eine einheitliche Schnittstelle konzentrieren.

Policykit verwaltet derzeit 45 Aktionen. Das relativ abstrakte Konzept beschreibt eine Aktion als das, was ein Subjekt (Anwender, Prozess) mit einem Objekt (Gerät, Konfiguration) tun darf. Im Gegensatz zu Sudo, das die Ausführung sämtlicher sämtlicher Programme kontrollieren kann, ist das Policykit auf die Integration in die jeweilige Anwendungen angewiesen. Eine ausführliche Anleitung finden Sie im Policykit-Handbuch [1]. So klappt zum Beispiel beim gnome-clockapplet die Umstellung der Zeitzone, doch die Änderung der Systemzeit funktioniert noch nicht, obwohl die Einstellungen im Policykit das vermuten lassen. Zumindest sind einige wichtige Funktionsaufrufe im Policykit vorbereitet und zur Verwendung vorgesehen

Insgesamt ist das noch nicht der große Rundumschlag, in der Praxis bietet die vorhandene Integration jedoch schon eine gewisse Hilfe: Mit der Kontrolle des Powermanagements, der Datenträger, und einigen Multimediageräten deckten die Entwickler zumindest die häufigsten Problemfälle ab.

Vertrauensfrage

Policykit unterscheidet, ob sich der Benutzer lokal angemeldet beziehungsweise sich überhaupt angemeldet hat (“Active Console” beziehungsweise “Console” oder “Anyone”). Schon das Beschränken auf lokale Anmeldungen reduziert die Angriffsmöglichkeiten erheblich. Bei der Anmeldung (“Authentication”) legen Sie zusätzlich fest, ob nur Administratorkonten berechtigt sind (“Admin Authentication”). Die Freigabe lässt sich zudem zeitlich einschränken (Abbildung 2). So gibt es folgenden Varianten:

• die einmalige Freigabe (“one shot”),
• die Freigabe durch das Passwort (“Authentication”),
• für eine Sitzung (“keep session”),
• nach einmaliger Authentisierung dauerhaft (“keep indefinitly”) und
• die Freigabe durch die Anmeldung am System (“Yes”).

Abbildung 2: Policykit bietet eine Vielzahl verschiedener Authentisierungsmöglichkeiten für privilegierte Aufgaben.

Systemkonfigurationen, etwa die Netzwerkeinstellungen, erkennt das Programm als eine Aktion org.freedesktop.systemtoolsbackend.set, die nur der Administrator entsperren darf. Den Passwortdialog bietet es daher auch nur solchen Benutzern an, die über Administrationsrechte verfügen. Obwohl auf dem System der Benutzer fred existiert (Abbildung 3), wird nur der Administrator marcus im Dropdown-Menü angezeigt.

Abbildung 3: Systemverwaltungsaufgaben, etwa das Ändern der Netzwerkeinstellungen, bleibt Anwendern mit administrativen Rechten vorbehalten. Normale Benutzer zeigt Policykit in der Auswahlliste nicht an.

Verwaltungsoberfläche

Sie starten die Verwaltungsoberfläche über System | Systemverwaltung | Authorizations (Abbildung 4). Alternativ verwenden Sie den Aufruf polkit-gnome-authorization im Terminal. KDE fehlt derzeit eine grafische Konfiguration für Policykit – alle Einstellungen nehmen Sie dort mit Kommandozeilenprogrammen vor, die der Abschnitt “Klicklos” näher beschreibt.

Abbildung 4: Die Konfigurationsoberfläche von Gnome erleichtert das Einstellen der Berechtigungen von Policykit erheblich, weist aber – speziell auf Programmebene – noch erhebliche Defizite auf.

Policykit verwaltet die Autorisierungen und die entsprechenden Aktionen für die Steuerung der Hardware (HAL), Einstellungen für Policykit selbst (policykit) und für die Systemprogramme (systemtoolsbackend). Die Gruppe clockapplet zeichnet für die Einstellungen der Systemzeit zuständig. Die verschiedenen Aktionen sind in einer an die Organisationsstruktur von Freedesktop.org [2] angelehnten Baumstruktur angeordnet. Nach Anwahl einer Rubrik erscheinen im rechten Teil Informationen und die Einstellungsoptionen.

Die Einstellungen unterscheiden implizite und explizite Autorisierungen. Implizite Autorisierungen werden automatisch durch die Art der Anfrage erteilt, beispielsweise von der lokalen Konsole. Explizite Autorisierungen erteilt Policykit, indem der Anwender sich mit seinem Passwort authentisiert oder mit Grant… die entsprechende Berechtigung bekommen. Während ein Klick auf den Button Block… einzelne Autorisierungen zurücknimmt, setzt Revoke alle erteilten Berechtigungen der ausgewählten Aktion zurück.

Neben den Freedesktop.org-Schnittstellen verwaltet Policykit das Gnome-Uhren-Applet für die Uhrzeit im Panel. Sie finden es im Pfad org | gnome | clockapplet | mechanism. In der Grundeinstellung dürfen alle lokal angemeldete Benutzer nach Eingabe ihres Passworts die Systemzeitzone über das Uhrzeit-Applet verändern (Abbildung 5). Da für die Aktion Authentication (keep indefinitely) eingestellt ist, bleibt die Autorisierung auch nach dem Beenden der Sitzung oder einem Neustart des Rechners erhalten.

Abbildung 5: Erst nach der Eingabe des Passworts ist der Anwender berechtigt, die Zeitzone zu wechseln.

In der Standardkonfiguration dürfen normale Benutzer unter anderem Wechseldatenträger einbinden und auswerfen, das System herunterfahren oder das WLAN an- und ausschalten.

Klicklos

Auch wenn die Bearbeitung grundsätzlich mit jedem Texteditor möglich wäre, sollten Sie die Konfigurationsdaten von Policykit nur mit den dafür vorgesehenen Werkzeugen Polkit-auth und Polkit-action editieren.

Jeder lokal angemeldete Benutzer darf in der Grundeinstellung nach der einmaligen Eingabe seines Passworts die Zeitzone wechseln. Als Anwendungsbeispiel soll die Berechtigung so geändert werden, dass er das Passwort bei jeder Änderung eingeben muss. Dazu führen Sie im Terminal das folgende Kommando aus:

$ polkit-auth --obtain org.freedesktop.policykit.modify-defaults

Da nur der Administrator Default-Einstellungen ändern darf, fragt das System für die Freigabe dieser Aktion das Administratorkennwort ab. Bei erfolgreicher Authentisierung besitzt die aktuelle Bash-Sitzung das Recht, Änderungen an der Policykit-Konfiguration vorzunehmen. Mit dem folgenden Befehl setzen Sie die Standardeinstellung der lokalen Konsole auf “Authentisieren”:

$ polkit-action --set-default-active org.gnome.clockapplet.mechanism.settimezone auth_self

Das Ergebnis überprüfen Sie entweder im grafischen Konfigurationsmenü oder im Terminal. Ob die Dateien nach einem solchen Eingriff noch fehlerlos sind, zeigt die Eingabe von polkit-policy-file-validate /usr/share/Policykit/policy/Konfigurationsobjekt.policy im Terminal. Eine Nachricht über den Systembus (D-Bus) an das Clock-Applet versucht, die Zeitzone zu wechseln und scheitert zunächst an der Autorisierung (Listing 1)

$ dbus-send --system --dest=org.gnome.ClockApplet.Mechanism / org.gnome.ClockApplet.Mechanism.SetTimezone string:/usr/share/zoneinfo/Europe/London
Error org.gnome.ClockApplet.Mechanism.NotPrivileged: org.clockapplet.mechanism.settimezone auth_self <-- (action, result)

Die Autorisierung setzen Sie, wie bereits bekannt, mit polkit-auth --obtain org.gnome.clockapplet.mechanism.settimezone. Hier wird jetzt das Passwort abgefragt und für die aktuelle Bash-Sitzung hinterlegt. Senden Sie nun die Nachricht erneut an das Clock-Applet, klappt die Umstellung der Zeitzone.

Überzeugungsarbeit

Da Anwendungen die Kommunikation über den Systembus oder über Libpolkit unterstützen müssen, greifen viele Regeln des Policykits noch ins Leere. Dennoch bringt das Verwenden von Policykit bereits viele Vorteile. Das betrifft nicht nur die Sicherheit, auch die Stabilität des Systems lässt sich durch ein einheitliches Interface erhöhen. Die Standardkonfiguration erscheint bereits recht gut gelungen, da sie nur dann Passwörter abfragt, wenn das auch notwendig ist.

Das Nutzen der Kommandozeilentools gestaltet sich allerdings recht mühsam, wenn man über den Systembus kommunizieren muss: Man bekommt die Informationen zu den einzelnen Diensten und Nachrichten nicht gerade auf dem Präsentierteller serviert. Hier erweist sich der Einsatz von Sudo als wesentlich einfacher und auch flexibler.