Ob im Unternehmen mit Hunderten von Arbeitsplätzen oder einfach nur zu Hause als Kindersicherung – Nutzerrechte auf dem Desktop einzuschränken ist oft ein wichtiges Anliegen. Mit KDE geht das ganz einfach.

Wer nach einer angepassten und verwüstungsfesten Oberfläche gefragt wird, bekommt meist zur Antwort, er möge doch den FVWM nehmen und konfigurieren. Doch zum einen bietet dieser Windowmanager längst nicht alle Features, die man auf modernen Desktop-Arbeitsplätzen erwartet – einfache Konfiguration eingeschlossen –, zum anderen wünscht man sich oft nicht nur einen Windowmanager, sondern eine integrative Desktop-Umgebung wie KDE. Doch das hohe Maß an Anpassbarkeit, sonst ein Stärke von KDE, ist hier natürlich fehl am Platz.

Gefragt ist stattdessen eine Lösung, bei der der Benutzer ohne monatelanges Dokumentationsstudium Einschränkungen vornehmen und individuelle Applikationen bis ins letzte Detail absichern kann. Seit KDE 3.1 existiert dafür eine ebenso einfache wie effiziente Lösung, der die KDE-Entwickler den Namen “Kiosk-Modus” verpassten, denn das ursprüngliche Einsatz-Szenario war ein Internet-Kiosk, beispielsweise in einem Internet-Cafe. Dabei reichen die Möglichkeiten vom manipulationssicheren Bildschirmhintergrund bis hin zum Verbot ganzer Programme.

Ein Leichtes

Damit die Einstellungen tatsächlich einfach zu konfigurieren sind, schrieb Waldo Bastian, der geistige Vater und Hauptentwickler des Kiosk-Modus, eine grafische Administrationsoberfläche namens “Kiosk Tool” [1]. Deren Funktionsweise entspricht in etwa der des Policy Editor unter Windows: Bestimmte Möglichkeiten des KDE-Desktops – etwa das Setzen des Hintergrundbilds oder das Ausführen von Programmen – lassen sich mit ihm einschränken. Suse-9.1-Benutzer sollten nicht das mitgelieferte Paket installieren, sondern auf die Heft-CD zurückgreifen oder ein aktuelles RPM von der Kiosk-Webseite beziehen (Kasten 1).

yast -i kiosktool-0.5-3.i586.rpm

./configure && make && make install

Nach dem ersten Start legt Kiosk Tool bei Anwahl des Buttons Add New Profile auf der Startseite ein Profil an, welches hinterher in der Datei /etc/kderc (bei Suse /etc/kde3rc) vermerkt wird. Darin finden sich grundsätzliche Informationen zu KDE wie der Installationspfad.

Zunächst aber versucht es, einen Namen und eine Kurzbeschreibung (Short description:) für das neue Profil zu erfahren. Beide Angaben so treffend wie möglich zu gestalten lohnt sich, will man später den Überblick nicht verlieren.

Außerdem sollte man statt des vorgegebenen Installationsverzeichnisses profile1 unterhalb von /etc/kde-profile einen sinnvolleren Verzeichnisnamen wählen, denn auch dieser begegnet einem später wieder. Da das Programm hier auf das nur für root schreibbare Verzeichnis /etc zurückgreift, fragt es abschließend nach dem root-Passwort. Ein Klick auf Next legt das neue Profil an; daraufhin erscheint eine Komponenten-Ansicht (Abbildung 1).

Abbildung 1: Die Einschränkungsmöglichkeiten sortiert Kiosk Tool nach Themen.

Sie erlaubt es, die zu konfigurierenden Regeln nach Kategorien auszuwählen. So bietet z. B. Theming Einschränkungsmöglichkeiten für das visuelle Erscheinungsbild des Desktops, General kümmert sich um Restriktionen, die die Arbeitsoberfläche als solche betreffen, und Menu Actions legt fest, welche Menüeinträge der Benutzer nicht zu sehen bekommen soll.

