Sofwareentwicklung mit Qubes OS

Qubes OS ist super geeignet, um ein hohes Maß an Sicherheit für Entwicklungsumgebungen zu gewährleisten und gleichzeitig die Möglichkeit zu haben, frei von Sicherheitsbedenken neue Tools und Setups auszuprobieren. Die Nutzung von Qubes bedeutet aber nicht zwangsläufig eine Verbesserung der Sicherheit. Dazu ist ein Konzept für das Setup notwendig, welches sensible Daten vor Zugriff durch bösartige Schadprogramme schützt.

Wir versuchen, auf dieser Seite ein paar Guidelines bereit zu stellen, die für das Aufsetzen einer Entwicklungsumgebung mit Qubes hilfreich sein könnten. Dies ist keine umfassende Anleitung, wie Qubes OS zu installieren und konfigurieren ist. Hilfe zu diesem Thema finden Sie auf der Qubes Website.

Hardwareanforderungen

Durch das Konzept von entkoppelten VMs benötigt Qubes OS einiges an Ressourcen. Insbesondere sollte darauf geachtet werden, dass genügend Arbeitsspeicher zur Verfügung steht. Wir empfehlen mindestens 16 GB RAM, da beim Start von mehreren VMs hier sonst recht schnell die Luft ausgeht. Generell gilt: Je mehr RAM desto besser.

Ein zweiter, wichtiger Punkt ist die Anforderung an den Prozessor im Hinblick auf Virtualisierungstechnologien. Auf der Qubes Hardware Compatibility List finden Sie dazu weitere Informationen, sowie eine Liste von unterstützter Hardware.

Setup der Entwicklungsumgebung

Qubes nutzt das Prinzip von Template VMs als Basis für sogenannte App VMs. App VMs werden für die eigentliche Arbeit verwendet, das Root Verzeichnis mit installierter Software und Tools wird bei jedem Neustart neu von der entsprechenden Template VM übernommen. Die in der App VM benötigte Software muss also in der Template VM installiert werden. Software, die lediglich in der App VM installiert wird, ist nach eine Reboot wieder von der VM verschwunden. Gleiches gilt für Dateien, die im Root Verzeichnis erstellt worden sind. Nur Dateien, die in einem der hier aufgelisteten persistenten Verzeichnisse angelegt werden, überstehen einen Reboot. Diese Besonderheit ist beim Setup der Entwicklungsumgebung zu beachten.

Template-basierte VMs als Entwicklungsumgebung

Um die Daten unserer Kunden möglichst getrennt zu halten, erzeugen wir für jeden Kunden bzw. jedes Projekt eine eigene VM basierend auf dem passenden Basis-Template. Im Basis-Template werden allgemein benötigte Entwickler-Werkzeuge wie Git, Docker, Python, GCC, Java usw. installiert. Für die Installation verschiedener Python und Node Versionen nutzen wir virtuelle Umgebungen, die wir mit Hilfe von virtualenvwrapper (Python) bzw. nvm (Node.js) verwalten. Bei nvm ist dazu nicht einmal die Installation in der Template VM notwendig, da das Tool inklusive der virtuellen Node Umgebungen in einem der persistenten Qubes-Verzeichnisse installiert wird. virtualenvwrapper wird dagegen wie hier beschrieben in der Template VM installiert. Damit das Tool in der App VM genutzt werden kann, muss in der entsprechenden App VM die bashrc angepasst werden:

export WORKON_HOME=$HOME/.virtualenvs
source /bin/virtualenvwrapper.sh

Datenbank Setup

Beim Setup der Datenbank ist darauf zu achten, dass das Data-Verzeichnis in einem der persistenten Qubes-Verzeichnisse gelegt wird, damit die Daten nach einem Reboot der VM erhalten bleiben. Bei PostgresQL kann dies mit Hilfe der "--unit" Option konfiguriert werden. Dazu müssen folgende Commands in der Template VM ausgeführt werden:

$ sudo dnf install postgresql-server
$ sudo mkdir /usr/local/pgsql
$ sudo chown postgres /usr/local/pgsql/
$ sudo postgresql-new-systemd-unit --datadir /usr/local/pgsql/data/ --unit postgresql@local

In der App VM muss die Datenbank dann initialisiert und der Server gestartet werden:

$ sudo mkdir /usr/local/pgsql
$ sudo chown postgres /usr/local/pgsql/
$ sudo postgresql-setup --initdb --unit=postgresql@local --port 5432
$ sudo systemctl start postgresql@local.service

