© claudiarndt, Photocase.com

Sollen normalerweise betreute PC-Anwender sich öfter selbst helfen, brauchen sie zusätzliche Berechtigungen. Das Tool Sudo und der Berechtigungsdienst Policykit regeln unter Linux, wer was darf.

Für Admins wäre es eine Erleichterung, wenn normale Benutzer kleinere Wartungsaufgaben selbst lösen könnten, etwa Software aktualisieren. Dumm ist nur, dass etwa »apt-get« Administratorrechte verlangt, und die möchte man einem normalen Nutzer auf keinen Fall gewähren. Glücklicherweise kann ihm der Admin mit »sudo« oder dem Berechtigungsdienst Policykit ganz gezielt bestimmte Aktionen erlauben.

Das Hilfsprogramm »sudo« führt die nachgestellten Anweisungen im Namen eines anderen Benutzers aus. Für »apt-get upgrade« wäre dies beispielsweise der allmächtige »root« . Welcher User Sudo wie mit welchen Programmen nutzen darf, steht in der Konfigurationsdatei »/etc/sudoers« . Um etwa dem Benutzer »klaus« das Aktualisieren seines eigenen Computers namens »marvin« zu gestatten, fügt der Admin ihr folgende Zeile hinzu:

klaus marvin=(ALL) NOPASSWD:/usr/bin/apt-get upgrade

Am Anfang der Zeile steht der Benutzername. Es folgt der des Rechners, von dem aus »klaus« das Kommando absetzen darf. In diesem Fall muss er vor seinem eigenen Rechner »marvin« sitzen.

Sollte er beim Aufruf von »apt-get upgrade« eine Fehlermeldung in der Art »klaus is not allowed to run sudo on …« erhalten, stimmt sehr wahrscheinlich etwas mit der Namensauflösung nicht. Der Administrator sollte dann prüfen, ob der angegebene Rechnername mit der Ausgabe von »hostname« übereinstimmt, und kontrollieren, ob dieser mit den Inhalten der Datei »/etc/hosts« korrespondiert.

Mit »ALL« anstelle des Rechnernamens darf »klaus« von jedem Rechner aus »apt-get upgrade« aufrufen. Alternativ zum Rechnernamen kann man natürlich auch die IP-Adresse angeben. Einen Adressbereich formuliert man als Subnetz:

klaus 192.168.2.0/255.255.255.0=(ALL)NOPASSWD:/usr/bin/apt-get upgrade

In diesem Fall dürfte der Benutzer »klaus« nur dann den Befehl aufrufen, wenn er vor einem Rechner mit einer IP-Adresse aus dem Bereich 192.168.2.1 bis 192.168.2.254 sitzt.

Sudo führt einen Befehl unter einem anderen Benutzerkonto aus. Welche Konten »klaus« dabei von den vorhandenen wählen darf, regelt die Angabe in den Klammern. Mit »(tim)« könnte »klaus« das Programm nur als Benutzer »tim« starten. Das »(ALL)« berechtigt »klaus« dazu, sich ein beliebiges Benutzerkonto aussuchen, also auch das für »apt-get« notwendige des Benutzers »root« :

sudo -u root apt-get upgrade

Die Option »-u« für den gewünschten User ist im Falle von Root optional. Bevor »sudo« das Kommando »apt-get upgrade« ausführt, muss »klaus« normalerweise sein Passwort eingeben.

Ausgewiesen

Das ist nicht mehr notwendig, sobald »NOPASSWD:« vor dem Programmnamen in der Konfigurationsdatei steht. Der eigentliche Befehl folgt schließlich am Ende der Zeile. Soll »klaus« mehrere Programme oder Kommandos starten dürfen, stehen diese einfach durch Kommata getrennt hintereinander:

klaus marvin=(ALL) NOPASSWD:/usr/bin/apt-get update,/usr/bin/apt-get upgrade

