Det er ikke mange artikler om Habré viet Qubes-operativsystemet, og de jeg har sett beskriver ikke mye av opplevelsen av å bruke det. Under kuttet håper jeg å korrigere dette ved å bruke eksemplet med å bruke Qubes som et middel for beskyttelse (mot) Windows-miljøet og samtidig anslå antallet russisktalende brukere av systemet.
Hvorfor Qubes?
Historien om slutten av teknisk støtte for Windows 7 og den økende angsten til brukere førte til behovet for å organisere arbeidet til dette operativsystemet, under hensyntagen til følgende krav:
- sikre bruk av fullt aktivert Windows 7 med mulighet for brukeren til å installere oppdateringer og ulike applikasjoner (inkludert via Internett);
- implementere fullstendig eller selektiv utelukkelse av nettverksinteraksjoner basert på forhold (autonom drift og trafikkfiltreringsmoduser);
- gi muligheten til selektivt å koble til flyttbare medier og enheter.
Dette settet med restriksjoner forutsetter en klart forberedt bruker, siden uavhengig administrasjon er tillatt, og begrensningene ikke er relatert til blokkering av potensielle handlinger, men utelukkelse av mulige feil eller ødeleggende programvareeffekter. De. Det er ingen intern lovbryter i modellen.
I vårt søk etter en løsning, forlot vi raskt ideen om å implementere begrensninger ved å bruke innebygde eller ekstra Windows-verktøy, siden det er ganske vanskelig å effektivt begrense en bruker med administratorrettigheter, noe som gir ham muligheten til å installere applikasjoner.
Den neste løsningen var isolasjon ved hjelp av virtualisering. Velkjente verktøy for desktop-virtualisering (for eksempel virtualbox) er dårlig egnet for å løse sikkerhetsproblemer, og de oppførte begrensningene må gjøres av brukeren ved hele tiden å bytte eller justere egenskapene til den virtuelle gjestemaskinen (heretter referert til som VM), noe som øker risikoen for feil.
Samtidig hadde vi erfaring med å bruke Qubes som brukers skrivebordssystem, men var i tvil om stabiliteten ved å jobbe med gjeste-Windows. Det ble besluttet å sjekke gjeldende versjon av Qubes, siden de oppgitte begrensningene passer veldig godt inn i paradigmet til dette systemet, spesielt implementeringen av virtuelle maskinmaler og visuell integrasjon. Deretter vil jeg prøve å kort snakke om ideene og verktøyene til Qubes, ved å bruke eksempelet på å løse problemet.
Typer Xen-virtualisering
Qubes er basert på Xen-hypervisoren, som minimerer funksjonene til å administrere prosessorressurser, minne og virtuelle maskiner. Alt annet arbeid med enheter er konsentrert i dom0 basert på Linux-kjernen (Qubes for dom0 bruker Fedora-distribusjonen).
Xen støtter flere typer virtualisering (jeg vil gi eksempler for Intel-arkitektur, selv om Xen støtter andre):
- paravirtualisering (PV) - en virtualiseringsmodus uten bruk av maskinvarestøtte, som minner om containervirtualisering, kan brukes for systemer med en tilpasset kjerne (dom0 fungerer i denne modusen);
- full virtualisering (HVM) - i denne modusen brukes maskinvarestøtte for prosessorressurser, og alt annet utstyr emuleres ved hjelp av QEMU. Dette er den mest universelle måten å kjøre ulike operativsystemer på;
- paravirtualisering av maskinvare (PVH - ParaVirtualized Hardware) - en virtualiseringsmodus som bruker maskinvarestøtte når gjestesystemkjernen, for å jobbe med maskinvare, bruker drivere tilpasset hypervisorens muligheter (for eksempel delt minne), og eliminerer behovet for QEMU-emulering og øke I/O-ytelsen. Linux-kjernen som starter fra 4.11 kan fungere i denne modusen.
Fra og med Qubes 4.0, av sikkerhetsgrunner, er bruken av paravirtualiseringsmodus forlatt (inkludert på grunn av kjente sårbarheter i Intel-arkitektur, som delvis reduseres ved bruk av full virtualisering); PVH-modus brukes som standard.
Ved bruk av emulering (HVM-modus) lanseres QEMU i en isolert VM kalt stubdomain, og reduserer dermed risikoen for å utnytte potensielle feil i implementeringen (QEMU-prosjektet inneholder mye kode, inkludert for kompatibilitet).
I vårt tilfelle bør denne modusen brukes for Windows.
Tjene virtuelle maskiner
I Qubes sikkerhetsarkitektur er en av hovedfunksjonene til hypervisoren overføring av PCI-enheter til gjestemiljøet. Maskinvareekskludering lar deg isolere vertsdelen av systemet fra eksterne angrep. Xen støtter dette for PV- og HVM-moduser, i det andre tilfellet krever det støtte for IOMMU (Intel VT-d) - maskinvareminneadministrasjon for virtualiserte enheter.
Dette skaper flere virtuelle systemmaskiner:
- sys-net, som nettverksenheter overføres til og som brukes som en bro for andre VM-er, for eksempel de som implementerer funksjonene til en brannmur eller en VPN-klient;
- sys-usb, som USB-kontrollere og andre kontroller for eksterne enheter overføres til;
- sys-firewall, som ikke bruker enheter, men fungerer som en brannmur for tilkoblede VM-er.
For å jobbe med USB-enheter brukes proxy-tjenester, som gir blant annet:
- for enhetsklassen HID (human interface device), sender kommandoer til dom0;
- for flyttbare medier, omdirigering av enhetsvolumer til andre VM-er (unntatt dom0);
- omdirigere direkte til en USB-enhet (ved hjelp av USBIP og integreringsverktøy).
I en slik konfigurasjon kan et vellykket angrep gjennom nettverksstakken eller tilkoblede enheter føre til kompromittering av kun den kjørende tjenesten VM, og ikke hele systemet som helhet. Og etter å ha startet tjeneste-VM på nytt, vil den bli lastet i sin opprinnelige tilstand.
VM-integrasjonsverktøy
Det er flere måter å samhandle med skrivebordet til en virtuell maskin – installere applikasjoner i gjestesystemet eller emulere video ved hjelp av virtualiseringsverktøy. Gjesteapplikasjoner kan være ulike universelle fjerntilgangsverktøy (RDP, VNC, Spice, etc.) eller tilpasset en spesifikk hypervisor (slike verktøy kalles vanligvis gjesteverktøy). Et blandet alternativ kan også brukes når hypervisoren emulerer I/O for gjestesystemet, og eksternt gir muligheten til å bruke en protokoll som kombinerer I/O, for eksempel som Spice. Samtidig optimaliserer fjerntilgangsverktøy vanligvis bildet, siden de innebærer arbeid via et nettverk, noe som ikke har en positiv effekt på bildets kvalitet.
Qubes tilbyr sine egne verktøy for VM-integrasjon. Først av alt er dette et grafikkundersystem - vinduer fra forskjellige VM-er vises på et enkelt skrivebord med sin egen fargeramme. Generelt er integrasjonsverktøy basert på egenskapene til hypervisoren – delt minne (Xen grant table), varslingsverktøy (Xen event channel), delt lagring xenstore og vchan kommunikasjonsprotokollen. Med deres hjelp implementeres de grunnleggende komponentene qrexec og qubes-rpc, og applikasjonstjenester - lyd- eller USB-omdirigering, overføring av filer eller utklippstavleinnhold, utføring av kommandoer og start av applikasjoner. Det er mulig å angi retningslinjer som lar deg begrense tjenestene som er tilgjengelige på en VM. Figuren nedenfor er et eksempel på fremgangsmåten for å initialisere samspillet mellom to VM-er.
Dermed utføres arbeid i VM uten bruk av nettverk, noe som tillater full bruk av autonome VM-er for å unngå informasjonslekkasje. For eksempel er dette hvordan separasjon av kryptografiske operasjoner (PGP/SSH) implementeres, når private nøkler brukes i isolerte VM-er og ikke går utover dem.
Maler, applikasjoner og engangs-VM-er
Alt brukerarbeid i Qubes gjøres i virtuelle maskiner. Hovedvertssystemet brukes til å kontrollere og visualisere dem. OS er installert sammen med et grunnleggende sett med malbaserte virtuelle maskiner (TemplateVM). Denne malen er en Linux VM basert på Fedora- eller Debian-distribusjonen, med integrasjonsverktøy installert og konfigurert, og dedikerte system- og brukerpartisjoner. Installasjon og oppdatering av programvare utføres av en standard pakkebehandling (dnf eller apt) fra konfigurerte depoter med obligatorisk digital signaturverifisering (GnuPG). Formålet med slike VM-er er å sikre tillit til applikasjons-VM-er som er lansert på deres grunnlag.
Ved oppstart bruker en applikasjons-VM (AppVM) et øyeblikksbilde av systempartisjonen til den tilsvarende VM-malen, og sletter dette øyeblikksbildet uten å lagre endringer. Dataene som kreves av brukeren, lagres i en brukerpartisjon som er unik for hver applikasjon VM, som er montert i hjemmekatalogen.
Å bruke engangs-VM-er (disposableVM) kan være nyttig fra et sikkerhetssynspunkt. En slik VM er opprettet basert på en mal på oppstartstidspunktet og lanseres for ett formål - å kjøre en applikasjon, fullføre arbeidet etter at den er lukket. VM-er til engangsbruk kan brukes til å åpne mistenkelige filer hvis innhold kan føre til utnyttelse av spesifikke applikasjonssårbarheter. Muligheten til å kjøre en engangs-VM er integrert i filbehandleren (Nautilus) og e-postklienten (Thunderbird).
Windows VM kan også brukes til å lage en mal og en engangs-VM ved å flytte brukerprofilen til en egen seksjon. I vår versjon vil en slik mal bli brukt av brukeren til administrasjonsoppgaver og applikasjonsinstallasjon. Basert på malen vil flere applikasjons-VM-er opprettes - med begrenset tilgang til nettverket (standard sys-brannmurfunksjoner) og uten tilgang til nettverket i det hele tatt (en virtuell nettverksenhet opprettes ikke). Alle endringer og applikasjoner som er installert i malen vil være tilgjengelige for å fungere i disse VM-ene, og selv om bokmerkeprogrammer blir introdusert, vil de ikke ha nettverkstilgang for kompromiss.
Kjemp for Windows
Funksjonene beskrevet ovenfor er grunnlaget for Qubes og fungerer ganske stabilt; vanskelighetene begynner med Windows. For å integrere Windows må du bruke et sett med gjesteverktøy Qubes Windows Tools (QWT), som inkluderer drivere for arbeid med Xen, en qvideo-driver og et sett med verktøy for informasjonsutveksling (filoverføring, utklippstavle). Installasjons- og konfigurasjonsprosessen er detaljert dokumentert på prosjektets nettside, så vi vil dele vår applikasjonserfaring.
Hovedproblemet er i hovedsak mangelen på støtte for de utviklede verktøyene. Key Developers (QWT) ser ut til å være utilgjengelig og Windows-integrasjonsprosjektet venter på en ledende utvikler. Derfor var det først og fremst nødvendig å vurdere ytelsen og danne en forståelse av muligheten for å støtte den uavhengig, om nødvendig. Den vanskeligste å utvikle og feilsøke er grafikkdriveren, som emulerer videoadapteren og skjermen for å generere et bilde i delt minne, slik at du kan vise hele skrivebordet eller programvinduet direkte i vertssystemvinduet. Under analysen av driverens drift tilpasset vi koden for montering i et Linux-miljø og utarbeidet et feilsøkingsskjema mellom to Windows-gjestesystemer. På kryssbyggingsstadiet gjorde vi flere endringer som forenklet ting for oss, hovedsakelig når det gjelder "stille" installasjon av verktøy, og eliminerte også den irriterende forringelsen av ytelsen når du jobbet i en VM i lang tid. Vi presenterte resultatene av arbeidet vårt i en separat , altså ikke lenge Lead Qubes-utvikler.
Det mest kritiske stadiet når det gjelder stabiliteten til gjestesystemet er oppstarten av Windows, her kan du se den kjente blå skjermen (eller ikke engang se den). For de fleste av de identifiserte feilene var det ulike løsninger – eliminering av Xen-blokk-enhetsdrivere, deaktivering av VM-minnebalansering, fikse nettverksinnstillinger og minimere antall kjerner. Våre gjesteverktøy-bygg installerer og kjører på fullt oppdaterte Windows 7 og Windows 10 (unntatt qvideo).
Når du flytter fra et virkelig miljø til et virtuelt, oppstår det et problem med aktivering av Windows hvis forhåndsinstallerte OEM-versjoner brukes. Slike systemer bruker aktivering basert på lisenser spesifisert i enhetens UEFI. For å behandle aktiveringen riktig, er det nødvendig å oversette en av hele ACPI-delene av vertssystemet (SLIC-tabellen) til gjestesystemet og litt redigere de andre, registrere produsenten. Xen lar deg tilpasse ACPI-innholdet i tilleggstabeller, men uten å endre de viktigste. En patch fra et lignende OpenXT-prosjekt, som var tilpasset Qubes, hjalp til med løsningen. Rettelsene virket nyttige ikke bare for oss og ble oversatt til hoveddepotet for Qubes og Libvirt-biblioteket.
De åpenbare ulempene med Windows-integrasjonsverktøy inkluderer mangelen på støtte for lyd, USB-enheter og kompleksiteten ved å jobbe med media, siden det ikke er maskinvarestøtte for GPU. Men det ovennevnte hindrer ikke bruken av VM for arbeid med kontordokumenter, og det forhindrer heller ikke lanseringen av spesifikke bedriftsapplikasjoner.
Kravet om å bytte til driftsmodus uten nettverk eller med et begrenset nettverk etter å ha opprettet en Windows VM-mal ble oppfylt ved å lage de riktige konfigurasjonene av applikasjons-VM-er, og muligheten for selektivt å koble til flyttbare medier ble også løst av standard OS-verktøy - når tilkoblet , de er tilgjengelige i systemet VM sys-usb, hvorfra de kan "videres" til den nødvendige VM. Brukerens skrivebord ser omtrent slik ut.
Den endelige versjonen av systemet ble positivt (så langt en så omfattende løsning tillater) akseptert av brukerne, og standardverktøyene til systemet gjorde det mulig å utvide applikasjonen til brukerens mobile arbeidsstasjon med tilgang via VPN.
I stedet for en konklusjon
Virtualisering generelt lar deg redusere risikoen ved å bruke Windows-systemer uten støtte - den tvinger ikke kompatibilitet med ny maskinvare, den lar deg ekskludere eller kontrollere tilgang til systemet over nettverket eller gjennom tilkoblede enheter, og den lar deg implementere et engangsoppstartsmiljø.
Basert på ideen om isolasjon gjennom virtualisering, hjelper Qubes OS deg å utnytte disse og andre mekanismer for sikkerhet. Fra utsiden ser mange på Qubes først og fremst som et ønske om anonymitet, men det er et nyttig system både for ingeniører, som ofte sjonglerer med prosjekter, infrastrukturer og hemmeligheter for å få tilgang til dem, og for sikkerhetsforskere. Separasjon av applikasjoner, data og formalisering av deres interaksjon er de første trinnene i trusselanalyse og sikkerhetssystemdesign. Denne separasjonen bidrar til å strukturere informasjon og redusere sannsynligheten for feil på grunn av den menneskelige faktoren - hastverk, tretthet, etc.
For tiden er hovedvekten i utviklingen på å utvide funksjonaliteten til Linux-miljøer. Versjon 4.1 forberedes for utgivelse, som vil være basert på Fedora 31 og inkluderer gjeldende versjoner av nøkkelkomponentene Xen og Libvirt. Det er verdt å merke seg at Qubes er laget av informasjonssikkerhetseksperter som alltid gir ut oppdateringer umiddelbart hvis nye trusler eller feil blir identifisert.
etterord
En av de eksperimentelle egenskapene vi utvikler lar oss lage VM-er med støtte for gjestetilgang til GPU basert på Intel GVT-g-teknologi, som lar oss bruke egenskapene til grafikkadapteren og utvide omfanget av systemet betydelig. I skrivende stund fungerer denne funksjonaliteten for testbygg av Qubes 4.1, og er tilgjengelig på .
Kilde: www.habr.com