Der er ikke mange artikler om operativsystemet Qubes på Habr, og dem jeg har set, beskriver lidt om erfaringerne. Under teksten håber jeg at rette op på dette ved at bruge Qubes som et beskyttelsesmiddel for Windows-miljøet og, samtidig, vurdere antallet af russisktalende brugere af systemet.
Hvorfor Qubes?
Historien om ophøret af support til Windows 7 og den stigende bekymring blandt brugerne har ført til nødvendigheden af at organisere arbejdet med dette operativsystem under hensyntagen til følgende krav:
- at sikre brugen af en fuldt aktiveret Windows 7 med mulighed for brugeren at installere opdateringer og forskellige applikationer (herunder via internettet);
- at implementere fuldstændig eller selektiv udelukkelse af netværksinteraktioner efter betingelse (offline- og trafikfiltreringstilstande);
- at give mulighed for selektiv tilkobling af eksterne lagerenheder og apparater.
Sådan et sæt begrænsninger forudsætter en klart forberedt bruger, da selvadministration er tilladt, og begrænsningerne ikke er relateret til blokering af brugerens potentielle handlinger, men til udelukkelse af mulige fejl eller destruktiv softwarepåvirkning. Det vil sige, at der ikke er nogen intern forstyrrer i modellen.
I søgen efter en løsning opgav vi hurtigt ideen om at implementere begrænsninger med indbyggede eller ekstra midler i Windows, da det er ret svært effektivt at begrænse en bruger med administratorrettigheder, samtidig med at han kan installere applikationer.
Den næste løsning var isolation ved hjælp af virtualisering. Velkendte værktøjer til desktopvirtualisering (f.eks. VirtualBox) er dårligt tilpasset sikkerhedsløsninger, og de nævnte begrænsninger skal brugeren konstant skifte eller justere egenskaberne for den gæste-VM (virtuelle maskine), hvilket øger risikoen for fejl.
Samtidig havde vi erfaring med at anvende Qubes som en desktop-brugersystem, men der var tvivl om stabiliteten ved at arbejde med den gæstebaserede Windows. Det blev besluttet at teste den aktuelle version af Qubes, da de stillede begrænsninger passer godt ind i paradigmet for dette system, især implementeringen af skabeloner for virtuelle maskiner og den visuelle integration. Jeg vil derefter forsøge at beskrive ideerne og værktøjerne i Qubes kortfattet, ved at tage udgangspunkt i løsningen af den givne opgave.
Typer af virtualisering i Xen
Qubes er baseret på hypervisoren Xen, som minimerer funktionerne til styring af CPU-ressourcer, hukommelse og virtuelle maskiner. Alt andet arbejde med enheder er koncentreret i dom0, der bygger på Linux-kernen (i Qubes anvendes Fedora-distribution til dom0).
Xen understøtter flere typer virtualisering (jeg vil give eksempler for Intel-arkitekturen, selvom Xen også understøtter andre):
- paravirtualisering (PV) — en virtualiseringstilstand uden brug af hardwareunderstøttelse, der minder om container-baseret virtualisering og kan bruges til systemer med tilpasset kerne (i denne tilstand fungerer dom0);
- fuld virtualisering (HVM) — i denne tilstand bruges hardwareunderstøttelse til CPU-ressourcer, mens alt andet udstyr emuleres ved hjælp af QEMU. Dette er den mest alsidige måde at køre forskellige OS'er på;
- paravirtualisering af hardware (PVH — ParaVirtualized Hardware) — en virtualiseringstilstand, der bruger hardwareunderstøttelse, hvor gæsternes systems kerne anvender drivere tilpasset hypervisorens funktioner (for eksempel delt hukommelse), hvilket fjerner behovet for QEMU-emulering og øger ind- og uddataens ydeevne. Linux-kernen kan fra version 4.11 fungere i denne tilstand.
Fra version 4.0 af Qubes er der af sikkerhedsmæssige grunde blevet besluttet at opgive brugen af paravirtualisering (herunder på grund af kendte sårbarheder i Intel-arkitekturen, der delvist afhjælpes ved brug af fuld virtualisering), hvor PVH-tilstand nu anvendes som standard.
Når emulering (HVM-tilstand) bruges, startes QEMU i en isoleret VM kaldet stubdomain, hvilket reducerer risici ved udnyttelse af potentielle fejl i implementeringen (QEMU-projektet indeholder meget kode, herunder for kompatibilitet).
Denne tilstand bør anvendes til Windows i vores tilfælde.
Tjeneste virtuelle maskiner
I sikkerhedsarkitekturen for Qubes er en af hypervisorens vigtigste funktioner overførsel af PCI-enheder til gæsteomgivelser. Udelukkelse af hardware gør det muligt at isolere værtens del af systemet fra eksterne angreb. Xen understøtter dette for både PV- og HVM-tilstande, hvor i det andet tilfælde kræves understøttelse fra IOMMU (Intel VT-d) — hardwareadministration af hukommelse for virtualiserede enheder.
På den måde oprettes flere systemvirtuelle maskiner:
- sys-net, som får tildelt netværksenheder og som bruges som bro til andre VM'er, for eksempel dem der implementerer firewall-funktioner eller VPN-klienter;
- sys-usb, som får tildelt USB og andre controllerenheder til perifere enheder;
- sys-firewall, som ikke bruger enheder, men fungerer som en firewall for tilsluttede VM'er.
For at arbejde med USB-enheder anvendes proxy-tjenester, som sikrer blandt andet:
- for HID-enheder (human interface device) overførsel af kommandoer til dom0;
- for udskiftelige medier, omdirigering af enhedsdisk til andre VM'er (undtagen dom0);
- omdirigering af den direkte USB-enhed (USBIP og integrationsværktøjer bruges).
I sådan en konfiguration kan et succesfuldt angreb gennem netværksstakken eller tilsluttede enheder kun føre til kompromittering af den kørende tjeneste-VM og ikke hele systemet. Og efter genstart vil den tjeneste-VM blive indlæst i sin oprindelige tilstand.
Integrationsværktøjer for VM
Der er flere måder at interagere med skrivebordet på en virtuel maskine — installation af applikationer i gæstesystemet eller videoemulering ved hjælp af virtualiseringsteknikker. Gæsteapplikationer kan være forskellige universelle fjernadgangsværktøjer (RDP, VNC, Spice osv.) eller specifikt tilpasset til en bestemt hypervisor (sådanne værktøjer kaldes ofte gæsteværktøjer). Der kan også anvendes en blandet løsning, hvor hypervisoren emulerer input-output for gæstesystemet og udenfor giver mulighed for at bruge en protokol, der kombinerer input-output, som i tilfældet med Spice. I denne proces optimerer fjernadgangsværktøjerne typisk billedet, da de antager, at arbejdet foregår over et netværk, hvilket ikke altid er til fordel for billedkvaliteten.
Qubes leverer sine egne værktøjer til integration af VM'er. Først og fremmest er der det grafiske system — vinduer fra forskellige VM'er vises på et fælles skrivebord med sin egen farveindramning. Generelt er integrationsværktøjerne baseret på hypervisorens funktioner — delt hukommelse (Xen grant table), underretningsværktøjer (Xen event channel), delt lager xenstore og kommunikationsprotokollen vchan. Ved hjælp af disse implementeres de grundlæggende komponenter qrexec og qubes-rpc samt applikationstjenester — lyd- eller USB-omdirigering, filoverførsel eller udklipsholderindhold, udførelse af kommandoer og start af applikationer. Der er mulighed for at etablere politikker, der begrænser de tjenester, der er tilgængelige på VM'en. Nedenfor er et eksempel på proceduren for initiering af interaktionen mellem to VM'er.
Dermed foregår arbejdet i VM uden brug af netværket, hvilket muliggør, at autonome VM'er kan bruges fuldt ud for at undgå informationslækage. For eksempel anvendes dette til at adskille kryptografiske operationer (PGP/SSH), hvor lukkede nøgler anvendes i isolerede VM'er og ikke forlader deres grænser.
Skabeloner, applikations- og engangs-VM'er
Alt arbejde i Qubes foregår i virtuelle maskiner. Det primære værtsoperativsystem bruges til at styre deres drift og visualisering. OS-installationen sker sammen med et grundlæggende sæt af virtuelle maskiner baseret på skabeloner (TemplateVM). En sådan skabelon er en Linux VM baseret på enten Fedora eller Debian-distributionen, med installerede og konfigurerede integrationsværktøjer samt dedikerede system- og brugerpartitioner. Installation og opdatering af software foregår gennem den indbyggede pakkemanager (dnf eller apt) fra de konfigurerede repositories med obligatorisk kontrol af den digitale signatur (GnuPG). Formålet med disse VMer er at sikre tillid til de applikations-VM'er, der kører på deres grundlag.
En applikations-VM (AppVM) bruger ved opstart et snapshot af systempartitionen fra den tilsvarende VM-skabelon, og efter afslutningen fjerner den dette snapshot uden at gemme ændringer. De nødvendige brugerdata opbevares i en unik brugerpartition for hver applikations-VM, som monteres i hjemmemappen.
Brugen af engangs-VM'er (disposableVM) kan være nyttig sikkerhedsmæssigt. En sådan VM oprettes baseret på en skabelon i det øjeblik, den startes, og køres med det formål at udføre én applikation, som afsluttes efter lukning. Engangs-VM'er kan bruges til at åbne mistænkelige filer, hvis indhold kan føre til udnyttelse af sårbarheder i specifikke applikationer. Muligheden for at starte en engangs-VM er integreret i filhåndtereren (Nautilus) og e-mailklienten (Thunderbird).
En Windows VM kan også bruges til at oprette en skabelon og en engangs-VM; til dette flyttes brugerprofilen til en separat partition. I vores tilfælde vil denne skabelon blive brugt af brugeren til administrativt arbejde og installation af applikationer. Baseret på skabelonen vil der blive oprettet flere applikations-VM'er — med begrænset netværksadgang (standardfunktioner sys-firewall) og uden netværksadgang overhovedet (der oprettes ikke en virtuel netværksenhed). I disse VM'er vil alle ændringer og applikationer, der installeres i skabelonen, være tilgængelige, og selv i tilfælde af inddragelse af spyware, vil de ikke have netværksadgang for kompromittering.
Kampen for Windows
De nævnte muligheder danner grundlaget for Qubes og fungerer ganske stabilt, mens der opstår problemer med Windows. For at integrere Windows skal man bruge Qubes Windows Tools (QWT), som inkluderer drivere til at arbejde med Xen, qvideo-driveren og et sæt værktøjer til informationsudveksling (filoverførsel, udklipsholder). Installations- og konfigurationsprocessen er detaljeret dokumenteret på projektets hjemmeside, så vi vil dele vores erfaring med anvendelsen.
Den største udfordring er i bund og grund manglen på støtte fra det udviklede værktøj. Nøgleudviklerne af QWT er tilsyneladende ikke tilgængelige, og integrationsprojektet med Windows venter på en førende udvikler. Derfor var det først og fremmest nødvendigt at vurdere funktionaliteten og danne sig et indtryk af muligheden for at støtte det selv, hvis nødvendigt. Den mest komplekse del af udviklingen og fejlfindingen er grafikkdriveren, som emulerer et grafikkort og display for at danne billeder i delt hukommelse, hvilket gør det muligt at vise hele skrivebordet eller vinduet af applikationen i værtsystemets vindue. Under analysen af driverens funktionalitet tilpassede vi koden til compilering i et Linux-miljø og arbejdede med debug-schemet mellem to gæste-Windows-systemer. I krydsbygningstrinnet foretog vi flere forenklinger, især med henblik på "stille" installation af værktøjer, samt eliminerede den gene, der medførte ydelsesnedgang ved langvarig brug i VM. Resultaterne af vores arbejde blev præsenteret i et separat , hvilket for en kort stund den førende udvikler af Qubes.
Den mest kritiske fase for stabiliteten af gæstesystemet er opstart af Windows, hvor man kan se den velkendte blå skærm (eller endda ikke se den). For de fleste opdagede fejl fandtes der forskellige omgåelsesmuligheder – afslag på Xen-drivere til blokenheder, deaktivering af VM-hukommelsesbalancering, fastsættelse af netværksindstillinger og minimisering af antallet af kerner. Vores samling af gæsteværktøjer installeres og fungerer på en fuldt opdateret Windows 7 og Windows 10 (undtagen qvideo).
Når man går fra et fysisk miljø til et virtuelt, opstår der et problem med aktivering af Windows, når der bruges forudinstallerede OEM-versioner. Sådanne systemer anvender aktivering baseret på licenser, der er indlejret i enheden's UEFI. For korrekt aktivering er det nødvendigt at overføre en af ACPI-sektionerne fra værtsystemet i sin helhed (SLIC-table) og justere andre lidt ved at angive producenten. Xen gør det muligt at konfigurere indholdet af ACPI's ekstra tabeller, men uden at modificere de grundlæggende. En patch fra et lignende projekt, OpenXT, som blev tilpasset til Qubes, hjalp med løsningen. Rettelserne viste sig at være nyttige ikke kun for os og blev overført til Qubes' hovedrepository og Libvirt-biblioteket.
Åbenlyse ulemper ved Windows-integrationens værktøjer inkluderer manglende lydsupport, manglende USB-enheder og kompleksiteten ved mediehåndtering, da der ikke er hardwareunderstøttelse af GPU. Men dette forhindrer ikke brugen af VM til arbejde med kontordokumenter og hindrer ikke kørsel af specifikke virksomhedsapplikationer.
Kravet om at skifte til offline- eller begrænset netværksarbejde efter oprettelsen af en Windows VM-skabelon blev opfyldt ved at oprette de relevante konfigurationer for applikations-VM'er, mens muligheden for selektiv tilslutning af flytbare medier også blev løst ved hjælp af operativsystemets standardfunktioner — ved tilslutning er de tilgængelige i system-VM'en sys-usb, hvorfra de kan "skydes" til den nødvendige VM. Brugerens skrivebord ser cirka sådan ud.
Den endelige version af systemet er positivt (så godt som et så komplekst system tillader) modtaget af brugerne, og systemets standardværktøjer har gjort det muligt at udvide anvendelsen til brugerens mobile arbejdsplads med adgang via VPN.
Afslutning
Virtualisering generelt gør det muligt at reducere risiciene ved brug af Windows-systemer, der ikke længere er understøttet — den tvinger ikke til at sikre kompatibilitet med ny hardware, gør det muligt at udelukke eller kontrollere adgangen til systemet via netværk eller tilsluttede enheder og giver mulighed for at etablere et miljø til engangsbrug.
Qubes OS, baseret på idéen om isolering gennem virtualisering, hjælper med at udnytte disse og andre mekanismer til at sikre sikkerhed. Udefra set ser mange Qubes hovedsageligt som en stræben efter anonymitet, men det er et nyttigt system for både ingeniører, som ofte kombinerer projekter, infrastruktur og adgangshemmeligheder, samt for sikkerhedsforskere. Opdeling af applikationer, data og formaliseret interaktion mellem dem er indledende skridt til trusselanalyse og design af et beskyttelsessystem. En sådan opdeling hjælper med at strukturere information og reducere fejltagelser forårsaget af menneskelige faktorer - haste, træthed osv.
I øjeblikket er hovedfokus i udviklingen på at udvide funktionaliteten af Linux-miljøer. En version 4.1 er på vej, som vil være baseret på Fedora 31 og inkludere opdaterede versioner af de centrale komponenter Xen og Libvirt. Det bør bemærkes, at Qubes udvikles af fagfolk inden for informationssikkerhed, som hurtigt udgiver opdateringer, når nye trusler eller fejl opdages.
Efterord
En af de eksperimentelle funktioner, vi udvikler, gør det muligt at oprette VM med support til gæsteadgang til GPU baseret på Intel GVT-g teknologi, hvilket gør det muligt at udnytte grafikkortets kapaciteter og markant udvide systemets anvendelsesområde. På tidspunktet for denne artikels skrivning fungerer denne funktionalitet for testversioner af Qubes 4.1 og er tilgængelig på .
Kilde: habr.com