Hier könnte »klaus« lediglich die Paketdatenbank auf den aktuellen Stand bringen und Aktualisierungen einspielen, jedoch keine Programme neu installieren. Das universelle »ALL« lässt sich auch bei den anderen Angaben verwenden. Die folgende Zeile stellt »klaus« mit dem Benutzer »root« gleich:

klaus ALL=(ALL) ALL

Alternativ zu einzelnen Benutzern kann die Sudoers-Datei auch gleich allen Mitgliedern einer Gruppe, etwa »admin« , entsprechenden Zugriff gewähren:

%admin ALL=(ALL) ALL

Das vorangestellte Prozentzeichen signalisiert Sudo, dass es sich um eine Gruppe und nicht um einen einzelnen Benutzer handelt. Auf diese Weise erlaubt etwa Ubuntu allen Administratoren den Zugriff auf Systemfunktionen.

Listing 1 zeigt die Konfigurationsdatei »sudoers« aus Ubuntu, der Übersichtlichkeit halber ohne ihre vielen Kommentare: Root sowie die Benutzer aus der Gruppe »admin« und »sudo« dürfen alles, die restlichen Benutzer nichts. Das zweite »ALL« in den Klammern kennzeichnet den erlaubten Gruppennamen, »klaus« dürfte den Befehl somit unter dem Konto eines beliebigen Benutzers aus einer beliebigen Gruppe ausführen.

01 # Umgebungsvariablen neu setzen:
02 Defaults        env_reset
03 Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
04
05 # Zugriffe erlauben:
06 root    ALL=(ALL:ALL) ALL
07 %admin ALL=(ALL) ALL
08 %sudo   ALL=(ALL:ALL) ALL
09
10 # Weitere Regeln einbinden:
11 #includedir /etc/sudoers.d

Vorspann

Mit »Default« beginnende Zeilen verändern jeweils eine Standardeinstellung von Sudo. In Listing 1 setzt »env_reset« die Umgebungsvariablen zurück, und »secure_path« definiert die »PATH« -Variable, also die Verzeichnisse, in denen Linux die auszuführenden Programme suchen darf. Beide Maßnahmen sollen Angriffe erschweren. Normalerweise behält »sudo« ein einmal eingegebenes Passwort. Nützlich ist deshalb auch noch Folgendes:

Defaults timestamp_timeout=15

Damit vergisst Sudo bei allen Benutzern das Passwort nach 15 Sekunden. Bei einer »« müssten die Benutzer bei jedem »sudo« -Aufruf ihr Passwort eintippen. Alle weiteren Standardeinstellungen nennt die Manpage »man 5 sudoers« .

Innerhalb von »/etc/sudoers« negiert das Ausrufezeichen eine Einstellung. Damit kann der Admin etwa verhindern, dass »klaus« ein ganz bestimmtes Programm aufruft. Dazu stellt er dem Programmnamen lediglich das Ausrufezeichen voran. Im folgenden Beispiel darf »klaus« nicht den Computer neu starten:

klaus marvin=(ALL) !/sbin/reboot

Alle fehlgeschlagenen Nutzungsversuche von »sudo« landen normalerweise im Syslog, unter Ubuntu in der Datei »/var/log/auth.log« . So lässt sich rasch herausfinden, welcher Benutzer seine Finger im Spiel hatte.

Tanz mit dem Teufel

Sudo ist aber ein gefährliches Biest, und zwar in mehrfacher Hinsicht. So kann man sich mit nur einem kleinen Tippfehler oder einem »!« an der falschen Stelle komplett aus dem System aussperren. Das passiert unter Umständen auch bei Regeln, von denen niemand solche Auswirkungen erwartet hätte.

