Nuk ka shumë artikuj në Habré kushtuar sistemit operativ Qubes dhe ata që kam parë nuk përshkruajnë shumë nga përvoja e përdorimit të tij. Nën prerjen, shpresoj ta korrigjoj këtë duke përdorur shembullin e përdorimit të Qubes si një mjet mbrojtjeje (kundër) mjedisit Windows dhe, në të njëjtën kohë, të vlerësoj numrin e përdoruesve rusishtfolës të sistemit.
Pse Qubes?
Historia e përfundimit të mbështetjes teknike për Windows 7 dhe ankthi në rritje i përdoruesve çoi në nevojën për të organizuar punën e këtij OS, duke marrë parasysh kërkesat e mëposhtme:
- të sigurojë përdorimin e Windows 7 plotësisht të aktivizuar me aftësinë që përdoruesi të instalojë përditësime dhe aplikacione të ndryshme (përfshirë përmes Internetit);
- të zbatojë përjashtimin e plotë ose selektiv të ndërveprimeve të rrjetit bazuar në kushtet (operimi autonom dhe mënyrat e filtrimit të trafikut);
- ofrojnë mundësinë për të lidhur në mënyrë selektive media dhe pajisje të lëvizshme.
Ky grup kufizimesh presupozon një përdorues të përgatitur qartë, pasi lejohet administrimi i pavarur, dhe kufizimet nuk lidhen me bllokimin e veprimeve të tij të mundshme, por me përjashtimin e gabimeve të mundshme ose efekteve shkatërruese të softuerit. Ato. Nuk ka asnjë shkelës të brendshëm në model.
Në kërkimin tonë për një zgjidhje, ne shpejt braktisëm idenë e zbatimit të kufizimeve duke përdorur mjete të integruara ose shtesë të Windows, pasi është mjaft e vështirë të kufizosh në mënyrë efektive një përdorues me të drejta administratori, duke i lënë atij mundësinë për të instaluar aplikacione.
Zgjidhja tjetër ishte izolimi duke përdorur virtualizimin. Mjetet e njohura për virtualizimin e desktopit (për shembull, si kutia virtuale) nuk janë të përshtatshme për zgjidhjen e problemeve të sigurisë dhe kufizimet e listuara do të duhet të bëhen nga përdoruesi duke ndërruar ose rregulluar vazhdimisht vetitë e makinës virtuale të ftuar (në tekstin e mëtejmë: si VM), gjë që rrit rrezikun e gabimeve.
Në të njëjtën kohë, ne kishim përvojë duke përdorur Qubes si një sistem desktopi të përdoruesit, por kishim dyshime për stabilitetin e punës me Windows-in e ftuar. U vendos që të kontrollohej versioni aktual i Qubes, pasi kufizimet e deklaruara përshtaten shumë mirë në paradigmën e këtij sistemi, veçanërisht implementimi i shablloneve të makinave virtuale dhe integrimi vizual. Më pas do të përpiqem të flas shkurtimisht për idetë dhe mjetet e Qubes, duke përdorur shembullin e zgjidhjes së problemit.
Llojet e virtualizimit Xen
Qubes bazohet në hipervizorin Xen, i cili minimizon funksionet e menaxhimit të burimeve të procesorit, kujtesës dhe makinave virtuale. E gjithë puna tjetër me pajisjet është e përqendruar në dom0 bazuar në kernelin Linux (Qubes për dom0 përdor shpërndarjen Fedora).
Xen mbështet disa lloje të virtualizimit (Unë do të jap shembuj për arkitekturën Intel, megjithëse Xen mbështet të tjerët):
- paravirtualizimi (PV) - një mënyrë virtualizimi pa përdorimin e mbështetjes harduerike, që të kujton virtualizimin e kontejnerëve, mund të përdoret për sistemet me një kernel të përshtatur (dom0 funksionon në këtë mënyrë);
- virtualizimi i plotë (HVM) - në këtë mënyrë, mbështetja e harduerit përdoret për burimet e procesorit, dhe të gjitha pajisjet e tjera emulohen duke përdorur QEMU. Kjo është mënyra më universale për të drejtuar sisteme të ndryshme operative;
- paravirtualizimi i harduerit (PVH - ParaVirtualized Hardware) - një mënyrë virtualizimi duke përdorur mbështetje harduerike kur, për të punuar me harduerin, kerneli i sistemit mysafir përdor drejtues të përshtatur me aftësitë e hipervizorit (për shembull, memoria e përbashkët), duke eliminuar nevojën për emulim QEMU dhe rritjen e performancës I/O. Kerneli Linux duke filluar nga 4.11 mund të funksionojë në këtë mënyrë.
Duke filluar me Qubes 4.0, për arsye sigurie, përdorimi i mënyrës së paravirtualizimit është braktisur (përfshirë për shkak të dobësive të njohura në arkitekturën Intel, të cilat zbuten pjesërisht nga përdorimi i virtualizimit të plotë); modaliteti PVH përdoret si parazgjedhje.
Kur përdorni emulimin (modaliteti HVM), QEMU lëshohet në një VM të izoluar të quajtur stubdomain, duke reduktuar kështu rreziqet e shfrytëzimit të gabimeve të mundshme në zbatim (projekti QEMU përmban shumë kode, përfshirë përputhshmërinë).
Në rastin tonë, kjo mënyrë duhet të përdoret për Windows.
Shërbimi i makinave virtuale
Në arkitekturën e sigurisë Qubes, një nga aftësitë kryesore të hipervizorit është transferimi i pajisjeve PCI në mjedisin e mysafirëve. Përjashtimi i harduerit ju lejon të izoloni pjesën pritëse të sistemit nga sulmet e jashtme. Xen e mbështet këtë për mënyrat PV dhe HVM, në rastin e dytë kërkon mbështetje për IOMMU (Intel VT-d) - menaxhimi i memories harduerike për pajisjet e virtualizuara.
Kjo krijon disa makina virtuale të sistemit:
- sys-net, në të cilën transferohen pajisjet e rrjetit dhe që përdoret si urë për VM-të e tjera, për shembull, ato që zbatojnë funksionet e një muri zjarri ose një klienti VPN;
- sys-usb, tek i cili transferohen USB dhe kontrollorët e tjerë të pajisjeve periferike;
- sys-firewall, i cili nuk përdor pajisje, por funksionon si një mur zjarri për VM-të e lidhura.
Për të punuar me pajisje USB, përdoren shërbimet proxy, të cilat ofrojnë, ndër të tjera:
- për klasën e pajisjes HID (pajisja e ndërfaqes njerëzore), duke dërguar komanda në dom0;
- për media të lëvizshme, ridrejtimi i vëllimeve të pajisjes në VM të tjera (përveç dom0);
- ridrejtimi direkt në një pajisje USB (duke përdorur USBIP dhe mjete integruese).
Në një konfigurim të tillë, një sulm i suksesshëm përmes grupit të rrjetit ose pajisjeve të lidhura mund të çojë në kompromisin vetëm të shërbimit VM që funksionon, dhe jo të gjithë sistemit në tërësi. Dhe pas rinisjes së shërbimit VM, ai do të ngarkohet në gjendjen e tij origjinale.
Mjetet e integrimit të VM
Ka disa mënyra për të bashkëvepruar me desktopin e një makinerie virtuale - instalimi i aplikacioneve në sistemin e mysafirëve ose imitimi i videos duke përdorur mjete virtualizimi. Aplikacionet e vizitorëve mund të jenë mjete të ndryshme universale të aksesit në distancë (RDP, VNC, Spice, etj.) ose të përshtatura për një hipervizor specifik (vegla të tilla zakonisht quhen shërbime të ftuar). Mund të përdoret gjithashtu një opsion i përzier, kur hipervizori emulon I/O për sistemin e ftuar dhe nga jashtë ofron mundësinë për të përdorur një protokoll që kombinon I/O, për shembull, si Spice. Në të njëjtën kohë, mjetet e aksesit në distancë zakonisht optimizojnë imazhin, pasi ato përfshijnë punën përmes një rrjeti, gjë që nuk ka një efekt pozitiv në cilësinë e imazhit.
Qubes ofron mjetet e veta për integrimin e VM. Para së gjithash, ky është një nënsistem grafik - dritaret nga VM të ndryshme shfaqen në një desktop të vetëm me kornizën e tyre të ngjyrave. Në përgjithësi, mjetet e integrimit bazohen në aftësitë e hipervizorit - memoria e përbashkët (tabela e granteve Xen), mjetet e njoftimit (kanali i ngjarjeve Xen), xenstore e përbashkët e ruajtjes dhe protokolli i komunikimit vchan. Me ndihmën e tyre, zbatohen komponentët bazë qrexec dhe qubes-rpc, dhe shërbimet e aplikacionit - ridrejtimi audio ose USB, transferimi i skedarëve ose përmbajtjes së clipboard, ekzekutimi i komandave dhe nisja e aplikacioneve. Është e mundur të vendosni politika që ju lejojnë të kufizoni shërbimet e disponueshme në një VM. Figura më poshtë është një shembull i procedurës për inicializimin e ndërveprimit të dy VM-ve.
Kështu, puna në VM kryhet pa përdorur një rrjet, i cili lejon përdorimin e plotë të VM-ve autonome për të shmangur rrjedhjen e informacionit. Për shembull, kështu zbatohet ndarja e operacioneve kriptografike (PGP/SSH), kur çelësat privatë përdoren në VM të izoluara dhe nuk shkojnë përtej tyre.
Modelet, aplikacionet dhe VM-të një herë
E gjithë puna e përdoruesve në Qubes bëhet në makina virtuale. Sistemi kryesor pritës përdoret për t'i kontrolluar dhe vizualizuar ato. Sistemi operativ është instaluar së bashku me një grup bazë të makinave virtuale të bazuara në shabllon (TemplateVM). Ky shabllon është një VM Linux i bazuar në shpërndarjen Fedora ose Debian, me mjete integrimi të instaluara dhe konfiguruar, si dhe ndarje të sistemit dhe përdoruesve të dedikuar. Instalimi dhe përditësimi i softuerit kryhet nga një menaxher standard i paketave (dnf ose apt) nga depo të konfiguruara me verifikim të detyrueshëm të nënshkrimit dixhital (GnuPG). Qëllimi i VM-ve të tilla është të sigurojë besim në VM-të e aplikacioneve të lançuara në bazë të tyre.
Në fillim, një aplikacion VM (AppVM) përdor një fotografi të ndarjes së sistemit të shabllonit përkatës të VM-së dhe pas përfundimit fshin këtë fotografi pa ruajtur ndryshimet. Të dhënat e kërkuara nga përdoruesi ruhen në një ndarje përdoruesi unike për çdo aplikacion VM, e cila është montuar në direktorinë kryesore.
Përdorimi i VM-ve të disponueshme (disposableVM) mund të jetë i dobishëm nga pikëpamja e sigurisë. Një VM e tillë krijohet bazuar në një shabllon në momentin e fillimit dhe lançohet për një qëllim - për të ekzekutuar një aplikacion, duke përfunduar punën pasi të mbyllet. VM-të e disponueshme mund të përdoren për të hapur skedarë të dyshimtë, përmbajtja e të cilëve mund të çojë në shfrytëzimin e dobësive specifike të aplikacioneve. Aftësia për të ekzekutuar një VM një herë është e integruar në menaxherin e skedarëve (Nautilus) dhe klientin e postës elektronike (Thunderbird).
Windows VM mund të përdoret gjithashtu për të krijuar një shabllon dhe një VM një herë duke lëvizur profilin e përdoruesit në një seksion të veçantë. Në versionin tonë, një shabllon i tillë do të përdoret nga përdoruesi për detyrat e administrimit dhe instalimin e aplikacionit. Bazuar në shabllon, do të krijohen disa VM të aplikacioneve - me akses të kufizuar në rrjet (aftësi standarde të murit të zjarrit të sistemit) dhe pa qasje fare në rrjet (një pajisje rrjeti virtual nuk është krijuar). Të gjitha ndryshimet dhe aplikacionet e instaluara në shabllon do të jenë të disponueshme për të punuar në këto VM dhe edhe nëse futen programet e faqerojtësve, ato nuk do të kenë akses në rrjet për kompromis.
Luftoni për Windows
Karakteristikat e përshkruara më sipër janë baza e Qubes dhe funksionojnë mjaft të qëndrueshme; vështirësitë fillojnë me Windows. Për të integruar Windows, duhet të përdorni një grup veglash të ftuar Qubes Windows Tools (QWT), i cili përfshin drejtuesit për të punuar me Xen, një drejtues qvideo dhe një grup shërbimesh për shkëmbimin e informacionit (transferimi i skedarëve, clipboard). Procesi i instalimit dhe konfigurimit është i dokumentuar në detaje në faqen e internetit të projektit, kështu që ne do të ndajmë përvojën tonë të aplikimit.
Vështirësia kryesore është në thelb mungesa e mbështetjes për mjetet e zhvilluara. Zhvilluesit kryesorë (QWT) duket se nuk janë të disponueshëm dhe projekti i integrimit të Windows është në pritje të një zhvilluesi kryesor. Prandaj, para së gjithash, ishte e nevojshme të vlerësohej performanca e tij dhe të formohej një kuptim për mundësinë e mbështetjes së pavarur, nëse ishte e nevojshme. Më e vështira për t'u zhvilluar dhe korrigjuar është drejtuesi i grafikës, i cili imiton përshtatësin e videos dhe ekranin për të gjeneruar një imazh në kujtesën e përbashkët, duke ju lejuar të shfaqni të gjithë desktopin ose dritaren e aplikacionit direkt në dritaren e sistemit pritës. Gjatë analizës së funksionimit të drejtuesit, ne përshtatëm kodin për montim në një mjedis Linux dhe përpunuam një skemë korrigjimi midis dy sistemeve të ftuar të Windows. Në fazën crossbuild, ne bëmë disa ndryshime që thjeshtuan gjërat për ne, kryesisht në drejtim të instalimit "të heshtur" të shërbimeve, dhe gjithashtu eliminuan degradimin e bezdisshëm të performancës kur punoni në një VM për një kohë të gjatë. Rezultatet e punës sonë i kemi paraqitur në një të veçantë , pra jo për shumë kohë Zhvilluesi kryesor i Qubes.
Faza më kritike për sa i përket stabilitetit të sistemit të mysafirëve është fillimi i Windows, këtu mund të shihni ekranin blu të njohur (ose as të mos e shihni atë). Për shumicën e gabimeve të identifikuara, kishte zgjidhje të ndryshme - eliminimi i drejtuesve të pajisjes së bllokut Xen, çaktivizimi i balancimit të kujtesës VM, rregullimi i cilësimeve të rrjetit dhe minimizimi i numrit të bërthamave. Mjetet tona të ftuar ndërtojnë instalimet dhe funksionojnë në Windows 7 dhe Windows 10 plotësisht të përditësuar (përveç qvideo).
Kur kaloni nga një mjedis real në një mjedis virtual, lind një problem me aktivizimin e Windows nëse përdoren versionet e para-instaluara OEM. Sisteme të tilla përdorin aktivizimin bazuar në licencat e specifikuara në UEFI të pajisjes. Për të përpunuar saktë aktivizimin, është e nevojshme të përktheni një nga të gjitha seksionet ACPI të sistemit pritës (tabela SLIC) në sistemin e ftuar dhe të modifikoni pak të tjerët, duke regjistruar prodhuesin. Xen ju lejon të personalizoni përmbajtjen ACPI të tabelave shtesë, por pa modifikuar ato kryesore. Një patch nga një projekt i ngjashëm OpenXT, i cili u përshtat për Qubes, ndihmoi me zgjidhjen. Rregullimet u dukën të dobishme jo vetëm për ne dhe u përkthyen në depon kryesore të Qubes dhe në bibliotekën Libvirt.
Disavantazhet e dukshme të mjeteve të integrimit të Windows përfshijnë mungesën e mbështetjes për pajisjet audio, USB dhe kompleksitetin e punës me media, pasi nuk ka mbështetje harduerike për GPU. Por sa më sipër nuk pengon përdorimin e VM-së për të punuar me dokumentet e zyrës, as nuk parandalon lëshimin e aplikacioneve specifike të korporatave.
Kërkesa për të kaluar në modalitetin e funksionimit pa rrjet ose me një rrjet të kufizuar pas krijimit të një shablloni të Windows VM u përmbush duke krijuar konfigurimet e duhura të VM-ve të aplikacionit, dhe mundësia e lidhjes selektive të mediave të lëvizshme u zgjidh gjithashtu nga mjetet standarde të OS - kur lidheshin , ato janë të disponueshme në sistemin VM sys-usb, nga ku mund të "përcillen" në VM-në e kërkuar. Desktopi i përdoruesit duket diçka si kjo.
Versioni përfundimtar i sistemit u pranua pozitivisht (për aq sa lejon një zgjidhje e tillë gjithëpërfshirëse) nga përdoruesit, dhe mjetet standarde të sistemit bënë të mundur zgjerimin e aplikacionit në stacionin e punës celular të përdoruesit me akses përmes VPN.
Në vend të një përfundimi
Virtualizimi në përgjithësi ju lejon të zvogëloni rreziqet e përdorimit të sistemeve Windows të mbetur pa mbështetje - nuk detyron përputhshmërinë me harduerin e ri, ju lejon të përjashtoni ose kontrolloni aksesin në sistem përmes rrjetit ose përmes pajisjeve të lidhura, dhe ju lejon të zbatoni një mjedis nisjeje një herë.
Bazuar në idenë e izolimit përmes virtualizimit, Qubes OS ju ndihmon të përdorni këto dhe mekanizma të tjerë për sigurinë. Nga jashtë, shumë njerëz e shohin Qubesin kryesisht si një dëshirë për anonimitet, por është një sistem i dobishëm si për inxhinierët, të cilët shpesh mashtrojnë projektet, infrastrukturat dhe sekretet për t'iu qasur atyre, ashtu edhe për studiuesit e sigurisë. Ndarja e aplikacioneve, të dhënave dhe formalizimi i ndërveprimit të tyre janë hapat fillestarë të analizës së kërcënimit dhe dizajnimit të sistemit të sigurisë. Kjo ndarje ndihmon në strukturimin e informacionit dhe zvogëlimin e gjasave të gabimeve për shkak të faktorit njerëzor - nxitimi, lodhja, etj.
Aktualisht, theksi kryesor në zhvillim është në zgjerimin e funksionalitetit të mjediseve Linux. Versioni 4.1 është duke u përgatitur për lëshim, i cili do të bazohet në Fedora 31 dhe do të përfshijë versionet aktuale të komponentëve kryesorë Xen dhe Libvirt. Vlen të përmendet se Qubes është krijuar nga profesionistë të sigurisë së informacionit, të cilët gjithmonë lëshojnë menjëherë përditësimet nëse identifikohen kërcënime ose gabime të reja.
pasthënje
Një nga aftësitë eksperimentale që po zhvillojmë na lejon të krijojmë VM me mbështetje për aksesin e mysafirëve në GPU bazuar në teknologjinë Intel GVT-g, e cila na lejon të përdorim aftësitë e përshtatësit grafik dhe të zgjerojmë ndjeshëm fushën e sistemit. Në kohën e shkrimit, ky funksionalitet funksionon për versionet testuese të Qubes 4.1 dhe është i disponueshëm në .
Burimi: www.habr.com