Användning av QubesOS för arbete med Windows 7

Det finns inte så många artiklar på Habré som handlar om operativsystemet Qubes, och de jag har sett beskriver lite om användarupplevelsen. Jag hoppas kunna åtgärda detta under kattsidan genom att visa hur Qubes används som ett skydd för Windows-miljön och samtidigt bedöma antalet svensktalande användare av systemet.

Varför Qubes?

Historien om slutet av stöd för Windows 7 och den ökande oron hos användarna har lett till behovet av att organisera arbetet i detta operativsystem med hänsyn till följande krav:

• att säkerställa användning av en fullt aktiverad Windows 7 med möjlighet för användaren att installera uppdateringar och olika applikationer (även via Internet);
• att genomföra fullständig eller selektiv uteslutning av nätverksinteraktioner enligt villkor (offline-läge och trafikfiltrering);
• att erbjuda möjlighet till selektiv anslutning av externa lagringsenheter och enheter.

En sådan uppsättning begränsningar förutsätter en tydligt förberedd användare, eftersom självständig administration är tillåten, och begränsningarna är inte kopplade till blockering av potentiella åtgärder utan till uteslutning av möjliga misstag eller programvaruskapande destruktiv påverkan. Det finns alltså ingen intern förövare i modellen.

I vår jakt på en lösning snabbt avvisade vi idén att införa begränsningar med hjälp av inbyggda eller extra medel från Windows, eftersom det är ganska svårt att effektivt begränsa en användare med administratörsrättigheter, medan man låter denne installera applikationer.

Nästa möjliga lösning var isolering genom virtualisering. Välkända verktyg för desktop-virtualisering (t.ex. som VirtualBox) är dåligt anpassade för säkerhetslösningar och de uppräknade begränsningarna måste ständigt hanteras av användaren genom att växla eller ställa in egenskaperna för den gästande virtuella maskinen (härefter VM), vilket ökar risken för misstag.

Samtidigt hade vi erfarenhet av att använda Qubes som en desktop-användarsystem, men det fanns tvivel om stabiliteten när man arbetade med gästversionen av Windows. Det beslutades att kontrollera den aktuella versionen av Qubes, eftersom de ställda begränsningarna passar mycket väl in i denna systems paradigm, särskilt implementeringen av virtuella maskinmallar och visuell integration. Jag ska försöka kortfattat berätta om idéerna och verktygen i Qubes, med exempel på lösningen av det uppställda problemet.

Typer av virtualisering av Xen

Kärnan i Qubes bygger på hypervisorn Xen, som minimerar funktionerna för hantering av CPU-resurser, minne och virtuella maskiner. All annan hantering av enheter är koncentrerad i dom0 baserad på Linux-kärnan (i Qubes använder dom0 en Fedora-distribution).

Xen stödjer flera typer av virtualisering (jag kommer att ge exempel för Intel-arkitekturen, även om Xen också stödjer andra):

• paravirtualisering (PV) – en virtualiseringsläge utan användning av hårdvarustöd, liknar container-virtualisering, kan användas för system med anpassade kärnor (dom0 fungerar i detta läge);
• fullständig virtualisering (HVM) – i detta läge används hårdvarustöd för CPU-resurser, medan all annan utrustning emuleras av QEMU. Detta är det mest mångsidiga sättet att köra olika operativsystem;
• paravirtualisering av hårdvara (PVH – ParaVirtualized Hardware) – en virtualiseringsläge som använder hårdvarustöd där kärnan i gästsystemet använder drivrutiner anpassade för hypervisorns möjligheter (t.ex. delad minne), vilket eliminerar behovet av QEMU-emulering och ökar I/O-prestandan. Linux-kärnan från version 4.11 kan arbeta i detta läge.

Från och med version 4.0 av Qubes, av säkerhetsskäl, har man avstått från att använda paravirtualiseringsläge (bland annat på grund av kända sårbarheter i Intel-arkitekturen, som delvis åtgärdas genom att använda fullständig virtualisering), och mode PVH används som standard.

Vid användning av emulering (HVM-läge) startas QEMU i en isolerad VM kallad stubdomain, vilket minskar riskerna för exploatering av potentiella fel i genomförandet (QEMU-projektet innehåller mycket kod, inklusive för kompatibilitet).
Ett sådant läge bör i vårt fall användas för Windows.

Tjänstevirtualiserade maskiner

I säkerhetsarkitekturen för Qubes är en av hypervisorens nyckelmöjligheter att överföra PCI-enheter till gästmiljön. Uteslutning av hårdvara gör det möjligt att isolera värddelen av systemet från externa attacker. Xen stöder detta för PV- och HVM-lägen, där det för det andra krävs stöd för IOMMU (Intel VT-d) — hårdvarustyrning av minnet för virtualiserade enheter.

På så sätt skapas flera systemvirtualiserade maskiner:

• sys-net, som får nätverksenheter och används som bro för andra VMer, till exempel som implementerar funktioner för brandvägg eller VPN-klient;
• sys-usb, som får USB- och andra kontroller för perifera enheter;
• sys-firewall, som inte använder enheter, utan fungerar som en brandvägg för anslutna VMer.