Daher sollte der Admin die Datei »/etc/sudoers« nur mit dem dafür geschaffenen »visudo« ändern. Dieser Editor prüft unter anderem die Syntax der Konfigurationsdatei. Anders als das »vi« im Namen andeutet, steckt dahinter bei einigen Distributionen heute der Editor »nano« (Abbildungen 1 und 2). Unter Ubuntu ließ er in einer Stichprobe selbst offensichtliche Tippfehler haufenweise durchgehen. Man sollte sich daher nicht zu sehr auf das Werkzeug verlassen.

Abbildung 1: Während unter Ubuntu der Aufruf von »visudo« lediglich die »sudoers« vor weiteren Zugriffen schützt und dann »nano« auf den Plan ruft, …

Abbildung 2: … setzt Open Suse den bekannten »vi« ein, der sogar Syntax-Highlighting bietet – wenn auch optisch etwas schrill.

Unter vielen Distributionen ist es zudem üblich, selbst geschriebene Regeln in eine eigene Konfigurationsdatei auszulagern und diese im Verzeichnis »/etc/sudoers.d« zu speichern. Die Zeile

#includedir /etc/sudoers.d

in »/etc/sudoers« sorgt dafür, dass Sudo automatisch alle Textdateien im Verzeichnis »/etc/sudoers.d« einliest und auswertet. Das vorangestellte »#« leitet hier ausnahmsweise keinen Kommentar ein, sondern gehört noch zum Befehl. Die Auslagerung hat den Vorteil, dass der Administrator bei Problemen einfach die zusätzlichen Konfigurationsdateien löschen kann, um den alten Zustand wiederherzustellen.

Vorsicht ist auch bei sich ergänzenden Regeln angebracht. Sollte »klaus« in folgendem Fall auch Mitglied der Gruppe »admin« sein, darf er alle Systemprogramme ausführen und nicht nur »/sbin/reboot« :

klaus marvin=(ALL) NOPASSWD:/sbin/reboot
%admin ALL=(ALL) ALL

In der Praxis sind den Regeln diese Abhängigkeiten aber nicht immer derart direkt anzusehen.

Risiken eindämmen

Um Systemprogramme aufzurufen, besitzt Sudo das Set-UID-Bit. Der Befehl läuft daher immer mit »root« -Rechten. Nur »sudo« selbst verhindert, dass ein gewöhnlicher Benutzer im System Amok läuft. Welche Rechte einem »sudo« gewährt, verrät der Befehl »sudo -l« .

Der Passwortverzicht über »NOPASSWD« ist zwar für die Anwender bequem, doch zum einen ruft der Benutzer vielleicht unbedacht Befehle auf, die das System gefährden, zum anderen könnten auch Schadprogramme unbemerkt im Hintergrund Systemprogramme starten.

Abschließend sollte der Admin immer den vollständigen Pfad zu den Programmen verwenden. Andernfalls kann es passieren, dass »sudo« nicht etwa das originale »apt-get« ausführt, sondern ein Schadprogramm mit gleichem Namen, das sich in den Suchpfad gemogelt hat.

All diese Probleme und Sicherheitsrisiken umschifft der Berechtigungsdienst Policykit [1] mit einer komplett anderen Arbeitsweise: Möchte der Benutzer »klaus« ein Paket installieren, fragt sein Paketmanager zunächst bei Policykit an, ob »klaus« diese Aktion überhaupt gestattet ist. Policykit kann anschließend umgehend grünes Licht geben oder erst noch ein Passwort von »klaus« einfordern.

Erlaubnisdienst Policykit

Im Gegensatz zu Sudo reglementiert Policykit einzelne (System-)Funktionen. So kann der Admin zwar »klaus« die Aktualisierung von Paketen gestatten, die Installation von neuen Paketen jedoch untersagen.

Policykit hat in seiner Entwicklung eine grundlegende Überarbeitung erfahren. Die aktuelle Version bezeichnet man im Allgemeinen als Policykit-1 oder kurz als »polkit« . Verwirrenderweise besitzt sie aber noch nicht die Versionsnummer 1, zum Redaktionsschluss aktuell war die Nummer 0.107. Trotz der Null vor dem Punkt läuft das Policykit-System stabil und kommt schon seit mehreren Jahren unter anderem in Ubuntu, Fedora und Open Suse zum Einsatz.

