Mijn digitale leven onderverdelen in beveiligingsdomeinen

Het onderstaande beschrijft hoe ik mijn digitale leven heb opgedeeld in beveiligingsdomeinen. Dit is een vrij geavanceerd schema en de meeste gebruikers zouden waarschijnlijk iets simpelers willen, maar ik denk dat het nog steeds interessant is om te bespreken. De domeinen zijn geïmplementeerd als lichtgewicht AppVM's op Qubes OS. Elk domein heeft specifieke rechten wat betreft netwerkconnectiviteit.

De basisdomeinen en kleurcodering

De drie basisdomeinen zijn werk (groen label), persoonlijk (geel label) en rood (voor alle onbetrouwbare, niet-gevoelige zaken). Deze zijn in het schema gemarkeerd met dikke kaders.

Over domeinlabels (kleuren)

In Qubes OS krijgt elk domein, naast een unieke naam, ook een label in de vorm van een vooraf gedefinieerde kleur. Deze kleuren worden gebruikt voor de raamdecoraties door de vertrouwde Window Manager en dienen als gebruiksvriendelijke indicatoren van hoe vertrouwelijk een bepaald venster is. De interpretatie van deze kleuren is volledig aan de gebruiker.

Voor mij is de associatie als volgt:

• Rood: Onbetrouwbaar en gevaarlijk ("rood licht" – stop! gevaar!).
• Groen: Veilig en vertrouwd.
• Geel en oranje: Ergens in het midden.
• Blauw en zwart: Progressief meer vertrouwde domeinen dan groen, waarbij zwart staat voor ultiem vertrouwd.

Specifieke domeinen en hun functies

Werkgerelateerde domeinen

