Gruppe 4-b: polkitd verweigert die Mitarbeit
polkitd – eine Einführung
Damit auf einem Rechner nicht alles drunter und drüber geht, gibt es unter
jedem vernünftigen Betriebssystem die Trennung von Privilegstufen zwischen
Nutzer- und Systemprozessen.
Während erstere im Auftrag des Benutzers agieren und direkt von diesem
gesteuert werden können, werden letztere im Auftrag des Systems tätig und haben
mit den Aktionen des Benutzers höchstens mittelbar etwas zu tun, doch es kann
trotzdem vorkommen, daß unprivilegierte mit privilegierten Prozessen
kommunizieren müssen.
Dies kann je nach der auszuführenden Aktion vergleichsweise harmlos sein, was
es rechtfertigt, den Zugriff zu erlauben, doch ab und an kann es passieren, daß
eine kritische Aktion angefordert wird. Gerade in einem solchen Fall ist es
wichtig, daß diese Aktion nicht einfach ausgeführt wird, da sonst ein jeder
Nutzer beispielsweise einfach Programme installieren oder deinstallieren
könnte, mit möglicherweise fatalen Folgen.
Hier greift dann der polkitd ein und entscheidet
anhand von vorher festgelegten Regeln, welche Zugriffe erlaubt und welche
verboten sind respektive welche von Dritten freigegeben werden müssen. Doch
manchmal ergeben sich Situationen, in denen polkitd
einen Zugriff abwürgt, dem im Normalfalle hätte stattgegeben werden können.
In diesem Fall ist es erforderlich, in den Regelsatz einzugreifen.
Diese Regelsätze lassen sich an zwei Orten wiederfinden:
- /usr/share/polkit-1
- /etc/polkit-1/rules.d
Diese können sowohl vom polkitd auszuführende Skripte
als auch XML-Dateien sein, die dem Daemon den aktuell gültigen Regelsatz
mitteilen, und je nach vorliegender Distribution kann es erforderlich sein, auf
ein bestimmtes Verzeichnis zuzugreifen, um die Sicherheitseinstellungen zu
ändern.
Bei openSuSE haben Sie beispielsweise im Verzeichnis
/etc/polkit-1/rules.d Erfolg, während Sie unter
Debian beispielsweise die XML-Dateien unter
/usr/share/polkit-1/actions anpassen müssen.
Das einzige Problem unter openSuSE ist, daß die Regeln äußerst kryptisch
anmuten, und die Anordnung der Berechtigungen erscheint kontraintuitiv (in den
Arrays ist der letzte der drei Werte für aktive Nutzer – der erste Wert legt
die Berechtigungen für alle sonstigen Nutzer fest).
Für jede der drei Nutzerkategorien (aktiv, inaktiv und sonstige) können Sie
festlegen, wie polkitd reagieren soll:
Regel | Bedeutung |
---|---|
no | Lehne die Aktion ab. |
yes | Lasse die Aktion zu. |
auth_self | Frage nach dem Passwort des Benutzers, bevor die Aktion gestattet wird. |
auth_self_session | Frage nach dem Passwort des Benutzers, bevor die Aktion gestattet wird. Das Passwort für die aktuelle Sitzung merken. |
auth_self_keep | Frage nach dem Passwort des Benutzers, bevor die Aktion gestattet wird. Das Passwort über einzelne Sitzungen hinweg merken. |
auth_admin | Frage nach dem Superuser-Passwort, bevor die Aktion gestattet wird. |
auth_admin_session | Frage nach dem Superuser-Passwort, bevor die Aktion gestattet wird. Das Passwort für die aktuelle Sitzung merken. |
auth_admin_keep | Frage nach dem Superuser-Passwort, bevor die Aktion gestattet wird. Das Passwort über einzelne Sitzungen hinweg merken. |
Wenn ein Programm also unvermittelt die Mitarbeit verweigert, so empfiehlt es sich, in den Berechtigungen nachzuschauen, was da wie eingestellt ist und die Einstellungen im Bedarfsfalle anzupassen. Danach müssen Sie polkitd nur noch anweisen, die neuen Einstellungen einzulesen.
- Öffnen Sie ein Terminal und melden Sie sich als root an.
- Wechseln Sie in das Verzeichnis /etc/polkit-1/rules.d.
- Kopieren Sie die Datei 90-default-privs.rules nach 10-local.rules.
- Laden Sie die Datei 10-local.rules in Ihren Editor.
- Suchen Sie dort nach den Einträgen, die sich auf den Prozeß beziehen, der scheinbar verrückt spielt, und löschen Sie ggf. die restlichen Einträge.
- Passen Sie die dort gesetzten Regeln an Ihren Bedarf an.
- Speichern Sie die Datei.
Wenn Sie später noch Regeln anpassen müssen, so kopieren Sie das, was verändert werden muß, aus der Datei 90-default-privs.rules in 10-local.rules und passen Sie diese geeignet an. So bleiben Ihre Regeln auch dann erhalten, wenn polkitd aktualisiert und die Datei 90-default-privs.rules in dem Zuge überschrieben wird.
Aufgepaßt!
Überlegen Sie sich genau, welche Zugriffsberechtigungen Sie wie anpassen! Auch
wenn es mehrere Einträge für einunddenselben Prozeß gibt, so ist es nicht
zielführend, einfach wahllos alles azupassen, da jeder Eintrag sich auf
unterschiedliche Zugriffsberechtigungen desselben Prozesses bezieht!
Es ergibt beispielsweise keinen Sinn, eine Zugriffsberechtigung auf den
Konfigurationsdialog für Netzwerkverbindungen zuzulassen, wenn Sie einem Nutzer
lediglich erlauben wollen, eingerichtete Netzwerkverbindungen aktivieren und
wieder trennen zu können. Zudem können Sie, wenn Sie Zugriffe an den falschen
Stellen erlauben, eine Menge Schaden anrichten, da so jeder beliebige Nutzer
unkontrolliert im System herumfuhrwerken kann!
Hier ist dann weniger mehr, und wenn Sie Zweifel haben, dann geben Sie den
Zugriff auf die gewünschte Ressource nicht ungeprüft frei, sondern koppeln die
Freigabe an die erfolgreiche Eingabe des Superuser-Passwortes, o. ä.!
Wenn Sie die notwendigen Einstellungen vorgenommen haben, so starten Sie den polkitd einfach neu: systemctl restart polkitd.service
nach obenNetworkManager läßt sich nicht steuern
Melden Sie sich lokal auf einem Rechner an, so funktioniert NetworkManager ganz wie gewohnt: Wenn Sie sich an einem anderen Netzwerk – meist ein Funknetzwerk – anmelden wollen, so wählen Sie es einfach an, und NetworkManager erledigt den Rest für Sie.
Wenn Sie sich über XDMCP anmelden, so sollte das ja ähnlich funktionieren –
könnte man meinen.
Doch weit gefehlt! Wenn Sie sich in einem anderen Netzwerk anmelden wollen, so quittiert
NetworkManager dies mit dem lapidaren Kommentar, daß der Vorgang nicht erlaubt
wäre.
Jetzt könnte man meinen, daß NetworkManager hier verrückt spielt, wenn man sich
übers Netzwerk anmeldet, doch dem ist nicht so. In diesem Fall spielen einem
die Sicherheitseinstellungen des polkitd einen
Streich, was gerade beim Zugriff auf VPNs zu einem Problem wird.
Zwar ist es richtig, daß beispielsweise kabelgebundene Verbindungen gegen
versehentliches Trennen geschützt werden sollen, damit der entfernte Rechner
erreichbar bleibt, doch ist so kein Zugriff auf ein VPN möglich, und wenn man
die VPN-Verbindung nicht ständig geöffnet haben möchte, so ist das direkte
Starten des jeweiligen VPN-Daemons keine Option. Also ist es erforderlich, die
Sicherheitsbeschränkungen des polkitd derart zu
lockern, daß man eine Netzwerkverbindung nicht versehentlich trennen kann, aber
ein Zugriff auf z. B. ein VPN ermöglicht wird, wenn man das richtige Passwort
(meist das des Systemverwalters) eingibt. So haben Sie immer noch die Zeit zu
reagieren, wenn Sie feststellen, daß Sie die falsche Verbindung erwischt haben
und brauchen den Vorgang nur abzubrechen, und wenn Sie die richtige Verbindung
ausgewählt haben, so bestätigen Sie den Vorgang einfach mit dem
root-Passwort.
Die alles entscheidende Frage hierbei ist jedoch, welche der Einstellungen für
den NetworkManager jetzt überhaupt anzupassen sind, damit alles reibungslos
läuft. Hier hilft Ihnen folgender Befehl weiter:
cat /etc/polkit-1/rules.d/90-default-privs.rules | grep
-A 1 NetworkManager.
Mit dem Kommando cat können Sie sich den Inhalt
einer Datei anzeigen lassen. Für uns ist hier die Datei mit den Defaultwerten
von Interesse, weshalb wir deren Inhalt ausgeben lassen.
Da wir jedoch nicht den kompletten Wust haben wollen, lassen wir uns lediglich
die passenden Einträge nebst den zugehörigen Einstellungen anzeigen. Dies
erledigt das Werkzeug grep für uns, indem es die
Ausgabe von cat anhand eines
regulären Ausdrucks
auswertet und die passenden Stellen anzeigt.
Für uns ist hier lediglich eine einzige Einstellung von Interesse, die mit dem
Bezeichner
org.freedesktop.NetworkManager.network-control
versehen ist. Suchen Sie nach dieser Zeichenkette und schauen Sie sich die
Zeile direkt im Anschluß an. Hier erkennen Sie folgende Werte:
[ 'no', 'no', 'yes' ].
Dies sorgt dafür, daß nur lokal angemeldete Benutzer mit aktiver Sitzung die
lokalen Netzwerke steuern können. Allen anderen Benutzern wird diese
Berechtigung schlichtweg verweigert.
Dies ist für unsere Zwecke jedoch nicht akzeptabel, von daher ändern Sie diese
wie folgt ab: [ 'auth_admin', 'auth_admin', 'yes' ].
Nachdem Sie den polkitd neugestartet haben, können
Sie zukünftig die bestehenden Verbindungen nutzen, auch wenn Sie über XDMCP
angemeldet sind. Sie werden in diesem Fall jedoch nach dem Passwort des
Systemverwalters (aka. root) gefragt, um die Aktion
zu bestätigen. Bei erfolgreicher Bestätigung wird diese dann ausgeführt.
Vorsicht!
Trennen Sie unter gar keinen Umständen die physikalische Netzwerkverbindung, wenn Sie von einem entfernten Rechner aus angemeldet sind! Sie sägen somit den Zugriff über das Netzwerk ab, und jemand muß sich erst einmal lokal anmelden, um die Netzwerkverbindung wieder gangbar zu bekommen – oder wenn das nicht möglich ist, ist stattdessen ein Neustart des betroffenen Rechners notwendig. Deshalb ist es sinnvoller, die Eingabe eines Passwortes zu fordern, da Sie so die Chance haben, den Vorgang abzubrechen, wenn Sie feststellen, daß Sie die falsche Verbindung erwischt haben.