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. </ul> Strona Qubes-OS: http://qubes-os.org/trac/wiki/InstallationGuide