• Werk (Groen): Hier heb ik toegang tot mijn werk-e-mail, bewaar ik mijn werk-PGP-sleutels en stel ik rapporten, presentaties en papers op. Ook bewaar ik hier diverse contracten en NDA's (als PDF's, mits ontvangen van vertrouwde partijen via versleutelde en ondertekende e-mail; anders open ik ze in Disposable VM's). Dit domein heeft enkel netwerktoegang tot mijn werk-mailserver (SMTP/IMAP4 via SSL).
• Work-pub (Geel): Voor werkgerelateerde taken die webtoegang vereisen, zoals het bewerken van de Qubes Wiki, het accepteren van LinkedIn-uitnodigingen, of het downloaden van afbeeldingen van fotolia.com of specificaties van intel.com. Omdat ik dit domein slechts "enigszins vertrouwd" acht, bewaar ik hier nooit PGP-sleutels of vertrouwelijke werkgegevens.
• Work-admin: Wordt gebruikt voor het beheer van bijna alle ITL-servers (webserver, Qubes repo & wiki servers, mailserver en DNS-beheer). Dit domein staat enkel SSH-verkeer naar deze servers toe, en HTTPS naar enkele webgebaseerde beheerservers.
• Work-blog: Wordt gebruikt voor het beheren van deze blog. Dit is gescheiden van work-admin of work uit paranoia: als de blogger-dienst gecompromitteerd wordt en een browserbug wordt misbruikt, mag dit niet leiden tot admin-toegang tot alle ITL-servers.
• Qubes-dev: Wordt gebruikt voor alle Qubes-ontwikkeling, het mergen van branches van andere ontwikkelaars (na verificatie van signaturen), het bouwen van RPM's/ISO's en het ondertekenen hiervan. Vanwege de ondertekeningssleutels is dit domein zeer gevoelig. Het heeft enkel SSH-netwerktoegang tot onze Qubes git-server.
• Work-archives: Hier verplaats ik jaarlijks oude bestanden (oude mailspools, contracten, NDA's) vanuit het werkdomein. Dit minimaliseert de impact van een eventuele aanval op het actieve werkdomein (bijvoorbeeld via een hypothetische bug in de protocol-handshake van Thunderbird of een bug in GPG).

Persoonlijke en financiële domeinen

• Persoonlijk (Geel): Hier staan alle niet-werkgerelateerde zaken, zoals persoonlijke e-mail, agenda, vakantiefoto's en video's. Het heeft in principe geen webtoegang, maar indien ik sociale netwerken zou gebruiken, zou ik HTTPS toestaan voor bijvoorbeeld Facebook.
• Very-personal: Een speciaal domein voor communicatie met mijn partner via PGP, met hiervoor aparte PGP-sleutels. Hoewel we geen staatsgeheimen bespreken, prefereren we om intieme gesprekken privé te houden.
• Shopping: Voor toegang tot e-commerce sites. Dit domein is gedefinieerd door de toegang tot mijn creditcardgegevens en mijn persoonlijke adres. Hier doe ik alle inkopen, van boodschappen tot hotel- en vluchtreserveringen.
• Banking: Wordt uitsluitend gebruikt voor het beheren van mijn bankrekeningen (zowel privé als zakelijk).

Overige gespecialiseerde domeinen

• Accounting: Alle boekhoudkundige zaken en facturen worden hier bewaard. De ratio is dat ik deze PDF's veel minder vertrouw dan de PDF's in mijn werkdomein.
• Vault: Een ultiem vertrouwd domein waar ik alle wachtwoorden (via KeePass) en master GPG-sleutels genereer en bewaar. Dit domein heeft absoluut geen netwerktoegang. (Opmerking: specifieke wachtwoorden, zoals die voor de mailserver, worden ook in het betreffende domein bewaard, bijvoorbeeld in Thunderbird, omdat het geen zin heeft dit te blokkeren als de gebruiker het wachtwoord toch handmatig moet invoeren).
• Red: Dit domein is totaal onbetrouwbaar. Als het gecompromitteerd wordt, is dat niet erg; ik kan het binnen enkele seconden opnieuw aanmaken. Ik maak er geen back-ups van. Hier doe ik alles wat niet in andere domeinen past en waarvoor geen gevoelige informatie nodig is, inclusief algemeen surfen. Voor anonimiteit zou ik een apart anoniem domein maken met verkeer via een Tor-proxy.

Datastromen tussen domeinen

De meeste datastromen lopen van meer vertrouwde domeinen naar minder vertrouwde domeinen. Voorbeelden hiervan zijn het kopiëren van een URL uit een werkmail naar de onbetrouwbare browser in het rode domein, of het verplaatsen van facturen van het werkdomein naar het accounting domein.

Het probleem van "up transfers"

Er zijn echter ook transfers van minder vertrouwde naar meer vertrouwde domeinen. Bijvoorbeeld het kopiëren van een interessante URL vanuit het rode domein naar een e-mailclient in het werk- of persoonlijke domein.

Dit vormt een significant beveiligingsprobleem. Hoewel het plakken van een URL in een e-maileditor onschadelijk lijkt, is het nog steeds een onbetrouwbare input. We weten niet wat het rode domein daadwerkelijk in het lokale klembord heeft geplaatst (bijvoorbeeld 64kB aan junk die een undo-buffer in de editor kan laten overlopen). Nog riskanter is het kopiëren van een afbeelding vanaf het web naar het werkdomein voor gebruik in een presentatie; kwaadaardige JPEGs die bugs in rendering-code exploiteren zijn al decennia bekend.

Isolatie versus Integriteit

Sommige ontwerpers van high-security systemen (bijvoorbeeld voor militaire of overheidsdoeleinden) hanteren een tegenovergestelde benadering: zij maken zich geen zorgen over transfers van minder-naar-meer vertrouwde domeinen, zolang ze maar kunnen garanderen dat er absoluut geen data in de tegenovergestelde richting kan stromen.

Dit vereist het elimineren van alle covert channels (geheime kanalen) tussen samenwerkende domeinen. Dit is in de praktijk zeer uitdagend en vereist vaak grote offers op het gebied van systeemprestaties. Bovendien richt deze aanpak zich enkel op isolatie en niet op de integriteit van het meer vertrouwde domein. Als een aanvaller via een "up transfer" het domein binnenkomt, kan hij daar alles doen, zolang hij de data maar niet terug kan lekken. Isolatie zonder integriteit is in mijn ogen onvoldoende.

Mogelijke oplossingen

Een alternatief is het gebruik van vertrouwde "converters" of "verifiers". Dit zouden programma's zijn, geschreven in een veilige taal en draaiend in een vertrouwd domein, die specifieke bestandstypen (zoals JPEGs) controleren en saneren voordat ze in het doeldomein terechtkomen. Dit verschilt van traditionele antivirussoftware omdat het niet leunt op een database met signatures, maar op veilige verwerking.

Momenteel wordt dit probleem in Qubes genegeerd: transfers van minder vertrouwde naar meer vertrouwde domeinen gebeuren op eigen risico van de gebruiker.

Het kopiëren van bestanden tussen domeinen

Naast de inhoud van de bestanden is er het risico van het transportmiddel. Bij fysiek gescheiden machines gebeurt dit vaak via USB-sticks of CD-ROM's. Dit proces triggert echter veel acties in het besturingssysteem: het parsen van apparaatinformatie, het laden van drivers, het lezen van de partitietabel en het parsen van het bestandssysteem. Elke stap hiervan is een potentieel aanvalsvlak.

In Qubes Alpha werd een virtuele stick gebruikt. In Qubes Beta 1 wordt een nieuw schema geïmplementeerd op basis van hetzelfde gedeelde geheugenkanaal dat wordt gebruikt voor GUI-virtualisatie. Het meest gevoelige element hierin is een un-cpio-achtige utility in het doeldomein die de inkomende blob uitpakt in een vooraf gedefinieerde directorystructuur. We geloven dat een dergelijke utility veel veiliger te schrijven is dan het beveiligen van alle bovenstaande elementen (USB, partities, fs-parsing).

Handhaving en gebruiksvriendelijkheid

Om een partitioneringsschema in de praktijk zinvol te maken, is een handhavingsmechanisme nodig zodat de gebruiker het niet per ongeluk omzeilt. Hiervoor is in Qubes Beta 1 specifieke firewall-ondersteuning toegevoegd.

Daarnaast moet het systeem gebruiksvriendelijk zijn. Een voorbeeld is het instellen van een beleid waarbij het klikken op een URL in een werk-e-mail automatisch de browser in het rode domein opent. Dit is momenteel nog niet geïmplementeerd, maar wordt overwogen voor de toekomst.

Samenvatting

Het onderverdelen van een digitaal leven in beveiligingsdomeinen is een proces dat nadenken vereist en zeer gebruikersspecifiek is. Mijn eigen schema is geavanceerd; de meeste mensen zullen iets simpelers willen. In zakelijke omgevingen zal dit schema waarschijnlijk door een CIO of IT-beheerder worden ontworpen en automatisch worden afgedwongen. Voor thuisgebruikers en kleine bedrijven is dit uitdagender. Mogelijk zullen toekomstige versies van Qubes kant-en-klare templates bieden voor typische gebruikersgroepen.