Ein Klick auf den Next-Button (oder einer auf das jeweilige Icon) führt zu einer Liste anwählbarer Einschränkungen, die auf die markierte Kategorie zutreffen. Den jeweils aktiven Einstellungspunkt erläutert eine Infobox unterhalb der Liste (Abbildung 2).

Abbildung 2: Die Kategorie “Menu Actions” erlaubt es, bestimmte Menüpunkte aus den KDE-Applikationen der Benutzer zu verbannen.

Einige Aktionen bringen sogar eine Vorschau mit: Wählt man z. B. in KDE Menu die Aktion Disable menu editing an, so bringt der Button Preview KDE Menu einen K-Button zum Vorschein, in dessen Kontext-Menü der Menu Editor-Eintrag fehlt (Abbildung 3). Leider ist die Vorschau-Funktion in der getesteten Version 0.5 noch anfällig für Hänger und Abstürze, und Nutzer weniger leistungsstarker Rechner werden auf eine Geduldsprobe gestellt.

Abbildung 3: Die Vorschau-Funktion zur Regel “Disable menu editing” zeigt, dass ein rechter Mausklick auf den Start-Menü-Knopf (hier bei Suse) den Menü-Editor-Eintrag vermissen lässt.

Ist man am Ende mit seinen Einstellungen zufrieden, so führt zweimaliges Anwählen des Back-Knopfs zurück in den Profile Selection-Hauptdialog, wo es nun an die Zuweisung der Profile zu den Benutzern geht.

Abbildung 4: Arbeit macht das Erstellen der Profile – das Zuweisen geht hingegen ganz einfach.

Für jeden etwas

Zu diesem Zweck klickt man auf den “Manage users…“-Knopf und darf nun für Unix-Benutzer oder -Gruppen jeweils ein Profil festlegen. Im Falle eines einzelnen Anwenders geht dies über den “Add User Policy…“-Button. Einmal angeklickt, erscheint ein Dialog wie in Abbildung 4, in dem man einen Usernamen und das gewünschte Profil auswählt.

Soll eine ganze Gruppe dasselbe Profil bekommen, verfährt man mit Add Group Policy analog. Diese Einstellungen werden beim nächsten KDE-Start für den jeweiligen Benutzer aktiv. Alle Profilzuweisungen speichert das Kiosk Tool in /etc/kde-user-profile.

Achtung: Wer KDE 3.2.2 einsetzt, muss auf jedem Fall die Zeile

export KDEDIRS=$(kiosktool-kdedirs)

am Anfang des KDE-Startskripts $KDEDIR/bin/startkde ergänzen, wobei $KDEDIR zumeist /opt/kde3 (Suse) oder /usr (Debian, Fedora) ist. KDE 3.2.3 benötigt diesen Zusatz nicht mehr.

Feintuning

Doch die Kiosk-Technologie endet nicht an den Grenzen des Kiosk-Tools. Als inhärenter Bestandteil von KDE erlaubt sie es, jede Applikation individuell anzupassen. Dabei gilt die Grundregel: Alles, was über eine von KDEs Konfigurationsdateien erreichbar ist, beugt sich den Wünschen des Administrators.

Für KDE-Anwendungen gibt es mindestens zwei Konfigurationshierarchien nebeneinander: Mit Hilfe der systemweiten Einstellungen, die unterhalb des Verzeichnisses /opt/kde3 (Suse) oder gemeinsam mit allen anderen Programmen unter /usr (Fedora, Debian) liegen, gibt der Administrator Konfigurationswerte für alle Benutzer des Systems vor. Die darin enthaltenen Dateien und Verzeichnisse können nichtprivilegierte User nicht ändern. Sollen die Einstellungen nur für gewisse Gruppen gelten, passt der Administrator alternativ Dateien in einem vorher mit dem Kiosk Tool erstellten Profil-Verzeichnis an.

