diff options
| -rw-r--r-- | document.asciidoc | 48 |
1 files changed, 47 insertions, 1 deletions
diff --git a/document.asciidoc b/document.asciidoc index f6c35c8..2a9e28e 100644 --- a/document.asciidoc +++ b/document.asciidoc @@ -143,7 +143,53 @@ unterschiedlichen Berechtigungen aufgeteilt. Das Ziel dabei ist es, den Programmcode mit so wenig Rechten wie moeglich ausführen zu lassen. - +Als Beispiel sei der Window-Compositer Weston genannt, der im Rahmen des +Wayland-Projektes implementiert wird. +Das Programm besteht aus dem Programm ``weston-launch'' und dem eigentlichen +Hauptprogramm ``weston''. +Der Compositor behandelt in seiner Hauptaufgabe das Darstellen der +Anwendungsfenster mit Hilfe der Grafikkarte, so wie das Einlesen und +Verarbeiten von Nutzereingaben über Eingabegeräte. +Das Ziel ist es, den Compositor ohne Root-Rechte laufen zu lassen. + +Das Öffnen von Eingabegeräten zum Einlesen bedarf Root-Rechte, damit nicht ein +beliebiges Programm -- in der Funktion eines Keyloggers -- die Nutzereingaben, +wie z.B. Passwörter, unauthorisiert lesen kann. +Für Eingabegeräte reicht die Privilege-Revocation nicht aus, denn durch +Hotplug Funktionalität können zur Laufzeit neue Eingabegeräte hinzukommen. +Das Gerät muss außerhalb der Initialisierungsphase mit Root-Rechten geöffnet +werden. +Desweiteren ist es beim Linux Kernel-Mode-Setting nötig, dass zur Laufzeit ein +Master für die Grafikkarte gesetzt wird, wenn ein VT-Switch auftritt. +Der Compositor agiert als ein solcher Master, wenn er aktiv ist. +Gefordert ist also ein Mechanismus, um ausgewählte begrenzte Operationen +zuzulassen: +Das Startprogramm ``weston-launch'' ist ein mit Root-Rechten gestartetes +Vorprogramm für das Hauptprogramm ``weston''. +Es erstellt einen Unix-Domain-Sockets, der den Kommunikationskanal bildet. +Dieser ist die Grundlage für den erwähnten Mechanismus. +Es startet anschließend weston mit eingeschränkten Rechten (Nutzer-Rechte) +und übergibt beim Start den Deskriptor für den Kommunikationskanal. + +Wenn nun zur Laufzeit weston ein Eingabe-Hotplug-Ereignis erhält +und das Gerät öffnen möchte, so nutzt weston nicht -- wie andere Programme -- +open(2), denn um das Gerät direkt zu Öffnen fehlen die Rechte. +Stattdessen wird eine Nachricht über den Kommunikationskanal gesendet, +die mit einem OpCode beschreibt, dass ein Gerät geöffnet werden soll, +und als Parameter den Pfad zum Gerät, z.b. /dev/input/event0 enthält. +Weston-launch empfängt diese Anfrage und prüft, ob es ein zur Öffnung erlaubter +Pfad ist (z.B. beginnend mit /dev/input/). +Falls erlaubt, wird das Gerät geöffnet und der Deskriptor über den +Kommunikationskanal als Socket-Control-Message an ``weston'' als Antwort +übertragen. Weston erhält damit einen Deskriptor, der sich nicht +von einem durch direkten Aufruf von open(2) geöffneten unterscheidet. +// TODO: Ähnliches Szenario: DRM Set Master + +Weston läuft somit im User-Mode und kann bestimmte Operationen, +über weston-launch ausführen lassen. +Wenn eine Sicherheitslücke in Weston nun zur Ausführung von schädlichem +Programm-Code führen sollte, könnten nur die Root-Operationen ausgeführt +werden, die ``weston-launch'' erlaubt -- nicht aber alle für Root erlaubten. === Service-Separation |