From 43e8d51e5e1f210c7aa59484f38d0e3137d0bf30 Mon Sep 17 00:00:00 2001
From: Benjamin Franzke <benjaminfranzke@googlemail.com>
Date: Mon, 7 Jan 2013 20:51:42 +0100
Subject: doc: Describe weston architecture

---
 document.asciidoc | 48 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

(limited to 'document.asciidoc')

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
 
-- 
cgit 