Den Kern von Policykit bildet der Daemon »polkitd« . Da er lediglich die Anfragen von Systemprogrammen beantworten muss, läuft er mit eingeschränkten Rechten. Über ihn kann folglich niemand das System kapern. »polkitd« stellt seine Funktionen über das Kommunikationssystem Dbus bereit. Alternativ können Programme auch die Bibliothek »libpolkit-gobject-1« nutzen, die die entsprechenden Dbus-Aufrufe kapselt.

Ob die bei Policykit angefragte Aktion gestattet ist, prüft eine »LocalAuthority« genannte Komponente. Wie ihr Name schon andeutet, berücksichtigt sie bei ihrer Entscheidung die lokal auf dem Rechner vorhandenen Benutzerkonten und Gruppen.

Ist die Eingabe eines Passworts erforderlich, ruft Policykit einen so genannten Authentication Agent zu Hilfe. Dieser besteht im Wesentlichen nur aus einer Eingabemaske, wie sie Abbildung 3 zeigt. Jede Desktopumgebung kann ihren eigenen Authentication Agent mitliefern.

Abbildung 3: Beispiel für einen Authentication Agent unter Ubuntu. Wenn man die Details aufklappt, zeigt die Maske die Aktion an, für die das Programm die nötigen Berechtigungen anfordert.

Regulator

Um einem Benutzer den Zugriff auf eine Systemfunktion zu gestatten, muss der Administrator eine entsprechende Regel aufstellen. Alle Policykit-Regeln sind in dem Verzeichnis »/etc/polkit-1/localauthority« versammelt. Dort finden sich wiederum fünf Unterverzeichnisse, auf die die Regeln nach ihren Urhebern verteilt sind.

Wer seine Regeln in welchem Verzeichnis parken muss, verrät Tabelle 1. Administratoren konzentrieren sich auf das Verzeichnis »50-local.d« . Die »LocalAuthority« liest alle dort abgelegten Dateien mit der Endung ».pkla« in lexikografisch aufsteigender Reihenfolge ein.

Sauber eingeordnet

Um beim Regelschreiben nicht den Überblick zu verlieren, sollte der Admin die Dateinamen immer mit einer (aufsteigenden) Nummer beginnen lassen. Die Regeldateien selbst sind einfache Textdateien, wobei mehrere Regeln in einer Datei zusammengefasst sein dürfen. Wichtig ist nur, dass die ».pkla« -Dateien einen eindeutigen Namen tragen. Die eigentlichen Zugriffsregeln bezeichnet Policykit als Authorization Entries.

Listing 2 zeigt eine Regel, die es dem Benutzer »klaus« erlaubt, im Network Manager die systemweiten Netzwerkeinstellungen zu ändern. Ein Kommentar in eckigen Klammern leitet die Regel ein. »Identity« verrät hinter dem Gleichheitszeichen, welche Benutzer oder Benutzergruppen von der Regel betroffen sind. In Zeile 2 ist dies jemand mit einem lokalen Benutzerkonto (»unix-user:« ) und dem Benutzernamen »klaus« . Mehrere Benutzer oder Gruppen trennt die Datei einfach durch Semikola. Mit der Zeile

01 [Klaus darf Netzwerkeinstellungen ändern]
02 Identity=unix-user:klaus
03 Action=org.freedesktop.NetworkManager.settings.modify.system
04 ResultInactive=no
05 ResultActive=auth_self

Identity=unix-user:klaus;unix-group:netzwerker

dürfte neben Klaus auch die gesamte Benutzergruppe »netzwerker« die Netzwerkeinstellungen anpassen.

Darf’s etwas mehr sein?

