Mamy polską receptę na szpiegów NSA: Qubes OS 3.0 to systemowe podejście do kwestii zaufania

Jak pewnie pamiętacie, fundamentem Qubes OS-a nie było jądroLinuksa, lecz hiperwizorXen, uruchamiający linuksowe maszyny wirtualne, z których każdazajmuje się czymś innym. W ten sposób mamy podzielone na domenyfunkcjonalne maszyny wirtualne interfejsu graficznego, sieci, czypamięci zewnętrznej, mamy też domeny do konkretnych zastosowań,którym przypisane są różne poziomy zaufania. Każda domena ma dziękitemu dostęp tylko do tego, czego faktycznie potrzebuje, co zmniejszapowierzchnię ataku do minimum. Minusem takiego rozwiązania byłyoczywiście problemy z kompatybilnością sprzętową, czy też niemożnośćwykorzystania sprzętowej akceleracji grafiki 3D.

Qubes OS 3.0 wprowadza nową architekturę HAL, która zapewnianiezależność systemu od zastosowanego hiperwizora. Rozwiązaniewirtualizacyjne staje się tu po prostu wykonawcą kluczowych dlaQubesa usług: tworzenia izolowanych bezpiecznych domenfunkcjonalnych, bezpiecznej wirtualizacji interfejsu użytkownika,bezpiecznej komunikacji między domenami i uruchamiania rozmaitychspecjalistycznych maszyn wirtualnych (np. Tora czy GPG). Wprzyszłości nie będzie musiał nim być już Xen, równie dobrze możnazastosować hiperwizor od Microsoftu (Hyper-V), desktopowegoVirtualBoksa, a nawet (w teorii) wbudowany w „okienka” mechanizmWindows Native Isolation. Cel ten udało się to zrealizować dziękibibliotece libvirt. Zamiast bezpośredniego wywoływania poleceń stosuzarządzającego Xena, wykorzystuje się libvirt, która dopiero tłumaczyje na polecenia wybranego hiperwizora. O możliwościach, jakieprzynosi taka elastyczność architektury możecie poczytać na bloguInvisibleThings. [img=QubesOdysseyDiagrams3]Na wprowadzeniu HAL się nie skończyło, w tej wersji systemupojawił się protokół komunikacjimiędzyprocesowej qrexec, hiperwizor Xen w wersji 4.4, oraz wieleszablonów maszyn wirtualnych, w pełni zintegrowanych z Qubesem. Sąwśród nich m.in. Debian 7 i 8, ArchLinux oraz Whonix. Przemyślano teżna nowo kwestię zaufania, kluczową przecież dla przyszłości tegobudzącego coraz większe zainteresowanie projektu. Korzysta onprzecież z gotowych binarnych pakietów, przygotowywanych przezdeweloperów Fedory i Debiana. Czy można być pewnym, że nikt przy nichnie „majstrował”? Jak zabezpieczyć się przednapastnikami, którzy pozyskali klucze wykorzystywane do podpisywaniapakietów? Wreszcie zaś, na jakiej podstawie ufać Rutkowskiej i jejkolegom, że nie mają złośliwych zamiarów?

Jak opisuje Rutkowska, póki co udało się uczynić proces kompilacjioprogramowania na Qubesie odporniejszym na ataki, dzięki możliwościbudowania szablonów Qubesa w czystych, jednorazowych maszynachwirtualnych. W ten sposób można utrzymywać oddzielne repozytoria dlaróżnych szablonów, za które odpowiedzialni są różni ludzie, którymwcale nie trzeba ufać, można dokładnie sprawdzić, co mają w ręku.

Udało się też utrudnić namierzenie procesu budowania, tj.wprowadzenie nawet podpisanych poprawnym kluczem pakietów Fedory czyDebiana z furtką, poprzez wykorzystanie maszyny wirtualnej z Toremjako domyślnej maszyny sieciowej do zbudowania aktualnego obrazu ISOsystemu. Poczyniono też pewne kroki w celu utwardzenia mechanizmówrozpowszechniania i instalacji szablonów, tak by użytkownikowi, któryzainstaluje sobie ze społecznościowych repozytoriów złośliwy szablon,wciąż nic nie groziło. Póki co można sprawdzić skrypty instalacyjne imetadane szablonu przed jego instalacją, w przyszłości cały tenproces ma zostać zautomatyzowany.

Wciąż pozostaje kwestia tego, czy można wierzyć ludziom zInvisible Things Lab. Deweloperzy Qubesa chcą zagwarantować, że wbinarkach Qubes OS-a nie ma żadnych furtek za pomocą „fundamentuzaufania”, w którym przed pobraniem obrazu ISO czy pakietusprawdzane będzie, czy jest on podpisany przez określoną liczbęniezależnych, zaufanych stron. To wymaga jednak deterministycznychkompilacji (czyli uzyskiwania z tego samego kodu źródłowego takichsamych binarek). Prace nad takimmechanizmem prowadzą programiści Debiana, na jego zastosowanie wQubes OS-ie przyjdzie jeszcze poczekać.

Qubes doczekał się także oficjalnegoharmonogramu prac nad kolejnymi wersjami. I tak jeszcze latemmamy zobaczyć wersję 3.1, która przyniesie m.in. uruchamianie namaszynach z UEFI, bezpieczne instalowanie szablonów oraz mechanizmzarządzania i prekonfiguracji, dzięki któremu możliwe będzie zdalnezarządzanie systemem. Na zimę pojawi się Qubes OS 3.2, przynoszącyulepszony interfejs użytkownika i skonfigurowanego już na starcieTora oraz Thunderbirda z obsługą kluczy GPG. Jednocześnie zimąpojawić się ma wersja 4.0, przynosząca kolejne daleko posuniętezmiany w architekturze, w tym core3 – nowy stos zarządzającyQubesa, którego autorami są Wojtek Porczyk i MarekMarczykowski-Górecki, obecnie główny deweloper systemu. Wartowspomnieć, że wydanie 3.0 Qubes OS-a jest pierwszym, którego ISOzostało podpisane już nie przez Joannę Rutkowską, ale właśnie przezMarka Marczykowskiego-Góreckiego.

W dyskusjach w Sieci nie raz pojawiały się opinie, że proponowaneprzez Invisible Things Lab rozwiązania to przesada, a Qubes OS totylko ciekawostka, która nigdy nie znajdzie praktycznegozastosowania. My obserwując rozwój tego systemu niemal od jegopoczątku, jesteśmy przeciwnego zdania – to najbardziejobiecujące podejście do kwestii bezpieczeństwa, które mogłoby stawićczoła nawet narzędziom szpiegowskim wykorzystywanym przezamerykańskie NSA. Jeśli zaś chodzi o wygodę pracy, to naprawdęniewiele można Qubesowi dziś już zarzucić. Przekonać się o tymmożecie sami, pobierając wydanie kandydackie QubesOS 3.