Für individuelle Vorlieben und private Daten zuständig ist das Unterverzeichnis .kde im Home-Directory eines jeden Benutzers, falls die UmgebungsvariableKDEHOME nichts anderes behauptet. Hier landen all die Einstellungen, die der Benutzer selbst über die Oberfläche festlegt oder verändert.

Über die Umgebungsvariable KDEDIRS oder durch einen Eintrag in der Datei /etc/kde(3)rc lassen sich aber weitere Verzeichnisbäume einbeziehen. Mit dieser Methode fügt auch das Kiosk Tool Profile zwischen globaler und lokaler Ebene ein.

Das Wasser abgraben

Doch wie verhindert der Administrator nun, dass der Benutzer gewisse Einstellungen verändert? Bestimmte Aspekte der Benutzeroberfläche systemweit auszublenden funktioniert nur solange, wie der Benutzer keine Kenntnisse über das oben beschriebene private Konfigurationsverzeichnis hat, und ist somit allenfalls als Zusatz geeignet. Deswegen realisiert KDE den Schutz auf unterster Ebene: Beim Einlesen der Konfigurationsdateien, die im INI-Format gehalten sind, lassen sich spezielle Attribute in eckigen Klammern angeben. [$i] steht hierbei für “immutable” (unveränderlich) und besagt, dass KDE den so bezeichneten Wert in der Konfigurationsdatei des Benutzers ignorieren wird – egal, was der individuell wünscht. Um einen Eintrag zu schützen, fügt man das Attribut wie in Listing 1 direkt vor dem Gleichheitszeichen ein.

[Background Common]
CommonDesktop[$i]=true
[Desktop0]
CurrentWallpaper[$i]=0
MultiWallpaperMode[$i]=NoMulti
Wallpaper[$i]=/opt/kde-cvs/share/wallpapers/default_blue.jpg
WallpaperMode[$i]=Scaled

Dieses Beispiel erzwingt die Anzeige des Hintergrundbilds /opt/kde-cvs/share/wallpapers/default_blue.jpg auf allen (CommonDesktop=true) virtuellen Desktops, unabhängig davon, was der Benutzer für sich konfiguriert. Da sich mit einem Bild schlecht eine Dia-Show auf dem Desktop-Hintergrund veranstalten lässt, steht MultiWallpaperMode auf NoMulti; Scaled skaliert die “Tapete” bildschirmfüllend.

Jeden Eintrag einzeln zu markieren ist sehr mühsam und oft, so auch in Listing 1, unnötig. Arbeit spart ein Gruppenattribut, das eine ganze Gruppe schützt: Man fügt es wie in Listing 2 der schließenden eckigen Klammer eines Gruppenbezeichners an.

[Background Common][$i]
CommonDesktop=true
[Desktop0][$i]
CurrentWallpaper=0
MultiWallpaperMode=NoMulti
Wallpaper=/opt/kde-cvs/share/wallpapers/default_blue.jpg
WallpaperMode=Scaled

Wichtig zu beachten ist hierbei, dass dies alle Attribute der Gruppe schützt, nicht nur die vom Administrator explizit aufgeführten. In Listing 2 ist das kein Problem, da man sich so auch vor Veränderung von Eigenschaften wehrt, die man nicht bedacht hat. Doch kann es vorkommen, dass man dem Nutzer mehr Rechte entzieht als gewünscht.

Das Problem verdeutlicht auch Listing 3: Alleinstehend in der ersten Zeile einer Konfigurationsdatei eingetragen, bewirkt das immutable-Flag den Schutz der gesamten Datei vor lokalen Änderungen. Diese werden zwar durchaus geschrieben, aber schlichtweg nicht eingelesen.

[$i][…]
[Background Common]
CommonDesktop=true[…]
[Desktop0]
CurrentWallpaper=0
MultiWallpaperMode=NoMulti
Wallpaper=/opt/kde-cvs/share/wallpapers/default_blue.jpg
WallpaperMode=Scaled[…]