Nach einem Neustart der App VM ist dann lediglich der letzte Command auszuführen, um den Datenbank-Server zu starten:

$ sudo systemctl start postgresql@local.service

Standalone VM als Sandbox

Um beim Testen von neuen Tools und Konfigurationen ein Zumüllen oder eine Gefährdung der Entwicklungsumgebungen zu verhindern, starten wir für diesen Fall eine Standalone VM, die auf dem Template der Entwicklungs-VMs basiert. Damit sind alle Standard-Tools aus den Entwicklungs-VMs verfügbar, Änderungen in der Sandbox haben aber keinerlei Auswirkung auf das Template der Entwicklungs-VMs und damit auch keine Auswirkungen auf die Entwicklungs-VMs selbst.

Schutz von Zugangsdaten mit der Vault VM

Vault VMs haben keinen Zugang zum Internet und eignen sich deshalb für das Ablegen hoch sensibler Daten wie Passworter und Encryption/Decryption Keys. Um den Transfer von Exploits in diesen geschützten Bereich ausschließen zu können, sollten möglichst keine Files in die VM übertragen werden. Für die Speicherung von Zugangsdaten kann das vorinstallierte KeePassX verwendet werden, der Transfer der Passwörter in die entsprechende VM geschieht über Copy/Paste zwischen VMs.

Trusted Browsing vs. Untrusted Browsing

Beim Thema Browsing unterscheiden wir zwischen der allgemeinen Suche nach Informationen im Netz (Untrusted Browsing) und der Nutzung von uns bekannten und vertrauten Services wie bspw. GitHub, AWS, CircleCI (Trusted Browsing).

Für das Trusted Browsing bietet sich eine eigene, template-basierte VM an. Wir nutzen dazu Fedora als Betriebssystem und den Firefox Browser. Um das Browsing auf vertrauensvolle Websites zu reduzieren und versehentliches Stöbern zu vermeiden, nutzen wir das Firefox Addon Block Site im Whitelist Modus. Eine Beschränkung über die Firewall ist nur über statische IP-Adressen möglich und in diesem Fall leider ungeeignet, da sich die IPs der meisten Services regelmäßig ändern.

Für das Untrusted Browsing nutzen wir eine Disposable VM basierend auf Fedora mit dem Firefox Browser. Unerwünschte Daten wie bspw. Cookies oder auch Schadsoftware verschwinden nach dem Schließen des Browsers vom System und der Zugriff auf sensible Daten der anderen VMs ist ausgeschlossen. Zusätzlich nutzen wir das Ghostery Addon, um der Datensammelwut diverser Dienste einen Riegel vorzuschieben.

Email VM

Um sensible Information aus Emails von den etwas weniger vertrauenswürdigen VMs für die Entwicklung und das Web Browsing fernzuhalten, sollte eine (oder bei mehreren Email Adressen auch mehrere) Email VMs angelegt werden. Des Weiteren erlaubt eine separate Email-VM eine restriktivere Konfiguration der Firewall. Um sicher zugehen, dass Email Links nicht versehentlich angeklickt werden, sollten nur Zugriffe auf den Email-Server die Firewall passieren können.

Automatisches Kopieren von Links mit Porcupine

Ist die Firewall entsprechen restriktiv konfiguriert, ist ein Öffnen von Links im Browser der Email-VM nicht mehr möglich. Stattdessen muss der Link kopiert und in einer anderen VM mit entsprechend passender Firewall-Einstellung geöffnet werden (Trusted bzw. Untrusted Browsing VM). Porcupine hilft, diesen Vorgang zu vereinfachen und zu beschleunigen, indem bei Klick auf einen Link die entsprechende URL in die Zwischenablage kopiert wird.

Porcupine kann über den Fedora Package Manager installiert werden:

$ dnf install porcupine

Nach der Installation muss Porcupine als Standard-Browser gesetzt werden:

$ xdg-settings set default-web-browser procupine.desktop
$ xdg-settings get default-web-browser
porcupine.desktop

Qubes Überblick

VMsBasis TemplateNetzwerk
vaultt-vault (Fedora)None
email-personal, email-workt-email (Fedora)sys-firewall
browse-personal, browse-work, browse-bankingt-trusted-browsing (Fedora)sys-firewall
develop-<project-xy>t-develop (Fedora)sys-firewall
multimediat-multimedia (Debian)sys-firewall
DisposableVMFedorasys-firewall