summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBenjamin Franzke <benjaminfranzke@googlemail.com>2013-01-07 20:51:42 +0100
committerBenjamin Franzke <benjaminfranzke@googlemail.com>2013-01-07 21:54:30 +0100
commit43e8d51e5e1f210c7aa59484f38d0e3137d0bf30 (patch)
treec3349103da749a460f42ed500f8e98e726181e43
parent0e61c01cc025a7bab6cb3c3387816bcd3e4c8228 (diff)
downloadsksys-43e8d51e5e1f210c7aa59484f38d0e3137d0bf30.tar.gz
sksys-43e8d51e5e1f210c7aa59484f38d0e3137d0bf30.tar.bz2
sksys-43e8d51e5e1f210c7aa59484f38d0e3137d0bf30.zip
doc: Describe weston architecture
-rw-r--r--document.asciidoc48
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