För att arbeta med USB-enheter används proxytjänster som säkerställer bland annat:

• för HID-enheter (human interface device) överföring av kommandon till dom0;
• för avtagbara lagringsenheter omdirigering av enhetstorlekar till andra VMer (med undantag för dom0);
• omdirigering av själva USB-enheten (använder USBIP och integrationsmedel).

I en sådan konfiguration kan en lyckad attack genom nätverksstacken eller anslutna enheter endast leda till kompromettering av den körande tjänste-VM:n, istället för hela systemet. Efter omstart av tjänste-VM:n kommer den att laddas i sitt ursprungliga tillstånd.

Integrationsverktyg för VMer

Det finns flera sätt att interagera med skrivbordet på en virtuell maskin – genom att installera program i gästsystemet eller emulera video genom virtualisering. Gästapplikationer kan vara olika universella fjärråtkomstlösningar (RDP, VNC, Spice osv.) eller anpassade för en specifik hypervisor (denna typ av verktyg kallas vanligtvis gästverktyg). En blandad variant kan användas där hypervisorn emulerar in- och utdata för gästsystemet, medan den utanför erbjuder möjligheten att använda ett protokoll som kombinerar in- och utdata, till exempel som med Spice. Fjärråtkomstverktyg optimerar vanligtvis bilden, eftersom de förutsätter arbete över ett nätverk, vilket påverkar bildkvaliteten negativt.

Qubes tillhandahåller egna verktyg för integration av VM. Först och främst är detta grafiksystemet – fönster från olika VM visas på en gemensam skrivbord med egen färgkant. Generellt baseras integrationsverktygen på hypervisorens funktioner – delat minne (Xen grant table), notifieringsverktyg (Xen event channel), delad lagring xenstore och kommunikationsprotokoll vchan. Med deras hjälp genomförs grundläggande komponenter som qrexec och qubes-rpc, samt applikationstjänster – ljud- eller USB-omdirigering, filöverföring eller innehåll överföring till urklipp, utförande av kommandon och starta applikationer. Det finns möjlighet att ställa in policyer som begränsar de tjänster som är tillgängliga på VM. Nedan är ett exempel på proceduren för att initiera interaktionen mellan två VM.

Således arbetar man i VM utan att använda nätverket, vilket gör det möjligt att fullt ut utnyttja autonomiska VM för att undvika informationsläckage. Till exempel genomförs separation av kryptografiska operationer (PGP/SSH), när privata nycklar används i isolerade VM och inte lämnar deras gränser.

Mallar, applikations- och engångs-VM

All user work in Qubes is carried out in virtual machines. The primary host system is used to manage their operation and visualization. The OS is installed along with a basic set of virtual machines based on templates (TemplateVM). Such a template represents a Linux VM based on the Fedora or Debian distribution, with integration tools installed and configured, along with dedicated system and user partitions. Software installation and updates are performed using the standard package manager (dnf or apt) from configured repositories, with mandatory digital signature verification (GnuPG). The purpose of these VMs is to ensure trust in the application VMs that run on their basis.

An application VM (AppVM) uses a snapshot of the system partition from the corresponding VM template at startup and deletes this snapshot upon completion without saving changes. Necessary user data is stored in a unique user partition for each application VM, which is mounted in the home directory.

Using disposable VMs can be beneficial from a security perspective. Such a VM is created from a template at startup and is launched with one purpose — to run a single application, terminating after it is closed. Disposable VMs can be used to open suspicious files whose contents may exploit vulnerabilities in specific applications. The ability to launch a disposable VM is integrated into the file manager (Nautilus) and the email client (Thunderbird).

A Windows VM can also be used to create a template and a disposable VM; for this, the user profile is transferred to a separate partition. In our case, such a template will be used by the user for administrative tasks and application installation. Several application VMs will be created based on the template — with limited network access (using sys-firewall) and without any network access at all (no virtual network device is created). All modifications and applications installed in the template will be available in these VMs, and even in the case of the introduction of trojans, they will lack network access for compromise.

The Struggle for Windows

De funktioner som beskrivs ovan är grunden för Qubes och fungerar faktiskt ganska stabilt; svårigheterna börjar med Windows. För att integrera Windows krävs en uppsättning gästeredskap som kallas Qubes Windows Tools (QWT), som inkluderar drivrutiner för att arbeta med Xen, qvideo-drivrutin och en uppsättning verktyg för informationsutbyte (filöverföring, gemensamt urklipp). Installations- och konfigurationsprocessen är noggrant dokumenterad på projektets webbplats, så vi delar med oss av vår erfarenhet av tillämpningen.