Ein weiteres sehr nützliches Attribut für Einträge ist [$e] (“evaluate”, auswerten). Damit weist KDE der Eigenschaft den Rückgabewert eines Shell-Ausdrucks, also den Inhalt einer Umgebungsvariablen oder eine Programmausgabe, zu. Natürlich lassen sich auch diese Einträge vor Benutzerveränderung schützen, indem beide Attribute zu [$ie] zusammengeführt werden.

Soll z. B. das Hintergrundbild in Listing 2 aus einer Umgebungsvariablen namens USERSWALLPAPER gelesen werden, lautet die Wallpaper[Desktop0]

Wallpaper[$e]=$USERSWALLPAPER

Die Variable muss dem System natürlich vor dem KDE-Start bekannt sein, z. B. dank ihrer Definition im kdeinit-Skript aus dem Verzeichnis $KDEHOME/bin.

Möchte man den Wert dynamisch von einem Shell-Skript bestimmen lassen, das ihn bei seiner Ausführung mit echo zurückgibt [4], so lautet die Zeile

Wallpaper[$e]=$(/pfad/zum/skript.sh)

Kein Anschluss unter dieser URL

Sogar die Netz-Nutzung lässt sich mit dem Kiosk-Modus beschränken: Will man erreichen, dass der Filius im Internet nur seine Mails abrufen und bei Wikipedia seine Hausaufgaben recherchieren kann, greift man zum “Whitelisting”, das bestimmte Seiten zulässt, oder sperrt lediglich gewisse Sites. Während Unternehmen solche Verbote am besten über einen Zwangsproxy realisieren, wirkt dies für den Hausgebrauch wie mit Kanonen auf Spatzen geschossen.

Neben Web-Angeboten macht KDE bei Bedarf auch gewisse Teile der lokalen Verzeichnishierarchie unzugänglich. Redirect-Regeln ermöglichen es zudem, bestimmten Webseiten z. B. im Intranet Zugriff auf Bereiche der lokalen Festplatte zu geben, den KDE gewöhnlich aus Sicherheitsgründen nicht gewährt.

Ein Beispiel zeigt Listing 4: Zunächst verbietet es sämtliche Zugriffe mit rule_1, danach öffnet es das Home-Verzeichnis des Benutzers und den Ordner für temporäre Dateien (rule_2 und rule_3). Im World Wide Web erlaubt es das Ansurfen aller Seiten der Wikipedia und von gmx.de. Ein leeres Feld (also ein Nichts zwischen zwei Kommata) fungiert als Platzhalter für alle möglichen Werte. Leider gibt es für dieses sehr nützliche Feature bislang keinen grafischen Editor. Wer sich davon nicht abschrecken lässt, findet unter [3] Details.

[KDE URL Restrictions]
rule_count=5
rule_1=open,,,,,,,false
rule_2=open,,,,file,,$HOME,true
rule_3=open,,,,file,,$TMP,true
rule_4=open,,,,http,,http://*.wikipedia.*,true
rule_5=open,,,,http,,http://*.gmx.de,true

Einer für alle – alle für einen

Jede KDE-Applikation liest vor ihrer eigenen Konfigurationsdatei auch immer die Datei kdeglobals aus dem Verzeichnis $KDEDIR/share/config aus. Administratoren von Abteilungen, die über mehrere Drucker verfügen, legen mit ihrer Hilfe z. B. fest, dass jedes Programm immer den Drucker auswählt, der dem Rechner am nächsten steht:

[KPrinter Settings]
Printer[$ei]=$(/usr/local/bin/evallocalprinter)

Das Shellskript /usr/local/bin/evallocalprinter muss allerdings selbst geschrieben werden und den korrekten Drucker per echo zurückgeben. Zur Entscheidungsfindung innerhalb des Skripts kann z. B. die Abfrage eines LDAP-Servers dienen.

Gedämmter Aktionismus

kdeglobals lässt sich aber auch elegant zu Rate ziehen, wenn man zum Beispiel das Aussehen der Werkzeugleisten nicht für jedes Programm einzeln festlegen möchte. In diesem Fall definiert man hier zentral, wie die Toolbars aussehen.

