Niewiele jest artykułów na temat Habré poświęconych systemowi operacyjnemu Qubes, a te, które widziałem, nie opisują zbyt wiele z doświadczeń związanych z jego używaniem. Poniżej mam nadzieję to skorygować na przykładzie wykorzystania Qubesa jako środka ochrony (przed) środowiskiem Windows i jednocześnie oszacować liczbę rosyjskojęzycznych użytkowników systemu.
Dlaczego Quby?
Historia końca wsparcia technicznego dla Windows 7 i rosnący niepokój użytkowników spowodowała konieczność zorganizowania pracy tego systemu z uwzględnieniem następujących wymagań:
- zapewnić korzystanie z w pełni aktywowanego systemu Windows 7 z możliwością instalowania przez użytkownika aktualizacji i różnych aplikacji (w tym przez Internet);
- wdrożyć całkowite lub selektywne wykluczanie interakcji sieciowych na podstawie warunków (tryby pracy autonomicznej i filtrowania ruchu);
- zapewniają możliwość selektywnego podłączania nośników i urządzeń wymiennych.
Ten zestaw ograniczeń zakłada wyraźnie przygotowanego użytkownika, gdyż dozwolona jest niezależna administracja, a ograniczenia nie są związane z blokowaniem jego potencjalnych działań, ale z wykluczeniem ewentualnych błędów lub destrukcyjnych efektów oprogramowania. Te. W modelu nie ma sprawcy wewnętrznego.
W poszukiwaniu rozwiązania szybko porzuciliśmy pomysł wprowadzania ograniczeń za pomocą wbudowanych lub dodatkowych narzędzi systemu Windows, gdyż dość trudno jest skutecznie ograniczyć użytkownika z uprawnieniami administratora, pozostawiając mu możliwość instalowania aplikacji.
Kolejnym rozwiązaniem była izolacja za pomocą wirtualizacji. Dobrze znane narzędzia do wirtualizacji pulpitu (na przykład takie jak virtualbox) słabo nadają się do rozwiązywania problemów związanych z bezpieczeństwem, a wymienione ograniczenia będą musiały zostać wykonane przez użytkownika poprzez ciągłe przełączanie lub dostosowywanie właściwości wirtualnej maszyny gościa (zwanej dalej jako VM), co zwiększa ryzyko błędów.
Jednocześnie mieliśmy doświadczenie w używaniu Qubesa jako systemu komputerowego użytkownika, ale mieliśmy wątpliwości co do stabilności pracy z systemem gościnnym. Postanowiono sprawdzić aktualną wersję Qubesa, gdyż podane ograniczenia bardzo dobrze wpisują się w paradygmat tego systemu, szczególnie w zakresie implementacji szablonów maszyn wirtualnych i integracji wizualnej. Następnie postaram się pokrótce opowiedzieć o pomysłach i narzędziach Qubesa na przykładzie rozwiązania problemu.
Rodzaje wirtualizacji Xen
Qubes opiera się na hypervisorze Xen, co minimalizuje funkcje zarządzania zasobami procesora, pamięcią i maszynami wirtualnymi. Cała inna praca z urządzeniami koncentruje się w dom0 opartym na jądrze Linuksa (Qubes dla dom0 korzysta z dystrybucji Fedory).
Xen obsługuje kilka typów wirtualizacji (podam przykłady dla architektury Intel, chociaż Xen obsługuje inne):
- parawirtualizacja (PV) – tryb wirtualizacji bez użycia wsparcia sprzętowego, przypominający wirtualizację kontenerów, może być zastosowany dla systemów z dostosowanym jądrem (w tym trybie działa dom0);
- pełna wirtualizacja (HVM) - w tym trybie wykorzystywana jest obsługa sprzętowa zasobów procesora, a cały pozostały sprzęt jest emulowany za pomocą QEMU. Jest to najbardziej uniwersalny sposób uruchamiania różnych systemów operacyjnych;
- parawirtualizacja sprzętu (PVH - ParaVirtualized Hardware) - tryb wirtualizacji wykorzystujący obsługę sprzętu, gdy do pracy ze sprzętem jądro systemu gościa wykorzystuje sterowniki dostosowane do możliwości hypervisora (np. pamięć współdzielona), eliminując potrzebę emulacji QEMU i zwiększenie wydajności we/wy. Jądro Linuksa począwszy od wersji 4.11 może pracować w tym trybie.
Począwszy od Qubesa 4.0 ze względów bezpieczeństwa zrezygnowano ze stosowania trybu parawirtualizacji (m.in. ze względu na znane luki w architekturze Intela, które są częściowo łagodzone poprzez zastosowanie pełnej wirtualizacji); domyślnie używany jest tryb PVH.
W przypadku korzystania z emulacji (tryb HVM) QEMU jest uruchamiany w izolowanej maszynie wirtualnej zwanej stubdomain, zmniejszając w ten sposób ryzyko wykorzystania potencjalnych błędów w implementacji (projekt QEMU zawiera dużo kodu, w tym ze względu na kompatybilność).
W naszym przypadku tego trybu należy używać w systemie Windows.
Obsługa maszyn wirtualnych
W architekturze bezpieczeństwa Qubes jedną z kluczowych możliwości hypervisora jest transfer urządzeń PCI do środowiska gościa. Wykluczenie sprzętu pozwala odizolować część hosta systemu od ataków zewnętrznych. Xen obsługuje to dla trybów PV i HVM, w drugim przypadku wymaga obsługi IOMMU (Intel VT-d) - sprzętowego zarządzania pamięcią dla urządzeń zwirtualizowanych.
Tworzy to kilka systemowych maszyn wirtualnych:
- sys-net, do którego przesyłane są urządzenia sieciowe i który służy jako pomost dla innych maszyn wirtualnych, na przykład tych, które realizują funkcje firewalla lub klienta VPN;
- sys-usb, do którego przesyłane są kontrolery USB i innych urządzeń peryferyjnych;
- sys-firewall, który nie korzysta z urządzeń, ale działa jako zapora sieciowa dla podłączonych maszyn wirtualnych.
Do pracy z urządzeniami USB wykorzystywane są usługi proxy, które zapewniają między innymi:
- dla klasy urządzeń HID (Human Interface Device), wysyłanie poleceń do dom0;
- w przypadku nośników wymiennych przekierowanie woluminów urządzeń na inne maszyny wirtualne (z wyjątkiem dom0);
- przekierowanie bezpośrednio na urządzenie USB (za pomocą USBIP i narzędzi integracyjnych).
W takiej konfiguracji udany atak poprzez stos sieciowy lub podłączone urządzenia może doprowadzić do naruszenia bezpieczeństwa tylko działającej maszyny wirtualnej usługi, a nie całego systemu jako całości. Po ponownym uruchomieniu usługi VM zostanie ona załadowana w oryginalnym stanie.
Narzędzia do integracji maszyn wirtualnych
Istnieje kilka sposobów interakcji z pulpitem maszyny wirtualnej - instalowanie aplikacji w systemie gościa lub emulacja wideo za pomocą narzędzi wirtualizacyjnych. Aplikacje gościnne mogą być różnymi uniwersalnymi narzędziami zdalnego dostępu (RDP, VNC, Spice itp.) lub dostosowanymi do konkretnego hypervisora (takie narzędzia są zwykle nazywane narzędziami gościnnymi). Można również zastosować opcję mieszaną, gdy hiperwizor emuluje wejścia/wyjścia dla systemu gościa i zewnętrznie zapewnia możliwość korzystania z protokołu łączącego wejścia/wyjścia, na przykład takiego jak Spice. Jednocześnie narzędzia zdalnego dostępu zwykle optymalizują obraz, ponieważ wymagają pracy w sieci, co nie wpływa pozytywnie na jakość obrazu.
Qubes udostępnia własne narzędzia do integracji maszyn wirtualnych. Przede wszystkim jest to podsystem graficzny – okna z różnych maszyn wirtualnych wyświetlane są na jednym pulpicie z własną ramką kolorystyczną. Ogólnie narzędzia integracyjne opierają się na możliwościach hypervisora - pamięć współdzielona (tabela grantów Xen), narzędzia powiadamiania (kanał zdarzeń Xen), pamięć współdzielona xenstore i protokół komunikacyjny vchan. Za ich pomocą realizowane są podstawowe komponenty qrexec i qubes-rpc oraz usługi aplikacji - przekierowywanie audio lub USB, przesyłanie plików lub zawartości schowka, wykonywanie poleceń i uruchamianie aplikacji. Możliwe jest ustawienie polityk pozwalających ograniczyć usługi dostępne na maszynie wirtualnej. Poniższy rysunek przedstawia przykład procedury inicjowania interakcji dwóch maszyn wirtualnych.
Tym samym praca w VM odbywa się bez wykorzystania sieci, co pozwala na pełne wykorzystanie autonomicznych VM w celu uniknięcia wycieku informacji. Tak np. realizowana jest separacja operacji kryptograficznych (PGP/SSH), gdy klucze prywatne są używane w izolowanych maszynach wirtualnych i nie wykraczają poza nie.
Szablony, aplikacje i jednorazowe maszyny wirtualne
Cała praca użytkownika w Qubes odbywa się na maszynach wirtualnych. Do ich kontroli i wizualizacji służy główny system hosta. System operacyjny jest instalowany wraz z podstawowym zestawem maszyn wirtualnych opartych na szablonach (TemplateVM). Ten szablon to maszyna wirtualna z systemem Linux oparta na dystrybucji Fedora lub Debian, z zainstalowanymi i skonfigurowanymi narzędziami integracyjnymi oraz dedykowanymi partycjami systemowymi i użytkownikami. Instalacja i aktualizacja oprogramowania odbywa się za pomocą standardowego menedżera pakietów (dnf lub apt) ze skonfigurowanych repozytoriów z obowiązkową weryfikacją podpisu cyfrowego (GnuPG). Celem takich maszyn wirtualnych jest zapewnienie zaufania do maszyn wirtualnych aplikacji uruchamianych na ich podstawie.
Podczas uruchamiania aplikacja VM (AppVM) wykorzystuje migawkę partycji systemowej odpowiedniego szablonu maszyny wirtualnej, a po zakończeniu usuwa tę migawkę bez zapisywania zmian. Dane wymagane przez użytkownika są przechowywane na partycji użytkownika unikalnej dla każdej maszyny wirtualnej aplikacji, która jest zamontowana w katalogu domowym.
Korzystanie z jednorazowych maszyn wirtualnych (disposableVM) może być przydatne z punktu widzenia bezpieczeństwa. Taka VM tworzona jest na podstawie szablonu w momencie uruchamiania i uruchamiana w jednym celu - w celu wykonania jednej aplikacji, kończącej pracę po jej zamknięciu. Jednorazowe maszyny wirtualne mogą być wykorzystywane do otwierania podejrzanych plików, których zawartość może prowadzić do wykorzystania określonych luk w zabezpieczeniach aplikacji. Możliwość uruchomienia jednorazowej maszyny wirtualnej jest zintegrowana z menedżerem plików (Nautilus) i klientem poczty e-mail (Thunderbird).
Maszyny wirtualnej systemu Windows można także użyć do utworzenia szablonu i jednorazowej maszyny wirtualnej, przenosząc profil użytkownika do osobnej sekcji. W naszej wersji taki szablon będzie służył użytkownikowi do zadań administracyjnych i instalacji aplikacji. Na podstawie szablonu zostanie utworzonych kilka maszyn wirtualnych aplikacji - z ograniczonym dostępem do sieci (standardowe możliwości sys-firewall) i w ogóle bez dostępu do sieci (nie jest tworzone wirtualne urządzenie sieciowe). Wszystkie zmiany i aplikacje zainstalowane w szablonie będą dostępne do pracy na tych maszynach wirtualnych, a nawet jeśli zostaną wprowadzone programy do tworzenia zakładek, nie będą one miały dostępu do sieci w celu kompromisu.
Walcz o Windowsa
Opisane powyżej funkcje stanowią podstawę Qubesa i działają dość stabilnie; trudności zaczynają się w systemie Windows. Aby zintegrować system Windows, należy skorzystać z zestawu narzędzi gościa Qubes Windows Tools (QWT), w skład którego wchodzą sterowniki do pracy z Xen, sterownik qvideo oraz zestaw narzędzi do wymiany informacji (przesyłanie plików, schowek). Proces instalacji i konfiguracji jest szczegółowo udokumentowany na stronie projektu, dlatego podzielimy się naszymi doświadczeniami z aplikacją.
Główną trudnością jest zasadniczo brak wsparcia dla opracowanych narzędzi. Key Developers (QWT) wydaje się być niedostępny, a projekt integracji systemu Windows oczekuje na głównego programistę. Dlatego przede wszystkim należało ocenić jego działanie i w razie potrzeby zrozumieć możliwość jego niezależnego wsparcia. Najtrudniejszym do opracowania i debugowania jest sterownik graficzny, który emuluje kartę wideo i wyświetlacz w celu wygenerowania obrazu w pamięci współdzielonej, umożliwiając wyświetlenie całego pulpitu lub okna aplikacji bezpośrednio w oknie systemu hosta. Podczas analizy działania sterownika dostosowaliśmy kod do montażu w środowisku Linux oraz opracowaliśmy schemat debugowania pomiędzy dwoma systemami gościnnymi Windows. Na etapie crossbuildu wprowadziliśmy kilka zmian, które uprościły nam sprawę, głównie w zakresie „cichej” instalacji narzędzi, a także wyeliminowały irytującą degradację wydajności podczas długotrwałej pracy na maszynie wirtualnej. Efekty naszej pracy zaprezentowaliśmy w osobnym wydaniu , więc nie na długo Główny programista Qubes.
Najbardziej krytycznym etapem pod względem stabilności systemu gościa jest uruchomienie systemu Windows, tutaj widać znajomy niebieski ekran (lub nawet go nie widać). W przypadku większości zidentyfikowanych błędów istniały różne obejścia - wyeliminowanie sterowników urządzeń blokowych Xen, wyłączenie równoważenia pamięci maszyny wirtualnej, naprawienie ustawień sieciowych i zminimalizowanie liczby rdzeni. Nasze narzędzia dla gości instalują i działają na w pełni zaktualizowanych systemach Windows 7 i Windows 10 (z wyjątkiem qvideo).
Przy przechodzeniu ze środowiska rzeczywistego do wirtualnego pojawia się problem z aktywacją systemu Windows w przypadku korzystania z preinstalowanych wersji OEM. Takie systemy wykorzystują aktywację w oparciu o licencje określone w UEFI urządzenia. Aby poprawnie przetworzyć aktywację, konieczne jest przetłumaczenie jednej z całych sekcji ACPI systemu hosta (tabela SLIC) na system gościa i niewielka edycja pozostałych, rejestrując producenta. Xen pozwala dostosować zawartość ACPI dodatkowych tabel, ale bez modyfikowania głównych. W rozwiązaniu pomogła łatka z podobnego projektu OpenXT, która została zaadaptowana dla Qubes. Poprawki wydały się przydatne nie tylko nam i zostały przetłumaczone na główne repozytorium Qubes oraz bibliotekę Libvirt.
Oczywiste wady narzędzi integracji systemu Windows obejmują brak obsługi dźwięku, urządzeń USB i złożoność pracy z multimediami, ponieważ nie ma obsługi sprzętowej procesora graficznego. Jednak powyższe nie uniemożliwia wykorzystania VM do pracy z dokumentami biurowymi, ani nie uniemożliwia uruchamiania określonych aplikacji korporacyjnych.
Wymóg przejścia do trybu pracy bez sieci lub z ograniczoną siecią po utworzeniu szablonu maszyny wirtualnej Windows został spełniony poprzez utworzenie odpowiednich konfiguracji maszyn wirtualnych aplikacji, a możliwość selektywnego podłączania nośników wymiennych rozwiązano także za pomocą standardowych narzędzi systemu operacyjnego – po podłączeniu , są one dostępne w systemowej maszynie wirtualnej sys-usb, skąd można je „przekazać” do wymaganej maszyny wirtualnej. Pulpit użytkownika wygląda mniej więcej tak.
Ostateczna wersja systemu została pozytywnie (na ile pozwala na to kompleksowe rozwiązanie) zaakceptowana przez użytkowników, a standardowe narzędzia systemu umożliwiły rozbudowę aplikacji o mobilną stację roboczą użytkownika z dostępem poprzez VPN.
Zamiast zawierania
Wirtualizacja w ogóle pozwala zmniejszyć ryzyko korzystania z systemów Windows pozostawionych bez wsparcia - nie wymusza kompatybilności z nowym sprzętem, pozwala wykluczyć lub kontrolować dostęp do systemu przez sieć lub poprzez podłączone urządzenia, a także pozwala zaimplementuj środowisko jednorazowego uruchomienia.
Opierając się na idei izolacji poprzez wirtualizację, Qubes OS pomaga wykorzystać te i inne mechanizmy bezpieczeństwa. Z zewnątrz wiele osób postrzega Qubes przede wszystkim jako chęć zachowania anonimowości, ale jest to przydatny system zarówno dla inżynierów, którzy często żonglują projektami, infrastrukturami i tajemnicami, aby uzyskać do nich dostęp, jak i dla badaczy bezpieczeństwa. Rozdzielenie aplikacji, danych i sformalizowanie ich interakcji to wstępne kroki analizy zagrożeń i projektowania systemu bezpieczeństwa. Ta separacja pomaga uporządkować informacje i zmniejszyć prawdopodobieństwo błędów spowodowanych czynnikiem ludzkim - pośpiechem, zmęczeniem itp.
Obecnie główny nacisk w rozwoju kładzie się na rozszerzanie funkcjonalności środowisk Linux. Przygotowywana jest do wydania wersja 4.1, która będzie oparta na Fedorze 31 i zawierała aktualne wersje kluczowych komponentów Xen i Libvirt. Warto dodać, że Qubes tworzony jest przez specjalistów ds. bezpieczeństwa informacji, którzy zawsze niezwłocznie publikują aktualizacje w przypadku wykrycia nowych zagrożeń lub błędów.
Posłowie
Jedna z rozwijanych przez nas eksperymentalnych możliwości pozwala nam na tworzenie maszyn wirtualnych z obsługą dostępu gościa do procesora graficznego w oparciu o technologię Intel GVT-g, co pozwala nam wykorzystać możliwości karty graficznej i znacznie rozszerzyć zakres systemu. W chwili pisania tego tekstu ta funkcjonalność działa w przypadku wersji testowych Qubes 4.1 i jest dostępna na stronie .
Źródło: www.habr.com