Den största svårigheten ligger i själva avsaknaden av stöd för det utvecklade verktyget. De nyckelutvecklare (QWT) verkar vara otillgängliga, och projektet för integration med Windows väntar på en ledande utvecklare. Därför var det först och främst nödvändigt att bedöma funktionaliteten och få en förståelse för möjligheten att stödja det vid behov själva. Den mest utmanande delen av utvecklingen och felsökningen är grafiska drivrutinen, som emulerar grafikkort och skärm för att skapa en bild i delat minne, vilket gör att hela skrivbordet eller ett specifikt programfönster kan visas i värdsystemets fönster. Under analysen av drivrutinen anpassade vi koden för att bygga i en Linux-miljö och arbetade med felsökningsschemat mellan två Windows-gäster. Vid krossbyggnadssteget genomförde vi flera förenklade ändringar, mestadels avseende "tyst" installation av verktyg, och eliminerade den irriterande prestandadegradering som uppstår vid långvarig drift i VM. Resultaten av vårt arbete dokumenterade vi separat. förrådet, vilket därmed kortvarigt inspirerade den ledande utvecklaren av Qubes.

Det mest kritiska steget för stabiliteten i gästsystemet är start av Windows, här kan man se den bekanta blå skärmen (eller till och med inte se den). För de flesta upptäckta fel fanns olika workaround-lösningar - avvisande av Xen-drivrutiner för blockenheter, avaktivering av minnesbalansering i VM, fastställande av nätverksinställningar och minimering av antalet kärnor. Vår samling av gästeredskap installeras och fungerar på fullt uppdaterat Windows 7 och Windows 10 (förutom qvideo).

När man övergår från en verklig miljö till en virtuell uppstår ett problem med aktiveringen av Windows när man använder förinstallerade OEM-versioner. Sådana system använder aktivering baserad på licenser lagrade i UEFI-enheten. För korrekt aktivering måste en av ACPI-sektionerna från värdsystemet överföras helt till gästsystemet (SLIC-tabell) och andra behöver justeras något för att ange tillverkaren. Xen möjliggör anpassning av innehållet i ACPI:s ytterligare tabeller, men utan att modifiera de grundläggande. En patch från ett liknande projekt, OpenXT, hjälpte till att lösa problemet och anpassades för Qubes. Dessa korrigeringar visade sig vara användbara inte bara för oss utan har också överförts till huvudförrådet Qubes och Libvirt-biblioteket.

De uppenbara bristerna med Windows integrationsverktyg är bristen på ljudsupport, USB-enheter och svårigheten att hantera media, eftersom det inte finns någon hårdvarustöd för GPU. Men dessa faktorer hindrar inte användning av VM för att arbeta med kontorsdokument och hindrar inte körning av specifika företagsapplikationer.

Kravet att växla till offline-läge eller med begränsad nätverksåtkomst efter skapandet av Windows VM-mallen uppfylldes genom att skapa lämpliga konfigurationer av applicerade VM, och möjligheten till selektiv anslutning av externa lagringsenheter löses också med operativsystemets standardverktyg — vid anslutning är dessa tillgängliga i system-VM sys-usb, från vilket de kan "släppas igenom" till den nödvändiga VM:n. Användarens skrivbord ser ungefär ut så här.

Den slutgiltiga versionen av systemet har mottagits positivt (så mycket som en så komplex lösning medger) av användarna, och operativsystemets standardverktyg har möjliggjort att utöka användningen till en mobil arbetsplats med tillgång via VPN.

Avslutande

Virtualisering i allmänhet gör det möjligt att minska riskerna med att använda Windows-system som inte längre stöds — det tvingar inte till att säkerställa kompatibilitet med nya hårdvaror, möjliggör att utesluta eller kontrollera åtkomst till systemet över nätverk eller via anslutna enheter, och möjliggör att skapa en miljö för engångsstart.

Qubes OS, som är baserat på idén om isolering genom virtualisering, hjälper till att använda dessa och andra mekanismer för att säkerställa säkerheten. Många ser Qubes främst som en strävan efter anonymitet, men det är ett användbart system för både ingenjörer som ofta samordnar projekt, infrastrukturer och hemligheter kopplade till dem samt för säkerhetsexperter. Att separera applikationer, data och formalisera deras interaktioner är de första stegen i hotanalys och design av skyddssystem. Denna separation hjälper till att strukturera information och minskar risken för misstag på grund av mänskliga faktorer - som stress, trötthet etc.

För närvarande fokuserar utvecklingen på att utöka funktionaliteten i Linux-miljöer. En version 4.1, som baseras på Fedora 31 och kommer att inkludera aktuella versioner av nyckelkomponenterna Xen och Libvirt, förbereds för release. Det är värt att notera att Qubes utvecklas av yrkesverksamma inom informationssäkerhet som alltid snabbt släpper uppdateringar vid upptäckten av nya hot eller fel.

Epilog

En av de experimentella funktionerna vi utvecklar möjliggör skapandet av VM med stöd för gäståtkomst till GPU baserat på teknologin Intel GVT-g, vilket gör att man kan dra nytta av grafikprocessorns kapabiliteter och betydligt utöka systemets användningsområde. Vid tidpunkten för artikelskrivningen fungerar den här funktionen för testversioner av Qubes 4.1 och finns tillgänglig på github.

Källa: habr.com