Einträge in Werkzeug- und Menüleisten werden bei KDE als Aktionen bezeichnet. Man kennt sie aus den Dialogen, die die Anwahl des Menüpunkts EinstellungenWerkzeugleiste einrichten… bei vielen KDE-Applikationen auf den Bildschirm bringt. Oft ist es wünschenswert, gewisse Aktionen nicht anzubieten. Auf alle KDE-Applikationen bezogene Einschränkungen konfiguriert man mit dem Kiosk Tool (Abbildung 2), geht es hingegen nur um spezielle Aktionen in Einzelanwendungen, ist Handarbeit gefragt.

Eine Übersicht über alle Aktionen, die ein gerade laufendes KDE-Programm anbietet, erhält man direkt vom lebenden Objekt. Welche Applikationen momentan laufen, verrät das Programm kdcop [5,6] (Abbildung 5). Mit der Information ausgestattet, dass gerade ein konqueror-20499 aktiv ist, sucht das Kommando

dcop konqueror-20499 qt objects | grep KActionCollection | cut -d'/' -f3

mit grep KActionCollection alle Konqueror-Aktionsobjekte aus. Der cut-Befehl beschränkt die Ausgabe auf das Wesentliche, nämlich auf die Namen der Aktionen.

Abbildung 5: kdcop verrät, welche KDE-Applikationen gerade laufen.

Jetzt sind Englisch-Kenntnisse und ein wenig Phantasie gefragt: In der langen Ausgabeliste findet sich u. a. der Eintrag saveDocument. Ihn gibt es nur, wenn Konqueror als Webbrowser läuft; dass er dem Menüpunkt Dokument | Speichern unter… entspricht, kommt spätestens dann heraus, wenn man ihn zu deaktivieren sucht. Dazu trägt man in die Konqueror-spezifische systemweite Konfigurationsdatei konquerorrc im Verzeichnis $KDEDIR/share/config/ folgende Zeilen ein:

[KDE Action Restrictions][$i]
action/saveDocument=false

(Existiert die Datei nicht, legt man sie an.) Nach einem KDE-Neustart ist der Menüeintrag verschwunden.

Soll das Abschalten einer Aktion alle KDE-Applikationen betreffen, fügt man Entsprechendes in der Datei kdeglobals im gleichen Verzeichnis ein. Pro Aktion kommt eine Zeile der Form

action/name=false

hinzu. Weitere Restriktionen lassen sich unter der Überschrift [KDE Action Restrictions] setzen; Tabelle 1 führt sie auf.

Sicherheit: ja, absolute Sicherheit: nein

Damit eignet sich der KDE-Kiosk-Mechanismus hervorragend für Anpassungen aller Art, auch wenn seine Stärken bislang noch in die Tiefe der Kommandozeile führen. Doch bedeutet sein Einsatz keineswegs die Lösung aller (Sicherheits-)Probleme auf dem Linux-Desktop. Selbst wenn man das Ausführen von Programmen und das Starten der Shell verbietet, finden umtriebige Zeitgenossen mit Nicht-KDE-Programmen schnell Umgehungsmöglichkeiten. Ein Paradebeispiel ist der Druckdialog eines alten Netscape-Browsers. Hier kann man als Druckkommando statt lpr ebensogut xterm angeben – schon kommt der Nutzer zu einem Kommandozeilenfenster.

Wer absolute Sicherheit will, kommt um die Verwendung einer entsprechenden Kernel-Erweiterung nicht herum, denn nur der Betriebssystemkern entscheidet letztlich, was ausgeführt werden darf und was nicht. Dennoch reicht der Kiosk-Modus für die meisten Fälle vollkommen aus und hilft dem erfahrenen Administrator genauso wie Eltern, die nur den Zugang für ihre Kinder beschränken wollen. Wer dabei Hilfe benötigt, wendet sich bei Bedarf an die KDE-Kiosk-Mailingliste [3].