Der er ikke mange artikler om Habré om Qubes-operativsystemet, og dem, jeg har set, beskriver ikke meget af oplevelsen af at bruge det. Under skæringen håber jeg at rette op på dette ved at bruge eksemplet med at bruge Qubes som et middel til beskyttelse (mod) Windows-miljøet og samtidig estimere antallet af russisktalende brugere af systemet.
Hvorfor Qubes?
Historien om afslutningen på teknisk support til Windows 7 og brugernes stigende angst førte til behovet for at organisere arbejdet med dette operativsystem under hensyntagen til følgende krav:
- sikre brugen af fuldt aktiveret Windows 7 med mulighed for, at brugeren kan installere opdateringer og forskellige applikationer (inklusive via internettet);
- implementere fuldstændig eller selektiv udelukkelse af netværksinteraktioner baseret på betingelser (autonom drift og trafikfiltreringstilstande);
- giver mulighed for selektivt at forbinde flytbare medier og enheder.
Dette sæt begrænsninger forudsætter en klart forberedt bruger, da uafhængig administration er tilladt, og begrænsningerne er ikke relateret til blokering af hans potentielle handlinger, men til udelukkelse af mulige fejl eller ødelæggende softwareeffekter. De der. Der er ingen intern lovovertræder i modellen.
I vores søgen efter en løsning opgav vi hurtigt ideen om at implementere begrænsninger ved hjælp af indbyggede eller yderligere Windows-værktøjer, da det er ret svært effektivt at begrænse en bruger med administratorrettigheder, hvilket giver ham mulighed for at installere applikationer.
Den næste løsning var isolering ved hjælp af virtualisering. Velkendte værktøjer til desktopvirtualisering (f.eks. virtualbox) er dårligt egnede til at løse sikkerhedsproblemer, og de anførte begrænsninger skal udføres af brugeren ved konstant at skifte eller justere egenskaberne for den virtuelle gæstemaskine (herefter refereret til som VM), hvilket øger risikoen for fejl.
Samtidig havde vi erfaring med at bruge Qubes som en brugers desktop-system, men var i tvivl om stabiliteten ved at arbejde med gæste-Windows. Det blev besluttet at tjekke den nuværende version af Qubes, da de angivne begrænsninger passer meget godt ind i dette systems paradigme, især implementeringen af virtuelle maskine skabeloner og visuel integration. Dernæst vil jeg forsøge kort at tale om ideerne og værktøjerne fra Qubes ved at bruge eksemplet med at løse problemet.
Typer af Xen-virtualisering
Qubes er baseret på Xen-hypervisoren, som minimerer funktionerne til styring af processorressourcer, hukommelse og virtuelle maskiner. Alt andet arbejde med enheder er koncentreret i dom0 baseret på Linux-kernen (Qubes for dom0 bruger Fedora-distributionen).
Xen understøtter flere typer virtualisering (jeg vil give eksempler på Intel-arkitektur, selvom Xen understøtter andre):
- paravirtualisering (PV) - en virtualiseringstilstand uden brug af hardwareunderstøttelse, der minder om containervirtualisering, kan bruges til systemer med en tilpasset kerne (dom0 fungerer i denne tilstand);
- fuld virtualisering (HVM) - i denne tilstand bruges hardwaresupport til processorressourcer, og alt andet udstyr emuleres ved hjælp af QEMU. Dette er den mest universelle måde at køre forskellige operativsystemer på;
- paravirtualisering af hardware (PVH - ParaVirtualized Hardware) - en virtualiseringstilstand, der bruger hardwareunderstøttelse, når gæstesystemkernen for at arbejde med hardware bruger drivere tilpasset hypervisorens muligheder (f.eks. delt hukommelse), hvilket eliminerer behovet for QEMU-emulering og øge I/O-ydelsen. Linux-kernen fra 4.11 kan fungere i denne tilstand.
Startende med Qubes 4.0, af sikkerhedsmæssige årsager, er brugen af paravirtualiseringstilstand opgivet (inklusive på grund af kendte sårbarheder i Intel-arkitektur, som delvist afbødes ved brug af fuld virtualisering); PVH-tilstand bruges som standard.
Ved brug af emulering (HVM-tilstand) lanceres QEMU i en isoleret VM kaldet stubdomæne, hvorved risikoen for udnyttelse af potentielle fejl i implementeringen reduceres (QEMU-projektet indeholder en masse kode, herunder for kompatibilitet).
I vores tilfælde skal denne tilstand bruges til Windows.
Service virtuelle maskiner
I Qubes sikkerhedsarkitektur er en af hypervisorens nøglefunktioner overførsel af PCI-enheder til gæstemiljøet. Hardwareekskludering giver dig mulighed for at isolere værtsdelen af systemet fra eksterne angreb. Xen understøtter dette til PV- og HVM-tilstande, i det andet tilfælde kræver det understøttelse af IOMMU (Intel VT-d) - hardwarehukommelsesstyring til virtualiserede enheder.
Dette skaber flere virtuelle systemmaskiner:
- sys-net, hvortil netværksenheder overføres, og som bruges som en bro til andre VM'er, for eksempel dem, der implementerer funktionerne i en firewall eller en VPN-klient;
- sys-usb, hvortil USB og andre perifere enhedscontrollere overføres;
- sys-firewall, som ikke bruger enheder, men fungerer som en firewall for tilsluttede VM'er.
For at arbejde med USB-enheder bruges proxy-tjenester, som blandt andet giver:
- for HID (human interface device) enhedsklassen, sender kommandoer til dom0;
- for flytbare medier, omdirigering af enhedsvolumener til andre VM'er (undtagen dom0);
- omdirigere direkte til en USB-enhed (ved hjælp af USBIP og integrationsværktøjer).
I en sådan konfiguration kan et vellykket angreb gennem netværksstakken eller tilsluttede enheder kun føre til kompromittering af den kørende tjeneste VM, og ikke hele systemet som helhed. Og efter genstart af tjeneste-VM, vil den blive indlæst i sin oprindelige tilstand.
VM integrationsværktøjer
Der er flere måder at interagere med skrivebordet på en virtuel maskine - installation af applikationer i gæstesystemet eller emulering af video ved hjælp af virtualiseringsværktøjer. Gæsteapplikationer kan være forskellige universelle fjernadgangsværktøjer (RDP, VNC, Spice osv.) eller tilpasset til en specifik hypervisor (sådanne værktøjer kaldes normalt gæsteværktøjer). En blandet mulighed kan også bruges, når hypervisoren emulerer I/O for gæstesystemet og eksternt giver mulighed for at bruge en protokol, der kombinerer I/O, f.eks. som Spice. Samtidig optimerer fjernadgangsværktøjer normalt billedet, da de involverer arbejde via et netværk, hvilket ikke har en positiv effekt på billedets kvalitet.
Qubes leverer sine egne værktøjer til VM-integration. Først og fremmest er dette et grafisk undersystem - vinduer fra forskellige VM'er vises på et enkelt skrivebord med deres egen farveramme. Generelt er integrationsværktøjer baseret på hypervisorens muligheder - delt hukommelse (Xen-tildelingstabel), notifikationsværktøjer (Xen-hændelseskanal), delt lager-xenstore og vchan-kommunikationsprotokollen. Med deres hjælp implementeres de grundlæggende komponenter qrexec og qubes-rpc, og applikationstjenester - lyd- eller USB-omdirigering, overførsel af filer eller udklipsholderindhold, udførelse af kommandoer og lancering af applikationer. Det er muligt at indstille politikker, der giver dig mulighed for at begrænse de tjenester, der er tilgængelige på en VM. Nedenstående figur er et eksempel på proceduren til initialisering af interaktionen mellem to VM'er.
Arbejdet i VM'en udføres således uden brug af et netværk, hvilket tillader fuld brug af autonome VM'er for at undgå informationslækage. For eksempel er det sådan, adskillelse af kryptografiske operationer (PGP/SSH) implementeres, når private nøgler bruges i isolerede VM'er og ikke går ud over dem.
Skabeloner, applikationer og engangs-VM'er
Alt brugerarbejde i Qubes udføres i virtuelle maskiner. Hovedværtssystemet bruges til at kontrollere og visualisere dem. OS er installeret sammen med et grundlæggende sæt skabelonbaserede virtuelle maskiner (TemplateVM). Denne skabelon er en Linux VM baseret på Fedora- eller Debian-distributionen, med integrationsværktøjer installeret og konfigureret, og dedikerede system- og brugerpartitioner. Installation og opdatering af software udføres af en standardpakkehåndtering (dnf eller apt) fra konfigurerede lagre med obligatorisk digital signaturverifikation (GnuPG). Formålet med sådanne VM'er er at sikre tillid til applikations VM'er, der er lanceret på deres grundlag.
Ved opstart bruger en applikations-VM (AppVM) et øjebliksbillede af systempartitionen af den tilsvarende VM-skabelon, og efter færdiggørelsen sletter dette snapshot uden at gemme ændringer. De data, der kræves af brugeren, gemmes i en brugerpartition, der er unik for hver applikations-VM, som er monteret i hjemmemappen.
Brug af engangs-VM'er (disposableVM) kan være nyttig ud fra et sikkerhedssynspunkt. En sådan VM oprettes baseret på en skabelon på opstartstidspunktet og lanceres til ét formål - at udføre en applikation, afslutte arbejdet, efter at den er lukket. VM'er til engangsbrug kan bruges til at åbne mistænkelige filer, hvis indhold kan føre til udnyttelse af specifikke applikationssårbarheder. Muligheden for at køre en engangs-VM er integreret i filhåndteringen (Nautilus) og e-mail-klienten (Thunderbird).
Windows VM kan også bruges til at oprette en skabelon og en engangs-VM ved at flytte brugerprofilen til en separat sektion. I vores version vil en sådan skabelon blive brugt af brugeren til administrationsopgaver og applikationsinstallation. Baseret på skabelonen vil der blive oprettet flere applikations-VM'er - med begrænset adgang til netværket (standard sys-firewall-muligheder) og uden adgang til netværket overhovedet (en virtuel netværksenhed oprettes ikke). Alle ændringer og applikationer, der er installeret i skabelonen, vil være tilgængelige for at fungere i disse VM'er, og selvom bogmærkeprogrammer introduceres, vil de ikke have netværksadgang til at gå på kompromis.
Kæmp for Windows
Funktionerne beskrevet ovenfor er grundlaget for Qubes og fungerer ganske stabilt; vanskelighederne begynder med Windows. For at integrere Windows skal du bruge et sæt gæsteværktøjer Qubes Windows Tools (QWT), som inkluderer drivere til at arbejde med Xen, en qvideo-driver og et sæt hjælpeprogrammer til informationsudveksling (filoverførsel, udklipsholder). Installation og konfigurationsprocessen er detaljeret dokumenteret på projektets hjemmeside, så vi deler vores applikationserfaring.
Den største vanskelighed er i det væsentlige manglen på støtte til de udviklede værktøjer. Key Developers (QWT) ser ud til at være utilgængelige, og Windows-integrationsprojektet afventer en ledende udvikler. Derfor var det først og fremmest nødvendigt at vurdere dens præstationer og danne sig en forståelse af muligheden for at støtte den selvstændigt, hvis det var nødvendigt. Den sværeste at udvikle og fejlfinde er grafikdriveren, som emulerer videoadapteren og skærmen for at generere et billede i delt hukommelse, så du kan få vist hele skrivebordet eller programvinduet direkte i værtssystemvinduet. Under analysen af driverens drift tilpassede vi koden til montering i et Linux-miljø og udarbejdede et fejlfindingsskema mellem to Windows-gæstesystemer. På crossbuild-stadiet foretog vi adskillige ændringer, der forenklede tingene for os, hovedsageligt med hensyn til "støjsvag" installation af hjælpeprogrammer, og eliminerede også den irriterende forringelse af ydeevnen, når du arbejdede i en VM i lang tid. Vi præsenterede resultaterne af arbejdet i en separat , altså ikke længe Lead Qubes-udvikler.
Den mest kritiske fase med hensyn til stabiliteten af gæstesystemet er opstarten af Windows, her kan du se den velkendte blå skærm (eller slet ikke se den). For de fleste af de identificerede fejl var der forskellige løsninger - eliminering af Xen-blok-enhedsdrivere, deaktivering af VM-hukommelsesbalancering, rettelse af netværksindstillinger og minimering af antallet af kerner. Vores gæsteværktøjer build installerer og kører på fuldt opdateret Windows 7 og Windows 10 (undtagen qvideo).
Når man flytter fra et rigtigt miljø til et virtuelt, opstår der et problem med aktivering af Windows, hvis der bruges forudinstallerede OEM-versioner. Sådanne systemer bruger aktivering baseret på licenser specificeret i enhedens UEFI. For at behandle aktiveringen korrekt er det nødvendigt at oversætte en af hele ACPI-sektionerne af værtssystemet (SLIC-tabellen) til gæstesystemet og redigere de andre lidt, registrere producenten. Xen giver dig mulighed for at tilpasse ACPI-indholdet i yderligere tabeller, men uden at ændre de vigtigste. En patch fra et lignende OpenXT-projekt, som var tilpasset til Qubes, hjalp med løsningen. Rettelserne virkede nyttige ikke kun for os og blev oversat til Qubes hovedlager og Libvirt-biblioteket.
De åbenlyse ulemper ved Windows-integrationsværktøjer inkluderer manglen på understøttelse af lyd, USB-enheder og kompleksiteten ved at arbejde med medier, da der ikke er hardwareunderstøttelse til GPU'en. Men ovenstående forhindrer ikke brugen af VM'en til at arbejde med kontordokumenter, og det forhindrer heller ikke lanceringen af specifikke virksomhedsapplikationer.
Kravet om at skifte til driftstilstand uden et netværk eller med et begrænset netværk efter oprettelse af en Windows VM-skabelon blev opfyldt ved at oprette de passende konfigurationer af applikations-VM'er, og muligheden for selektivt at forbinde flytbare medier blev også løst af standard OS-værktøjer - når tilsluttet , de er tilgængelige i systemet VM sys-usb, hvorfra de kan "videres" til den nødvendige VM. Brugerens skrivebord ser nogenlunde sådan ud.
Den endelige version af systemet blev positivt (så vidt en sådan omfattende løsning tillader) accepteret af brugerne, og systemets standardværktøjer gjorde det muligt at udvide applikationen til brugerens mobile arbejdsstation med adgang via VPN.
I stedet for en konklusion
Virtualisering i almindelighed giver dig mulighed for at reducere risikoen ved at bruge Windows-systemer uden support - det tvinger ikke kompatibilitet med ny hardware, det giver dig mulighed for at udelukke eller kontrollere adgang til systemet over netværket eller gennem tilsluttede enheder, og det giver dig mulighed for at implementere et engangs-lanceringsmiljø.
Baseret på ideen om isolering gennem virtualisering hjælper Qubes OS dig med at udnytte disse og andre mekanismer til sikkerhed. Udefra ser mange mennesker Qubes primært som et ønske om anonymitet, men det er et nyttigt system både for ingeniører, som ofte jonglerer med projekter, infrastrukturer og hemmeligheder for at få adgang til dem, og for sikkerhedsforskere. Adskillelse af applikationer, data og formalisering af deres interaktion er de indledende trin i trusselsanalyse og sikkerhedssystemdesign. Denne adskillelse hjælper med at strukturere information og reducere sandsynligheden for fejl på grund af den menneskelige faktor - hastværk, træthed osv.
I øjeblikket ligger hovedvægten i udviklingen på at udvide funktionaliteten i Linux-miljøer. Version 4.1 er ved at blive klargjort til udgivelse, som vil være baseret på Fedora 31 og inkludere aktuelle versioner af nøglekomponenterne Xen og Libvirt. Det er værd at bemærke, at Qubes er skabt af informationssikkerhedsprofessionelle, som altid omgående frigiver opdateringer, hvis nye trusler eller fejl identificeres.
efterskrift
En af de eksperimentelle muligheder, vi er ved at udvikle, giver os mulighed for at skabe VM'er med understøttelse af gæsteadgang til GPU'en baseret på Intel GVT-g-teknologi, som giver os mulighed for at bruge grafikadapterens muligheder og udvide systemets omfang betydeligt. I skrivende stund virker denne funktionalitet for testversioner af Qubes 4.1 og er tilgængelig på .
Kilde: www.habr.com