# &kppp; und die Sicherheit

Dieses Kapitel ist hauptsächlich für Administratoren(`root`), Leute mit hohen Sicherheitsansprüchen oder einfach technisch Interessierte. Es ist nicht notwendig, dieses Kapitel zu lesen, wenn Sie nur &Linux; für sich zu Hause laufen lassen (obwohl Sie vielleicht etwas Neues lernen könnten, wenn Sie es lesen).

## Den Zugang zu &kppp; beschränken

Ein Systemadministrator möchte vielleicht Zugang zu &kppp; auf diejenigen beschränken, denen es erlaubt ist, es zu benutzen. Es gibt zwei Wege, dies zu tun:

### Den Zugang zu &kppp; durch Gruppenrechte beschränken

Man erstellt zunächst eine neue Benutzergruppe (sie könnte ⪚ `dialout` heißen) und fügt jeden Benutzer, der &kppp; benutzen darf, zu dieser Gruppe hinzu. Dann tippt man folgendes ein:

    # chown root.dialout /opt/kde/bin/kppp
    # chmod 4750 /opt/kde/bin/kppp

Dabei wird vorausgesetzt, dass sich &kde; in `/opt/kde` befindet und die neue Gruppe `dialout` heißt.

### Den Zugang mit den Mitteln von &kppp; beschränken

Beim Start überprüft &kppp;, ob eine Datei `/etc/kppp.allow` existiert. Falls es eine solche Datei gibt, können nur Benutzer, die in dieser Datei aufgelistet sin, eine Verbindung herstellen. Diese Datei muss für jeden Benutzer lesbar sein (natürlich nicht für jeden schreibbar). Nur Benutzernamen werden erkannt, man kann also keine UID verwenden. Hier ein kurzes Beispiel:

    # /etc/kppp.allow
    # Kommentare und Leerzeilen werden ignoriert.
    #

    fred
    karl
    daisy

Im obigen Beispei dürfen nur die Benutzer `fred`, `karl` und `daisy` eine Verbindung herstellen. Außerdem darf das jeder Benutzer mit der UID 0 (daher muss root nicht explizit genannt werden).

## &kppp; hat das SUID-Bit gesetzt. Wo bleibt die Sicherheit?

Es ist realistisch gesehen nicht möglich, ein Wählprogramm ohne gesetztes SUID-Bit zu schreiben, das sicher und dabei für unerfahrene Benutzer einfach zu benutzen ist. &kppp; geht das Sicherheitsproblem mit folgender Strategie an:

- Gleich nach dem Programmstart startet &kppp; einen neuen Prozess.

- Der Masterprozess (der die GUI, Benutzerinteraktion u.ä. verwaltet) legt den SUID-Status danach ab und läuft dann mit den normalen Benutzerprivilegien.

- Der Slaveprozess behält seine Privilegien bei und kümmert sich um alles, für das man `root`-Rechte benötigt. Um diesen Teil sicher zu machen, werden hier keine Funktionen der &kde;-/&Qt;-Bibliotheken aufgerufen, sondern nur einfache Funktionen der C-Bibliothek. Der Quellcode für diesen Prozess ist kurz (etwa 500 Zeilen) und gut dokumentiert. Dadurch ist es einfach, Sicherheitslöcher zu entdecken.

- Master- und Slaveprozess kommunizieren mit standard &UNIX; IPC.

Vielen Dank an Harri Porten für das Schreiben dieses exzellenten Quelltextes. Ich dachte, es sei unmöglich - er schrieb es in einer Woche.