Hinter »Action« steht der Name der erlaubten Aktion. Welche Aktionen Policykit kennt, verrät der Befehl »pkaction« . Vorsicht, die ausgespuckte Liste kann je nach Distribution relativ lang sein (Abbildung 4). In der Regel ist schon am Namen der Aktion erkennbar, was sie bewirkt. Wer es ganz genau wissen möchte, ruft »pkaction« mit dem Namen der Aktion auf, also etwa (Abbildung 5):

Abbildung 4: Die Bezeichnungen aller von Policykit unterstützten Aktionen verrät »pkaction«, wobei eine lange Liste herauskommen kann.

Abbildung 5: Hier verrät »pkaction«, dass die Aktion »org.freedesktop.NetworkManager.settings.modify.system« es allen Benutzern gestattet, die Netzwerkeinstellungen über den Network Manager zu ändern. Ganz unten in der Ausgabe finden sich noch die voreingestellten Berechtigungen.

pkaction --verbose --action-id org.freedesktop.NetworkManager.settings.modify.system

Die komplette, ausführliche Liste leitet der Admin besser in eine Datei um, etwa mit dem Kommando »pkaction –verbose > aktionen.txt« . Die zur Verfügung stehenden Aktionen hängen von der Distribution und den installierten Programmen ab (siehe Kasten “Policykits Aktionsprogramm”). Mehrere Aktionen lassen sich mit Hilfe des Platzhalters »*« in einer einzigen Regel zusammenfassen. So könnte »klaus« dank

Identity=org.freedesktop.NetworkManager.*

gleich alle vom Network Manager angebotenen Funktionen nutzen.

01 <action id="org.freedesktop.NetworkManager.settings.modify.system">
02     <description xml:lang="de">Netzwerkverbindungen für alle Benutzer bearbeiten</description>
03     <message xml:lang="de">Die Systemrichtlinien verhindern das Bearbeiten von Netzwerkeinstellungen für alle Benutzer</message>
04     <defaults>
05       <allow_inactive>no</allow_inactive>
06       <allow_active>auth_admin_keep</allow_active>
07     </defaults>
08   </action>

Was bin ich?

Policykit unterscheidet zwischen Anfragen, die aus einer aktiven, und solchen, die aus einer inaktiven Sitzung stammen. Was mit Anfragen aus einer aktiven Sitzung passieren soll, steht hinter »ResultActive=« . In Listing 2 muss »klaus« dann sein eigenes Passwort eintippen (»auth_self« ). Im Fall einer inaktiven Sitzung gilt hingegen die Regel hinter »ResultInactive=« . In Zeile 4 steht ein »no« , was das Ändern der Netzwerkeinstellungen über den Network Manager verbietet. Neben »auth_self« und »no« gibt es noch ein paar weitere mögliche Werte, deren Bedeutung Tabelle 2 zusammenfasst.

Alternativ zu »ResultInactive« und »ResultActive« kann der Administrator auch »ResultAny« verwenden, das für aktive und inaktive Sitzungen gleichermaßen gilt. Aus der Dreierbande muss nur mindestens einer in der ».pkla« -Datei auftauchen, für die Fehlenden gelten die von der entsprechenden Aktion vorgegebenen Regeln (siehe Kasten “Policykits Aktionsprogramm”).

Listing 2 könnte der Admin beispielsweise als »51-org.freedesktop.NetworkManager.pkla« im Verzeichnis »/etc/polkit-1/localauthority/50-local.d« ablegen. Sobald dies geschehen ist, berücksichtigt Policykit die neuen Regeln, ein Neustart des Daemon ist nicht notwendig.

Weitere Regelbeispiele finden sich unter »/var/lib/polkit-1/localauthority« . In diesem nur für den Benutzer »root« zugänglichen Unterverzeichnis lagern alle von der Distribution mitgebrachten Regeln. Über den Aufbau der ».pkla« -Dateien informiert die Manpage »man pklocalauthority« .

