Vorgedanken

Jedes UML sollte unter einer eigenen Nutzer-ID laufen - also keinesfalls als root-Prozess.

Auf die Daten- und System-Images hat jeweils nur dieser Nutzer Zugriff.

Dies würde simplerweise folgendermaßen aussehen:

su - UMLUSER /uml/kernel/stable ubd0=SYSIMAGE ubd1=DATAIMAGE daemon,,unix,UMLNET_SOCKET

Die Nutzer müssen in der Gruppe uml-net sein, damit sie den gemeinsamen Netzwerk-Socket, der vom uml_switch-Daemon verwaltet wird, nutzen können.

User-Mode-Linux wurde jedoch nicht vorrangig unter Sicherheitsaspekten entwickelt. Es bietet also eine gute, aber nicht ausreichende Sicherheit.

Eine chroot-Umgebung schützt das Host-System zusätzlich vor einem potentiellen UML-Eindringling.

Die folgenden Schritte stammen von http://uml.harlowhill.com/index.php/Chroot.

Verzeichnis-Struktur

Die chroot-Umgebung wird unter /uml/chrootjail/ liegen.

Im Unterverzeichnis guests befinden sich die Verzeichnisse der einzelnen User-Mode-Systeme.

Jedes dieser Verzeichnisse hat folgenden Inhalt:

UMLNAME-sys.img: das Betriebssystem-Abbild
UMLNAME-data.img: das Daten-Abbild
uml-UMLNAME: ein Link auf den verwendeten Kernel (sinnvoll, damit die Prozesse ver UMLs unterscheidbare Namen tragen)
.ssh: Schlüssel, authorized_keys und known_hosts

Rechte und Besitzer

Jedes UML-Verzeichnis gehört root und der Gruppe uml-net mit den Rechten 0710.

Die Daten- und System-Abbilder gehören dem UML-Nutzer und sind nur ihm zugänglich (0600).

Die ssh-Dateien id_rsa und id_rsa.pub gehören dem UML-Nutzer, jedoch ohne Schreibrechte (0400) - naja - vielleicht hilft's

Die übrigen Dateien und Verzeichnisse gehören root.

Externe Dateien

Für das UML in der chroot-Umgebung werden nur wenige Dinge benötigt:

/proc/mm: Zum Zugriff auf den Arbeitsspeicher
/proc/cpuinfo: wohl vor allem für ältere UML-Kernel nötig
/dev/net/tun: das Netzwerk-Device
/tmp: Terminals benötigen temporäre Dateien
/net-socket/uml-net.sock: der Socket des uml_switch-Daemon
/vmlinuz: der Kernel (er muss statisch kompiliert sein - also beispielsweise der debian-User-Mode-Kernel)

Einrichtung

einmalig

{{{mkdir /uml/chrootjail cd /uml/chrootjail mkdir -p dev/net proc net-socket tmp cp /proc/cpuinfo proc touch proc/mm (sonst klappt das mount-bind nachher nicht) mknod dev/net/tun c 10 200 chown -R root. . chgrp uml-net . dev/net/tun net-socket chmod 177 tmp chmod 660 dev/net/tun chmod 770 net-socket cp /usr/bin/linux vmlinuz }}}

bei jedem Booten des Hosts

mount --bind /proc/mm /uml/chrootjail/proc/mm

Starten eines UML

Um gleichzeitig die Nutzer-ID zu wechseln und eine chroot-Umgebung zu erzeugen, gibt es beispielsweise folgende Programme:

Zum Starten verwenden wir das Skript /uml/scripts/starte_uml_guest.sh. Der einzige Parameter ist der Name des User-Mode-Systems.

Was fehlt?

Erzeugung ausführbarer Dateien

im /tmp/-Verzeichnis können Dateien ausgeführt werden (http://uml.harlowhill.com/index.php/Chroot zeigt, wie mensch dies verhindern kann)
derzeit können die UML-Nutzer noch in dem Verzeichnis net-socket schreiben - dies ist erforderlich, damit der uml_switch-Daemon dort den Socket erzeugen kann
allgemein wäre es gut, wenn die UML-Nutzer nicht die Partition durch das Anlegen großer Dateien zumüllen könnten

getrennte chroot-Umgebungen

Zur weiteren Isolierung der UML-Gastsysteme voneinander, wäre es sinnvoll, getrennte chroot-Umgebungen anzulegen. Allerdings würde dies sehr viele mount-Prozesse (für /proc/mm und den Netzwerk-Socket) erfordern.