Na Habrze nie ma zbyt wielu artykułów poświęconych systemowi operacyjnemu Qubes, a te, które widziałem, słabo opisują doświadczenia z jego użytkowaniem. W dalszej części mam nadzieję to naprawić na przykładzie użycia Qubes jako środka ochrony środowiska Windows i jednocześnie ocenić liczbę użytkowników systemu posługujących się językiem rosyjskim.
Dlaczego Qubes?
Historia z zakończeniem wsparcia technicznego dla Windows 7 oraz rosnąca niepewność użytkowników doprowadziła do potrzeby zorganizowania pracy tego systemu operacyjnego, uwzględniając następujące wymagania:
- zapewnić możliwość korzystania z pełnoprawnej zaktualizowanej Windows 7, z opcją instalacji aktualizacji i różnych aplikacji przez użytkownika (w tym przez Internet);
- zrealizować całkowite lub selektywne wyłączenie interakcji sieciowych na podstawie warunków (tryby pracy offline i filtracji ruchu);
- dostarczyć możliwość selektywnego podłączania nośników wymiennych i urządzeń.
Taki zestaw ograniczeń wymaga wyraźnie przygotowanego użytkownika, ponieważ dozwolone jest samodzielne administrowanie, a ograniczenia nie wynikają z blokowania jego potencjalnych działań, ale z wykluczenia możliwych błędów lub destrukcyjnego działania oprogramowania. Tzn. wewnętrznego naruszyciela w modelu nie ma.
W poszukiwaniu rozwiązania szybko porzuciliśmy pomysł realizacji ograniczeń za pomocą wbudowanych lub dodatkowych narzędzi Windows, ponieważ wystarczająco trudno jest skutecznie ograniczyć użytkownika z uprawnieniami administratora, pozostawiając mu możliwość instalacji aplikacji.
Następną opcją rozwiązania była izolacja za pomocą wirtualizacji. Powszechnie znane narzędzia do wirtualizacji na komputerze (jak na przykład virtualbox) są słabo przystosowane do rozwiązywania zadań związanych z bezpieczeństwem, a wymienione ograniczenia użytkownik będzie musiał ustawiać ciągle, przełączając lub konfigurować właściwości gościnnej maszyny wirtualnej (dalej VM), co zwiększa ryzyko błędów.
Jednocześnie mieliśmy doświadczenie w stosowaniu Qubes jako systemu operacyjnego dla użytkownika, ale pojawiły się wątpliwości co do stabilności działania z gościnnym systemem Windows. Postanowiono sprawdzić aktualną wersję Qubes, ponieważ nałożone ograniczenia doskonale wpisują się w paradygmat tego systemu, a szczególnie w implementację szablonów maszyn wirtualnych i wizualną integrację. Poniżej postaram się w miarę możliwości krótko opisać idee i narzędzia Qubes, na przykładzie rozwiązania postawionego zadania.
Typy wirtualizacji Xen
Qubes bazuje na hipernadzorze Xen, który minimalizuje w sobie funkcje zarządzania zasobami procesora, pamięcią i maszynami wirtualnymi. Cała pozostała praca z urządzeniami koncentruje się w dom0 opartym na jądrze Linux (w Qubes dla dom0 używa się dystrybucji Fedora).
Xen obsługuje kilka typów wirtualizacji (będę podawał przykłady dla architektury Intel, chociaż Xen obsługuje także inne):
- półwirtualizacja (PV) — tryb wirtualizacji bez użycia wsparcia sprzętowego, przypominający wirtualizację kontenerową, może być używany dla systemów z dostosowanym jądrem (w takim trybie działa dom0);
- pełna wirtualizacja (HVM) — w tym trybie dla zasobów procesora wykorzystuje się wsparcie sprzętowe, a cały inny sprzęt jest emulowany za pomocą QEMU. To najbardziej uniwersalny sposób uruchamiania różnych systemów operacyjnych;
- półwirtualizacja sprzętu (PVH — ParaVirtualized Hardware) — tryb wirtualizacji z użyciem wsparcia sprzętowego, w którym do pracy ze sprzętem jądro gościnnego systemu korzysta z driverów dostosowanych do możliwości hipernadzorcy (na przykład pamięci współdzielonej), eliminując potrzebę emulacji przez QEMU i zwiększając wydajność operacji wejścia-wyjścia. Jądro Linux od wersji 4.11 może działać w takim trybie.
Od wersji Qubes 4.0 z powodów bezpieczeństwa rezygnuje się z używania trybu półwirtualizacji (w tym z powodu znanych luk w architekturze Intel, które są częściowo eliminowane dzięki wykorzystaniu pełnej wirtualizacji), domyślnie używany jest tryb PVH.
W trybie emulacji (HVM) uruchomienie QEMU odbywa się w izolowanej maszynie wirtualnej zwanej stubdomain, co zmniejsza ryzyko wykorzystania potencjalnych błędów w implementacji (projekt QEMU zawiera wiele kodu, w tym dla zgodności).
Taki tryb w naszym przypadku należy stosować dla systemu Windows.
Maszyny wirtualne pomocnicze
W architekturze bezpieczeństwa Qubes jedną z kluczowych funkcji hypervisora jest przekazywanie urządzeń PCI do środowiska gościa. Wyjątkowe użycie sprzętu pozwala na izolację części hosta od zewnętrznych ataków. Xen obsługuje to w trybach PV i HVM, w drugim przypadku wymagana jest obsługa IOMMU (Intel VT-d) — sprzętowe zarządzanie pamięcią dla wirtualizowanych urządzeń.
W ten sposób tworzone są różne systemowe maszyny wirtualne:
- sys-net, której przekazywane są urządzenia sieciowe i która służy jako most dla innych VM, na przykład realizujących funkcje zapory lub klienta sieci VPN;
- sys-usb, której przekazywane są kontrolery USB i inne kontrolery urządzeń peryferyjnych;
- sys-firewall, która nie używa urządzeń, a działa jako zapora dla podłączonych VM.
Do obsługi urządzeń USB używane są usługi proxy, które zapewniają m.in.:
- dla klasy urządzeń HID (urządzenie wejściowe) przekazywanie poleceń do dom0;
- dla wymiennych nośników przekazywanie wolumenów urządzeń do innych VM (z wyjątkiem dom0);
- przekazywanie bezpośrednio urządzenia USB (używa USBIP i narzędzi integracyjnych).
W takiej konfiguracji udany atak przez stos sieciowy lub podłączone urządzenia może prowadzić do kompromitacji tylko uruchomionej maszyny wirtualnej pomocniczej, a nie całego systemu. A po ponownym uruchomieniu maszyny wirtualnej pomocniczej będzie ona ładowana w pierwotnym stanie.
Narzędzia integracji VM
Istnieje kilka sposobów interakcji z pulpitami wirtualnej maszyny — instalacja aplikacji w systemie gościa lub emulacja wideo za pomocą technologii wirtualizacji. Jako aplikacje gościa mogą występować różne uniwersalne narzędzia zdalnego dostępu (RDP, VNC, Spice itp.) lub dostosowane do konkretnego hipernadzorcy (te narzędzia zwykle nazywane są narzędziami gości). Możliwa jest również mieszana opcja, w której hipernadzorca emuluje wejście-wyjście dla systemu gościa, a na zewnątrz umożliwia korzystanie z protokołu, który łączy wejście-wyjście, jak w przypadku Spice. Przy tym, narzędzia zdalnego dostępu zazwyczaj optymalizują obraz, ponieważ zakładają pracę przez sieć, co negatywnie wpływa na jakość obrazu.
Qubes oferuje własne środki do integracji WMs. Przede wszystkim to graficzny system — okna z różnych WMs są wyświetlane na jednej pulpicie z unikalnym kolorowym obramowaniem. Ogólnie, narzędzia integracyjne opierają się na możliwościach hipernadzorcy — pamięci dzielonej (Xen grant table), metodach powiadomień (Xen event channel), dzielonym magazynie xenstore i protokole komunikacyjnym vchan. Dzięki nim realizowane są podstawowe komponenty qrexec i qubes-rpc, oraz aplikacyjne usługi — przekierowywanie dźwięku lub USB, transfer plików lub zawartości schowka, wykonywanie poleceń i uruchamianie aplikacji. Istnieje możliwość ustalania polityk ograniczających dostępne usługi na WMs. Na poniższym rysunku przykład procedury inicjalizacji interakcji dwóch WMs.
W ten sposób praca w WMs odbywa się bez korzystania z sieci, co pozwala na pełne wykorzystanie autonomicznych WMs w celu uniknięcia wycieków informacji. Na przykład, w ten sposób realizowane jest rozdzielenie operacji kryptograficznych (PGP/SSH), gdzie klucze prywatne są używane w izolowanych WMs i nie opuszczają ich granic.
Szablony, aplikacyjne i jednorazowe WMs
Wszystkie operacje użytkownika w Qubes odbywają się w maszynach wirtualnych. Główna systemowa maszyna służy do zarządzania ich pracą oraz wizualizacji. System operacyjny jest instalowany z podstawowym zestawem maszyn wirtualnych opartych na szablonach (TemplateVM). Taki szablon jest maszyną wirtualną Linux opartą na dystrybucji Fedora lub Debian, z zainstalowanymi i skonfigurowanymi narzędziami integracyjnymi oraz wyodrębnionymi systemowymi i użytkowników częściami dysku. Instalacja i aktualizacja oprogramowania odbywa się za pomocą wbudowanego menedżera pakietów (dnf lub apt) z skonfigurowanych repozytoriów z obowiązkowym sprawdzeniem podpisu cyfrowego (GnuPG). Celem tych maszyn wirtualnych jest zapewnienie zaufania do aplikacyjnych maszyn wirtualnych uruchamianych na ich podstawie.
Maszyna wirtualna aplikacji (AppVM) przy uruchomieniu używa migawki systemowej odpowiedniego szablonu maszyny wirtualnej, a po zakończeniu działania usuwa tę migawkę bez zachowywania zmian. Niezbędne dane użytkownika są przechowywane w unikalnej części użytkownika dla każdej maszyny wirtualnej aplikacji, która jest montowana w katalogu domowym.
Używanie jednorazowych maszyn wirtualnych (disposableVM) może być korzystne z punktu widzenia bezpieczeństwa. Taka maszyna wirtualna jest tworzona na podstawie szablonu w momencie uruchomienia i działa z jedynym celem – wykonania jednego zastosowania, kończąc swoje działanie po jego zamknięciu. Jednorazowe maszyny wirtualne mogą być używane do otwierania podejrzanych plików, których zawartość może prowadzić do wykorzystania podatności w konkretnych aplikacjach. Możliwość uruchomienia jednorazowej maszyny wirtualnej jest zintegrowana z menedżerem plików (Nautilus) oraz klientem poczty (Thunderbird).
Maszyna wirtualna Windows może być również używana do tworzenia szablonów i jednorazowych maszyn wirtualnych, w tym celu profil użytkownika jest przenoszony do osobnej części. W naszej konfiguracji taki szablon będzie wykorzystywany przez użytkownika 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) oraz bez dostępu do sieci w ogóle (nie jest tworzone wirtualne urządzenie sieciowe). W tych maszynach wirtualnych będą dostępne wszystkie zmiany i aplikacje instalowane w szablonie, a nawet w przypadku wprowadzenia złośliwego oprogramowania, nie będzie miał on dostępu do sieci, co uniemożliwi kompromitację.
Walcząc o Windows
Opisane powyżej funkcje są podstawą Qubes i działają dość stabilnie, trudności zaczynają się z systemem Windows. Aby zintegrować Windows, należy użyć zestawu narzędzi gościa Qubes Windows Tools (QWT), który obejmuje sterowniki do pracy z Xen, sterownik qvideo oraz zestaw narzędzi do wymiany informacji (przesyłanie plików, schowek). Proces instalacji i konfiguracji jest dokładnie udokumentowany na stronie projektu, dlatego podzielimy się naszym doświadczeniem z jego zastosowaniem.
Główną trudnością jest w zasadzie brak wsparcia dla opracowanego narzędzia. Kluczowi deweloperzy (QWT) są najwyraźniej niedostępni, a projekt integracji z Windows czeka na głównego dewelopera. Dlatego najpierw konieczne było ocenienie funkcjonalności i zrozumienie możliwości samodzielnego wsparcia w razie potrzeby. Najbardziej skomplikowanym elementem do opracowania i debugowania jest sterownik graficzny, który emuluje kartę wideo i wyświetlacz do formowania obrazu w pamięci dzielonej, pozwalając wyświetlać cały pulpit lub bezpośrednio okno aplikacji w oknie systemu gospodarza. W trakcie analizy działania sterownika dostosowaliśmy kod do kompilacji w środowisku Linux i opracowaliśmy schemat debugowania między dwoma systemami Windows gości. Na etapie cross-build wprowadziliśmy kilka uproszczeń w głównej mierze w zakresie "cichej" instalacji narzędzi, a także wyeliminowaliśmy natarczywą degradację wydajności podczas długotrwałej pracy w VM. Wyniki naszej pracy przedstawiliśmy w osobnym , tym samym na chwilę głównego dewelopera Qubes.
Najbardziej krytycznym etapem pod względem stabilności systemu gościa jest uruchamianie Windows, tutaj można zobaczyć znany niebieski ekran (lub nawet go nie zobaczyć). Dla większości wykrytych błędów znaleziono różne sposoby obejścia — rezygnacja ze sterowników Xen urządzeń blokowych, wyłączenie równoważenia pamięci VM, ustalenie ustawień sieciowych i minimalizacja liczby rdzeni. Nasza kompilacja narzędzi gości instaluje się i działa na w pełni zaktualizowanym Windows 7 i Windows 10 (z wyjątkiem qvideo).
Przy przejściu z rzeczywistego środowiska do wirtualnego pojawia się problem z aktywacją systemu Windows w przypadku korzystania z preinstalowanych wersji OEM. Takie systemy korzystają z aktywacji opartej na licencjach zapisanych w UEFI urządzenia. Aby aktywacja mogła przebiegać prawidłowo, należy przesłać do systemu gościa jedną z tabel ACPI z systemu gospodarza w całości (tabela SLIC) oraz nieco zmodyfikować inne, wpisując producenta. Xen pozwala na konfigurację zawartości dodatkowych tabel ACPI, ale bez modyfikacji podstawowych. Z pomocą przyszedł patch z podobnego projektu OpenXT, który został dostosowany do Qubes. Poprawki okazały się przydatne nie tylko dla nas i zostały przeniesione do głównego repozytorium Qubes oraz biblioteki Libvirt.
Oczywistymi wadami narzędzi integracji Windows należy wymienić brak wsparcia dla dźwięku, urządzeń USB oraz trudności w pracy z mediami, ponieważ brak jest sprzętowego wsparcia GPU. Jednak to nie przeszkadza w używaniu VM do pracy z dokumentami biurowymi ani nie uniemożliwia uruchamiania specyficznych aplikacji korporacyjnych.
Wymóg przełączenia na tryb pracy offline lub w ograniczonej sieci po utworzeniu szablonu Windows VM realizowano poprzez tworzenie odpowiednich konfiguracji aplikacyjnych VM, a możliwość selektywnego podłączania nośników przenośnych również była rozwiązywana za pomocą standardowych narzędzi systemu operacyjnego — po podłączeniu są one dostępne w systemowej VM sys-usb, skąd mogą być "przekazywane" do potrzebnej VM. Pulpit użytkownika wygląda mniej więcej tak.
Finalna wersja systemu została pozytywnie przyjęta przez użytkowników (na ile pozwala na to tak kompleksowe rozwiązanie), a standardowe narzędzia systemu umożliwiły rozszerzenie zastosowania do mobilnego miejsca pracy użytkownika z dostępem przez VPN.
Zamiast zakończenia
Wirtualizacja w ogóle pozwala na zmniejszenie ryzyka korzystania z systemów Windows, które zostały pozostawione bez wsparcia — nie zmusza do zapewnienia zgodności z nowym sprzętem, pozwala na wykluczanie lub kontrolowanie dostępu do systemu przez sieć lub za pośrednictwem podłączanych urządzeń, oraz pozwala na realizację środowiska do jednorazowego uruchomienia.
System Qubes, based on the idea of isolation through virtualization, helps harness these and other mechanisms to ensure security. From the outside, many see Qubes primarily as a pursuit of anonymity, but it is a useful system for engineers who often juggle projects, infrastructures, and access secrets, as well as for security researchers. Separating applications, data, and formalizing their interactions are initial steps in threat analysis and system design. This separation helps structure information and reduce the likelihood of errors due to human factors like haste, fatigue, etc.
Currently, the main focus of development is on expanding the functionality of Linux environments. Version 4.1 is being prepared for release, which will be based on Fedora 31 and include up-to-date versions of key components Xen and Libvirt. It is worth noting that Qubes is created by professionals in the field of information security, who promptly release updates in case new threats or bugs are identified.
Epilog
One of the experimental features we are developing allows the creation of VMs with guest access to GPUs based on Intel GVT-g technology, enabling the use of graphics adapter capabilities and significantly expanding the system's range of applications. At the time of writing this article, this functionality works for test builds of Qubes 4.1 and is available at .
Źródło: habr.com
