Det finns inte många artiklar om Habré ägnade åt operativsystemet Qubes, och de som jag har sett beskriver inte mycket av upplevelsen av att använda det. Nedanför snittet hoppas jag kunna rätta till detta med exemplet att använda Qubes som ett sätt att skydda (mot) Windows-miljön och samtidigt uppskatta antalet rysktalande användare av systemet.
Varför Qubes?
Historien om slutet på teknisk support för Windows 7 och användarnas ökande oro ledde till behovet av att organisera arbetet med detta operativsystem, med hänsyn till följande krav:
- säkerställa användningen av fullt aktiverat Windows 7 med möjlighet för användaren att installera uppdateringar och olika applikationer (inklusive via Internet);
- implementera fullständig eller selektiv uteslutning av nätverksinteraktioner baserat på förhållanden (autonom drift och trafikfiltreringslägen);
- ger möjlighet att selektivt ansluta flyttbara media och enheter.
Denna uppsättning begränsningar förutsätter en tydligt förberedd användare, eftersom oberoende administration är tillåten, och begränsningarna är inte relaterade till att blockera hans potentiella handlingar, utan till uteslutandet av möjliga fel eller destruktiva mjukvarueffekter. De där. Det finns ingen intern gärningsman i modellen.
I vårt sökande efter en lösning övergav vi snabbt tanken på att implementera begränsningar med hjälp av inbyggda eller ytterligare Windows-verktyg, eftersom det är ganska svårt att effektivt begränsa en användare med administratörsrättigheter, vilket ger honom möjligheten att installera applikationer.
Nästa lösning var isolering med virtualisering. Välkända verktyg för skrivbordsvirtualisering (till exempel virtualbox) är dåligt lämpade för att lösa säkerhetsproblem och de angivna begränsningarna måste göras av användaren genom att ständigt byta eller justera egenskaperna för den virtuella gästmaskinen (hädanefter hänvisad till som VM), vilket ökar risken för fel.
Samtidigt hade vi erfarenhet av att använda Qubes som en användares skrivbordssystem, men tvivlade på stabiliteten i att arbeta med gäst-Windows. Det beslutades att kontrollera den aktuella versionen av Qubes, eftersom de angivna begränsningarna passar mycket väl in i paradigmet för detta system, särskilt implementeringen av virtuella maskinmallar och visuell integration. Därefter kommer jag att försöka att kort prata om idéerna och verktygen från Qubes, med hjälp av exemplet för att lösa problemet.
Typer av Xen-virtualisering
Qubes är baserat på Xen-hypervisorn, som minimerar funktionerna för att hantera processorresurser, minne och virtuella maskiner. Allt annat arbete med enheter är koncentrerat till dom0 baserat på Linux-kärnan (Qubes för dom0 använder Fedora-distributionen).
Xen stöder flera typer av virtualisering (jag kommer att ge exempel för Intel-arkitektur, även om Xen stöder andra):
- paravirtualisering (PV) - ett virtualiseringsläge utan användning av hårdvarustöd, som påminner om containervirtualisering, kan användas för system med en anpassad kärna (dom0 fungerar i detta läge);
- full virtualisering (HVM) - i detta läge används hårdvarustöd för processorresurser och all annan utrustning emuleras med QEMU. Detta är det mest universella sättet att köra olika operativsystem;
- paravirtualisering av hårdvara (PVH - ParaVirtualized Hardware) - ett virtualiseringsläge som använder hårdvarustöd när gästsystemkärnan, för att arbeta med hårdvara, använder drivrutiner anpassade till hypervisorns möjligheter (till exempel delat minne), vilket eliminerar behovet av QEMU-emulering och öka I/O-prestanda. Linuxkärnan från 4.11 kan fungera i detta läge.
Från och med Qubes 4.0, av säkerhetsskäl, överges användningen av paravirtualiseringsläge (inklusive på grund av kända sårbarheter i Intel-arkitektur, som delvis mildras genom användning av full virtualisering); PVH-läge används som standard.
Vid användning av emulering (HVM-läge) lanseras QEMU i en isolerad virtuell dator som kallas stubdomain, vilket minskar riskerna för att utnyttja potentiella fel i implementeringen (QEMU-projektet innehåller mycket kod, inklusive för kompatibilitet).
I vårt fall bör detta läge användas för Windows.
Betjäna virtuella maskiner
I Qubes säkerhetsarkitektur är en av hypervisorns nyckelfunktioner överföringen av PCI-enheter till gästmiljön. Uteslutning av hårdvara låter dig isolera värddelen av systemet från externa attacker. Xen stöder detta för PV- och HVM-lägen, i det andra fallet kräver det stöd för IOMMU (Intel VT-d) - hantering av hårdvaruminne för virtualiserade enheter.
Detta skapar flera virtuella systemmaskiner:
- sys-net, till vilket nätverksenheter överförs och som används som en brygga för andra virtuella datorer, till exempel de som implementerar funktionerna hos en brandvägg eller en VPN-klient;
- sys-usb, till vilken USB och andra styrenheter för kringutrustning överförs;
- sys-brandvägg, som inte använder enheter, men fungerar som en brandvägg för anslutna virtuella datorer.
För att arbeta med USB-enheter används proxytjänster som ger bland annat:
- för enhetsklassen HID (human interface device) skickar kommandon till dom0;
- för flyttbara media, omdirigering av enhetsvolymer till andra virtuella datorer (förutom dom0);
- omdirigering direkt till en USB-enhet (med USBIP och integrationsverktyg).
I en sådan konfiguration kan en framgångsrik attack genom nätverksstacken eller anslutna enheter leda till att endast den körande tjänsten VM kompromissar, och inte hela systemet som helhet. Och efter att ha startat om tjänsten VM kommer den att laddas i sitt ursprungliga tillstånd.
VM-integreringsverktyg
Det finns flera sätt att interagera med skrivbordet på en virtuell maskin - installera applikationer i gästsystemet eller emulera video med virtualiseringsverktyg. Gästapplikationer kan vara olika universella fjärråtkomstverktyg (RDP, VNC, Spice, etc.) eller anpassade till en specifik hypervisor (sådana verktyg kallas vanligtvis gästverktyg). Ett blandat alternativ kan också användas när hypervisorn emulerar I/O för gästsystemet och externt ger möjlighet att använda ett protokoll som kombinerar I/O, till exempel, som Spice. Samtidigt optimerar fjärråtkomstverktyg oftast bilden, eftersom de innebär arbete via ett nätverk, vilket inte har en positiv effekt på bildens kvalitet.
Qubes tillhandahåller sina egna verktyg för VM-integration. Först och främst är detta ett grafiskt delsystem - fönster från olika virtuella datorer visas på ett enda skrivbord med sin egen färgram. I allmänhet är integrationsverktyg baserade på funktionerna hos hypervisorn - delat minne (Xen-anslagstabell), meddelandeverktyg (Xen-händelsekanal), delad lagring xenstore och vchan-kommunikationsprotokollet. Med deras hjälp implementeras de grundläggande komponenterna qrexec och qubes-rpc, och applikationstjänster - ljud- eller USB-omdirigering, överföring av filer eller urklippsinnehåll, exekvering av kommandon och start av applikationer. Det är möjligt att ställa in policyer som gör att du kan begränsa de tjänster som är tillgängliga på en virtuell dator. Bilden nedan är ett exempel på proceduren för att initiera interaktionen mellan två virtuella datorer.
Arbetet i den virtuella datorn utförs således utan att använda ett nätverk, vilket tillåter full användning av autonoma virtuella datorer för att undvika informationsläckage. Det är till exempel så här separation av kryptografiska operationer (PGP/SSH) implementeras, när privata nycklar används i isolerade virtuella datorer och inte går utöver dem.
Mallar, applikationer och engångs-VM
Allt användararbete i Qubes sker i virtuella maskiner. Huvudvärdsystemet används för att kontrollera och visualisera dem. OS är installerat tillsammans med en grundläggande uppsättning mallbaserade virtuella maskiner (TemplateVM). Den här mallen är en virtuell Linux-dator baserad på Fedora- eller Debian-distributionen, med integrationsverktyg installerade och konfigurerade, och dedikerade system- och användarpartitioner. Installation och uppdatering av programvara utförs av en standardpakethanterare (dnf eller apt) från konfigurerade arkiv med obligatorisk digital signaturverifiering (GnuPG). Syftet med sådana virtuella datorer är att säkerställa förtroende för virtuella applikationer som lanseras på grundval av dem.
Vid start använder en applikations-VM (AppVM) en ögonblicksbild av systempartitionen för motsvarande VM-mall, och när den är klar raderas denna ögonblicksbild utan att spara ändringar. Data som krävs av användaren lagras i en användarpartition som är unik för varje applikations-VM, som är monterad i hemkatalogen.
Att använda virtuella engångsmaskiner (disposableVM) kan vara användbart ur säkerhetssynpunkt. En sådan virtuell dator skapas baserat på en mall vid uppstartstillfället och lanseras för ett syfte - att köra en applikation, slutföra arbetet efter att det stängts. VM:er av engångstyp kan användas för att öppna misstänkta filer vars innehåll kan leda till exploatering av specifika programsårbarheter. Möjligheten att köra en engångs-VM är integrerad i filhanteraren (Nautilus) och e-postklienten (Thunderbird).
Windows VM kan också användas för att skapa en mall och en engångs-VM genom att flytta användarprofilen till en separat sektion. I vår version kommer en sådan mall att användas av användaren för administrationsuppgifter och applikationsinstallation. Baserat på mallen kommer flera virtuella applikationer att skapas - med begränsad åtkomst till nätverket (standard sys-brandväggsmöjligheter) och utan åtkomst till nätverket alls (en virtuell nätverksenhet skapas inte). Alla ändringar och applikationer som installeras i mallen kommer att vara tillgängliga för att fungera i dessa virtuella datorer, och även om bokmärkesprogram introduceras kommer de inte att ha nätverksåtkomst för kompromisser.
Kämpa för Windows
Funktionerna som beskrivs ovan är grunden för Qubes och fungerar ganska stabilt; svårigheterna börjar med Windows. För att integrera Windows måste du använda en uppsättning gästverktyg Qubes Windows Tools (QWT), som inkluderar drivrutiner för att arbeta med Xen, en qvideo-drivrutin och en uppsättning verktyg för informationsutbyte (filöverföring, urklipp). Installation och konfigureringsprocessen dokumenteras i detalj på projektets webbplats, så vi kommer att dela med oss av vår applikationserfarenhet.
Den största svårigheten är i huvudsak bristen på stöd för de utvecklade verktygen. Nyckelutvecklare (QWT) verkar vara otillgängliga och Windows-integrationsprojektet väntar på en ledande utvecklare. Därför var det först och främst nödvändigt att bedöma dess prestanda och bilda sig en förståelse för möjligheten att stödja den självständigt, om det skulle behövas. Den svåraste att utveckla och felsöka är grafikdrivrutinen, som emulerar videoadaptern och skärmen för att generera en bild i delat minne, så att du kan visa hela skrivbordet eller programfönstret direkt i värdsystemets fönster. Under analysen av drivrutinens funktion anpassade vi koden för montering i en Linux-miljö och arbetade fram ett felsökningsschema mellan två Windows-gästsystem. I crossbuild-stadiet gjorde vi flera förändringar som förenklade saker för oss, främst när det gäller "tyst" installation av verktyg, och eliminerade även den irriterande försämringen av prestanda när man arbetade i en virtuell dator under lång tid. Vi presenterade resultatet av arbetet i en separat , alltså inte länge Ledande Qubes-utvecklare.
Det mest kritiska steget när det gäller gästsystemstabilitet är uppstarten av Windows, här kan du se den välbekanta blå skärmen (eller inte ens se den). För de flesta av de identifierade felen fanns det olika lösningar - eliminera Xen-blockenhetsdrivrutiner, inaktivera VM-minnesbalansering, fixa nätverksinställningar och minimera antalet kärnor. Våra gästverktyg bygger installerar och körs på helt uppdaterade Windows 7 och Windows 10 (förutom qvideo).
När man flyttar från en verklig miljö till en virtuell, uppstår ett problem med att aktivera Windows om förinstallerade OEM-versioner används. Sådana system använder aktivering baserat på licenser som anges i enhetens UEFI. För att korrekt bearbeta aktiveringen är det nödvändigt att översätta en av hela ACPI-sektionerna i värdsystemet (SLIC-tabellen) till gästsystemet och redigera de andra något, registrera tillverkaren. Xen låter dig anpassa ACPI-innehållet i ytterligare tabeller, men utan att ändra de viktigaste. En patch från ett liknande OpenXT-projekt, som var anpassat för Qubes, hjälpte till med lösningen. Fixningarna verkade användbara inte bara för oss och översattes till huvudförrådet i Qubes och Libvirt-biblioteket.
De uppenbara nackdelarna med Windows-integreringsverktyg inkluderar bristen på stöd för ljud, USB-enheter och komplexiteten i att arbeta med media, eftersom det inte finns något hårdvarustöd för GPU:n. Men ovanstående hindrar inte användningen av den virtuella datorn för att arbeta med kontorsdokument, och det hindrar inte heller lanseringen av specifika företagsapplikationer.
Kravet att byta till driftläge utan nätverk eller med ett begränsat nätverk efter att ha skapat en Windows VM-mall uppfylldes genom att skapa lämpliga konfigurationer av applikations-VM, och möjligheten att selektivt ansluta flyttbara media löstes också av standard OS-verktyg - när den var ansluten , de är tillgängliga i systemets VM sys-usb, varifrån de kan "vidarebefordras" till den virtuella datorn som krävs. Användarens skrivbord ser ut ungefär så här.
Den slutliga versionen av systemet accepterades positivt (så långt en sådan omfattande lösning tillåter) av användarna, och systemets standardverktyg gjorde det möjligt att utöka applikationen till användarens mobila arbetsstation med åtkomst via VPN.
I stället för en slutsats
Virtualisering i allmänhet gör att du kan minska riskerna med att använda Windows-system som lämnas utan stöd - det tvingar inte fram kompatibilitet med ny hårdvara, det låter dig utesluta eller kontrollera åtkomst till systemet över nätverket eller via anslutna enheter, och det låter dig implementera en engångslanseringsmiljö.
Baserat på idén om isolering genom virtualisering, hjälper Qubes OS dig att utnyttja dessa och andra mekanismer för säkerhet. Från utsidan ser många människor Qubes främst som en önskan om anonymitet, men det är ett användbart system både för ingenjörer, som ofta jonglerar med projekt, infrastrukturer och hemligheter för att komma åt dem, och för säkerhetsforskare. Separering av applikationer, data och formalisering av deras interaktion är de första stegen i hotanalys och säkerhetssystemdesign. Denna separation hjälper till att strukturera information och minska sannolikheten för fel på grund av den mänskliga faktorn - brådska, trötthet, etc.
För närvarande ligger huvudvikten i utvecklingen på att utöka funktionaliteten i Linux-miljöer. Version 4.1 förbereds för release, som kommer att baseras på Fedora 31 och inkluderar aktuella versioner av nyckelkomponenterna Xen och Libvirt. Det är värt att notera att Qubes skapas av informationssäkerhetsproffs som alltid snabbt släpper uppdateringar om nya hot eller fel identifieras.
efterordet
En av de experimentella funktionerna vi utvecklar gör att vi kan skapa virtuella datorer med stöd för gäståtkomst till GPU:n baserad på Intel GVT-g-teknik, vilket gör att vi kan använda grafikadapterns kapacitet och avsevärt utöka systemets omfattning. I skrivande stund fungerar den här funktionen för testversioner av Qubes 4.1 och är tillgänglig på .
Källa: will.com