Allmächtiger

Einige Systemfunktionen sind so gefährlich oder kritisch, dass sie nur ein richtiger Administrator auslösen darf. Die »LocalAuthority« unterscheidet deshalb zwischen normalen Benutzern und Administratoren. Letztgenannte haben schlichtweg die gleiche Stellung wie der Benutzer »root« .

Wer zum elitären Kreis der Administratoren gehört, bestimmen die Konfigurationsdateien unter »/etc/polkit-1/localauthority.conf.d« . Auch hier liest die »LocalAuthority« alle Dateien in lexikografischer Reihenfolge ein, Einstellungen in später gelesenen Dateien überschreiben die vorhergehenden. Der Systemverwalter sollte daher nicht in eine der vorhandenen Dateien eingreifen, sondern eine selbst geschriebene Datei mit einer höheren Nummer hinzusetzen. Das hat gleichzeitig den Vorteil, dass die Distribution die vorhandenen Dateien bei einem Systemupdate nicht überschreibt.

Standardmäßig besteht eine Konfigurationsdatei nur aus zwei Zeilen, unter Ubuntu beispielsweise:

[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin

Hinter »AdminIdentities=« stehen alle Benutzer und Gruppen, die aus den Augen von Policykit die gleichen Rechte wie »root« besitzen. Um auch noch »klaus« unter Ubuntu in diesen elitären Kreis aufzunehmen, erzeugt Root eine neue Datei »99-klaus.conf« und legt in ihr die folgenden zwei Zeilen ab:

[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin;unix-user:klaus

Die beiden Gruppen »sudo« und »admin« stammen aus den vorhandenen Konfigurationsdateien. Man sollte sie übernehmen, da ansonsten nur noch »klaus« die »root« -Rechte besitzt.

Wenig Unterstützung

Policykit bildet eine weitere Sicherheitsschicht über dem schon vorhandenen Unix-Rechtesystem, es ersetzt es aber nicht. Darüber hinaus müssen die beteiligten Systemprogramme Policykit unterstützen beziehungsweise bei dem Dienst nachfragen. Das machen aber derzeit nur ein paar ausgewählte GUI-Werkzeuge, etwa der Network Manager.

Durchweg alle Konsolenanwendungen, etwa »apt-get« , ignorieren Policykit. Zu welchen Problemen dieser Mischmasch führen kann, zeigt der Kasten “Ausgeführt”. Doch selbst wenn eine Anwendung Policykit unterstützt, muss sie sich noch lange nicht an dessen Antwort halten. Folglich können sich Angreifer und Schadprogramme recht einfach an Policykit vorbeimogeln. Wissenswertes zu Policykit findet sich auch im Linux-User-Artikel “Türsteher” [2].

pkexec --user klaus apt-get update

pkexec apt-get update

Sowohl »sudo« als auch Policykit haben ihre Vor- und Nachteile. Sofern der Admin eine Aktion erlauben möchte, die Policykit in seinem Repertoire hat, sollte er eine entsprechende ».pkla« -Datei erstellen. Damit gibt er nur ganz gezielt die wirklich notwendige Funktion frei.

Sudo sollte ein Admin trotzdem normalen Benutzer nur nach reiflicher Überlegung oder im Notfall in die Hand geben: Zu groß ist die Gefahr, dass er durch eine fehlerhafte Regel mehr erlaubt als geplant oder sich sogar selbst vom System aussperrt.

Alternative gesucht

Ein feingranulares, einheitliches Rechtesystem vermisst man unter Linux nach wie vor. Gerade wenn der Administrator den Zugriff auf Kommandozeilenprogramme gestatten möchte, sollte er unbedingt auch einen Blick auf alternative Techniken zur Zugriffsbeschränkung werfen, beispielsweise Access Control Lists (ACL, [4]). (mhu)