Komu się przyda Qubes-OS?

Właśnie zainstalowałem Qubes-OS, czyli namiastkę systemu operacyjnego klasy trusted opartą o separację i wirtualizację, zamiast o security kernel wbudowany w system operacyjny.

Qubes jest we wczesnej wersja alpha, więc nie należy od niego oczekiwać szczególnej przyjazności użytkownikowi. Traktuję go jako proof-of-concept niż jako gotowy produkt. Ciekawe jest nie tyle to, co Qubes już potrafi a raczej to jakie możliwości daje jako punkt wyjściowy do tworzenia nowych rozwiązań.

Qubes jest oparty o wirtualizację - każda aplikacja w systemie może być uruchomiona wewnątrz autonomicznego środowiska wirtualnego i w nim jest zamknięta. Jedno okno przeglądarki możemy mieć otwarte w celu korzystania z bankowości internetowej, w drugim możemy łazić po stronach z exploitami ale jeśli każde z nich uruchomimy w oddzielnym środowisku to nie będą mogły na siebie wpływać. Rzecz jasna, żadne z nich nie będzie mogło także wpływać na środowisko nadrzędne (Dom0 czyli hypervisor).

Brzmi to jak dobre rozwiązanie zwłaszcza dla organizacji, które muszą pracować równocześnie w kilku środowiskach o różnej klasyfikacji niejawności informacji. I chyba dość dobrze pasuje to do zastosowań w administracji publicznej - na przykład w policji swego czasu widziałem na biurkach dwa oddzielne komputery, jeden do sieci publicznej, drugi do sieci niejawnej. Ale nie tylko sektor publiczny - w sektorze prywatnym ten sam pracownik często też równocześnie pracuje na danych mniej (email, WWW) i bardziej (dane osobowe) zastrzeżonych. Dzięki separacji w stylu Qubes można zbudować produkt, który umożliwi bezpieczny dostęp do obu środowisk na jednym fizycznym komputerze.

Dla porównania, systemy z rozbudowanymi funkcjami bezpieczeństwa takie jak SELinux czy GRsecurity działają w oparciu o działający na poziomie kernela reference monitor, który wymusza dostęp do obiektów (pliki, sieć) przez podmioty (aplikacje) zgodnie z opisaną w jakiś sposób polityką bezpieczeństwa. W różnych systemach różnie to działa, ale jeśli przypomnimy sobie słynną dziurę do_brk() w jądrze Linuksa to widać, że implementacja reference monitora jako równoprawnej części jądra systemu operacyjnego nie jest najlepszym pomysłem.

Kilka uwag uruchomieniowych dotyczących Qubes-OS:

• Instalacja jest prosta jeśli prowadzi się ją dokładnie tak jak opisano w Wiki Qubes-OS. Najwięcej czasu zajmuje instalacja Fedory 13 (punkt wyjścia do instalacji paczek Qubes) oraz pobieranie obrazu wzorcowego (template). W trakcie instalacji (pkt VI.6) zobaczyłem błąd, który jej jednak nie przerwał:
  

  Installing: qubes-core-dom0-1.3.4-1.x86_64    4/5
  grep: /etc/NetworkManager/NetworkManager.conf: 
  No such file or directory
  sed: can't read /etc/NetworkManager/NetworkManager.conf: 
  No such file or directory
  service single does not support chkconfig

• Środowisko nadrzędne (Dom0) ma dostęp do sieci tak jak każdy normalny system operacyjny - interfejs sieciowy konfiguruje się ręcznie lub po DHCP.
• Środowisko potomne (AppVM) ma prywatny adres IP - działa to więc chyba podobnie jak NAT w VMWare. Niestety po uruchomieniu konsoli w AppVM nie mogę się połączyć z siecią (patrząc z Dom0 na vif1.0 nie ma żadnego ruchu). A Firefox w AppVM w ogóle się nie uruchamia i wywala taki błąd:
  

  [Dom0] Sorry - KDialog
  
  The remote protocol version is 2, the local protocol 
  version is 3. 
  Upgrade qubes-gui-dom0 (in dom0) and qubes-gui-vm 
  (in template VM) packages so that they provide 
  compatible/latest software. You can run 'xm console 
  vmname' (as root) to access shell prompt in the VM

• Działa przeklejanie tekstu między środowiskiem głównym (Dom0) a środowiskami potomnymi (AppVM).
• Konsola uruchomiona w AppVM nie widzi nic poza swoim środowiskiem, w szczególności nie widzi innych środowisk ani Dom0.

Strona Qubes-OS:

http://qubes-os.org/trac/wiki/InstallationGuide