Qubes OS

A projekt célja

Az első és legfontosabb információ a projekttel kapcsolatban, hogy egyáltalán miért jött létre, mit szeretne megvalósítani. A cél nagyon röviden: egy biztonságos Desktop Operációs Rendszer megalkotása. Ennek megértésben – a már több cikkemben is linkelt – rövid prezentáció segíthet: Qubes-meetup

Felmerülhet a kérdés, hogy miben különbözik ez, a többi egyéb hasonló célt szolgáló megoldástól? Erre ad választ a projekt alapítója – egy blog bejegyzés formájában.

Az egyéb kérdéseket a Gyakran Ismételt Kérdések szekció igyekszik megválaszolni.


Az alábbi ismertető a Qubes OS aktuálisan elérhető legfrissebb stabil – vagy az általam már használhatónak ítélt – verziójáról szól, ami jelenleg a:

Qubes OS 4.1.0


A Qubes OS felépítése

Security by Isolation

A fenti ábra jól szemlélteti a Qubes OS felépítését, aminek alapvető eleme a Xen hypervisor, ami egy biztonságos Type-1 (Bare-metal) virtualizációs réteget biztosít. Ennek segítségével külön-külön virtuális gépek formájában valósítja meg az elkülönítést a rendszer kritikus elemei és az alkalmazásokat futtató AppVM-ek között. Mindezt úgy, hogy közben a különböző AppVM-ben futó alkalmazások ugyan azon a képernyőn jelenjenek meg, sőt lehetőség van egymás közötti biztonságos adatátvitelre is.

Természetesen, ilyen szintű szeparáció biztonságos megvalósításához hardver szintű támogatás is szükséges. A rendszer futtatásához szükséges konkrét hardver követelmények megtalálhatóak a projekt oldalán. Sőt, a fejlesztők és a felhasználók által tesztelt konkrét eszközökkel kapcsolatban a HCL nyújthat további segítséget.

Bare-metal (Type-1) hypervisor

Ahogy ezt már többször is igyekeztem kihangsúlyozni, a rendszer legfontosabb eleme – a virtualizációt és ennek segítségével a szeparációt biztosító hypervisor – esetünkben a Xen.

Hardver szintű támogatással elkülönített rendszer komponensek:

  • dom0

A Xen hypervisor ugyan nem egy másik operációs rendszeren belül fut, de szüksége van eszközmeghajtókra (driver), management szoftverekre, és grafikus felületre is. Ezeket biztosítja a dom0 operációs rendszere, ami a Qubes OS esetében egy – kifejezetten erre a feladatra specializált – Fedora 25 alapokra építkező disztribúció.

A Qubes OS esetében extra biztonsági fícsör, hogy a dom0 nem rendelkezik közvetlen hálózati összeköttetéssel! Így a gyorsan elavuló Fedora 25 sem jelent biztonsági problémát, a hardvertámogatásért felelős komponenseket (Kernel, Xorg) pedig rendszeresen backportolják a fejlesztők.

  • Network

A Qubes egyik legfontosabb  – a fenti ábrán is jól szemléltetett –  biztonsági megoldása, a hálózati eszközök elkülönítése a dom0, illetve az AppVM-ektől. Ezt a Xen hypervisor egyik remek lehetősége,  a PCI Passtrough biztosítja. A megoldás lényege, hogy a fizikai hálózati eszközeinket egy kifejezetten erre a feladatra tervezett virtuális gép típushoz – egy NetVM-hez csatoljuk. Így hatékonyan elszeparálhatjuk a külső hálózatokkal közvetlen kapcsolatot tartó eszközöket (és az ehhez szükséges drivereket) az érzékeny adatokat tartalmazó alkalmazásainktól, és az egész rendszert vezérlő dom0-tól egyaránt.

Template alapú virtuális gépek

Mivel sok virtuális gépet fogunk futtatni, elengedhetetlen fícsör, hogy ezeket ne kelljen külön-külön egyesével frissíteni, karbantartani. Ez a gyakorlatban azt jelenti, hogy a virtuális gépek egy read-only template (itt találhatóak a telepített alkalmazások, és a rendszer szintű beállítások) és egy read-write lehetőséggel bíró virtuális diszket (amin a home könyvtárunk és a VM-enként eltérő konfigurációs állományok találhatóak) is kapnak, ezek összessége adja a virtuális gép teljes file struktúráját.

Ennek technikai megvalósításáról a projekt oldalán találunk bővebb informáviókat.

Ez a megoldás a következő előnyöket biztosítja:

  • nagyságrendekkel kisebb diszk igény,
  • csak egy helyen kell az alkalmazásokat telepíteni/frissíteni,
  • csak egyszer kell a globális (minden VM-re érvényes) beállításokat elvégezni,
  • ‘elronthatatlan’ bináris készlet – ideiglenesen ugyan felülírhatjuk a template-ből kapott állományokat is, ám azok egy reboot után visszaállnak az eredeti állapotra.

Természetesen ennek a megoldásnak ugyan úgy vannak hátrányai is, legfőképp a megnövekedett diszk I/O igény – mivel minden VM ugyan azt a diszk területet akarja egyszerre olvasgatni. Erre azonban a ma már igen elterjedt SSD technológia remek megoldást nyújt. Éppen ezért erősen javasolt is, a hagyományos HDD-kel szemben.

A Qubes OS ‘gyárilag’ a következő template-ek használatát támogatja:

Azonban a lehetőség adott, bárki készíthet egyéb más operációs rendszerekre épülő template-eket is, köszönhetően a template builder-nek. Ennek segítségével készül már több – a közösség által támogatott – megoldás is:

Amellett, hogy a template alapú VM-ek használata a gyakorlatban nagyon hasznos, természetesen lehetőség van egymástól teljesen független (Standalone) VM-ek létrehozására is.

Különböző típusú virtuális gépek futtatásának lehetősége:

  • NetVM

Ez egy speciális feladatot ellátó virtuális gép típus, ez biztosít összeköttetést a fizikai hálózatok és az alkalmazásainkat futtató AppVM-ek között. Legalább egy ilyen típusú VM kell hogy legyen a rendszerünkben. Alapértelmezett telepítés esetén egy ilyen VM (sys-net) jön létre, és ehhez lesz hozzárendelve a gépünkben található összes hálózati eszköz, de természetesen ennél jóval bonyolultabb rendszert is kialakíthatunk, ha a különböző eszközöket (Ethernet, WiFi, 3G) külön-külön NetVM-ekhez rendeljük.

  • USB VM

Ez szintén egy speciális feladatot ellátó virtuális (sys-usb) gép, amihez alapértelmezetten a gépünkben található összes USB támogatásért felelős PCI eszköz hozzá van rendelve. Itt került implementálásra az első USB proxy szolgáltatás is, ami az USB alapú beviteli eszközök biztonságos használatát teszi lehetővé.

  • ProxyVM

A Proxy (vagy Firewall) típusú virtuális gépeket az AppVM-ek és a NetVM(ek) közé csatlakoztatva, még tovább szeparálhatjuk – ezzel még biztonságosabbá téve – a belső virtuális hálózatunkat.

Alapértelmezett telepítés esetén egy ilyen VM (sys-firewall) jön létre. A gyakorlatban azonban magam is több  ProxyVM-et: használok: Whonix (TOR), VPN, vagy épp az AppVM-ek egymás közötti kommunikációjának engedélyezésére.

  • AppVM

Felhasználói szemszögből ez a fajta VM tartalmazza a lényeget: az alkalmazásokat, amiket használni szeretnénk :) Hogy kinek mennyi kell ezekből, az már a felhasználás módjától és a tevékenységeink sokszínűségétől (és biztonsági vonzataitól) függ. Természetesen minél több AppVM fut, annál több erőforrást is igényel, tehát a rendelkezésünkre álló hardver figyelembevételével tervezzük meg, hogy mennyire szeretnénk darabokra szeparálni a digitális életünket.

Az eddig vázolt VM-ek mind PHV – vagyis paravirtualizát környezetben futnak, aminek legfőbb tulajdonsága, hogy az operációs rendszernek erről tudnia kell, azaz egy módosított kernelre van szükség az ilyen környezetben való futáshoz. Ezzel szemben a HVM – vagy ‘Full Virtualization’ – környezetben módosítás nélkül futtathatunk szinte bármilyen operációs rendszert, így lehetőség van olyan operációs rendszerek futtatására is, amik kernelét nem tudjuk/akarjuk módosítani a PHV környezethez. Ilyen például a Windows is.

Ilyen típusú VM esetén lehetséges nem template alapú – azaz Standalone VM-eket is létrehozni.

DVM – Disposable VM

Az eldobható – azaz egyszer használatos – VM-ek segítségével még tovább tudjuk csökkenteni az internetről ránk áradó támadások, vírusok, és egyéb gonosz dolgok káros hatásait. Ez a VM ugyanis a kikapcsolás után végleg megszűnik létezni – az esetleg összeszedett károkozókkal együtt :)

Ez a megoldás kiválóan alkalmas ismeretlen eredetű, vagy akár tudottan ártó jellegű weboldalak felkeresésére, fájlok letöltésére, vírusok ‘tesztelésére’. Mindemellett magánéleti (privacy) szempontból kényes ügyek intézésére is remek megoldás, főleg egy ProxyVM-ben futó TOR/Whonix megoldással kiegészítve.

Ez a VM mindenképpen egy PHV alapú, speciális template-re épülő megoldás, amiből akár több példány is futhat egyszerre, és készíthetünk akár többféle különböző template-et is. Ezeket a többi VM-től függetlenül testreszabhatjuk.

Ezek használatát nagyban megkönnyíti a File kezelőhöz, Evolution-höz. és Firefox-hoz is elérhető plugin, aminek segítségével egy normál AppVM-ből is egyetlen kattintással nyithatunk meg állományokat, weboldalakat egy újonnan indított DVM-ben.

Grafikus VM kezelőfelület

A mára már alapvetőnek számító Qube Manager az 1.0 kiadásban debütált, és mivel azóta csak apróbb változtatásokon esett át, így ezt nem részletezném újra.

Alternatívaként természetesen ott vannak a kezdetektől létező CLI parancsok, és az akár automatizálást is lehetővé tevő SaltStack.

Seamless GUI Integration

Mivel ezt a kifejezést igen nehéz lefordítani, igyekszem elmagyarázni miről is van szó. Nehéz dolog ez azért is, mert a végeredménynek pont az a lényege, hogy a felhasználó számára egyértelmű legyen, hogy melyik alkalmazás melyik VM-ben fut, ám ez mégse jelentsen korlátokat a használhatóságban. Ez a gyakorlatban azt jelenti, hogy minden egyes alkalmazás egy színes ablakkeretet kap. Ez az ablakkeret a színével és az alkalmazást futtató VM nevével van ellátva, de ettől függetlenül ugyan azon a desktop felületen láthatjuk őket, sőt akár copy-paste műveletet is végezhetünk a közöttük, attól függetlenül, hogy valójában külön VM-ben futnak. Persze mindezt látni kell, és máris egyértelmű miről is beszélek :)

Technikai részletek a projekt oldalán

Biztonságos adatátviteli lehetőségek a VM-ek között:

Segítségével lehetőségünk van biztonságos módon állományokat mozgatni anélkül, hogy bármilyen közös eszközt kellene felcsatolnunk az érintett VM-ekben.

A „Seamless GUI Integration” egyik lényeges eleme, hogy Copy-Paste műveleteket is végezhetünk a különböző VM-ek között.

Minden AppVM egy belső virtuális hálózat része. Hogy ezek a virtuális gépek pontosan mit érhessenek el, azt a qubes firewall szabályozza.

Backup & Restore

Nem, a biztonsági mentések fontosságát nem szeretném szajkózni.Úgyis mindenki csak egy őt is érintő adatvesztés után kezd el rendszeres mentéseket készíteni, és általában ez is csak addig tart, amíg az ezzel kapcsolatos rossz emlékek.

A Qubes mindenesetre lehetőséget biztosít a rendszerünk egyszerű és biztonságos mentésére és visszaállítására egyaránt. Itt azért kihangsúlyoznám a működő visszaállítást. A Qubes tesztelése során ugyanis ez a fícsör adta a lehetőséget arra, hogy különösebb probléma (és adatvesztés) nélkül lehessen frissíteni, vagy akár egy régebbi állapotra visszaállni. Az egyéb operációs rendszerek és mentéseikkel kapcsolatban eddig sajnos nem voltak ilyen pozitív tapasztalataim…

Anti Evil Maid

Ez egyfajta TPM implementáció, aminek elsődleges célja az ‘Evil Maid’ tipusú támadások megakadályozása. Bővebb információk a projet oldalán.

Single User Mode – by design

Ez első hallásra ugyan sokkal inkább hiányosságként lehetne értelmezni, ám aki a dom0-hoz hozzáfér, az az összes VM felett korlátlan jogokkal rendelkezik. Emiatt a jelenlegi megoldásokkal nem biztosítható a felhasználók jogainak elkülönítése a dom0-ban. Tehát a Qubes OS csak egyetlen felhasználót feltételez. – ami egy laptop esetében nem is túl elvonatkoztatott dolog.


Természetesen, az itt leírtak csak a főbb tulajdonságokat taglalják. A projekt teljes dokumentációja ennél lényegesen bővebb információkat tartalmaz.

Qubes – 2.0

A hamarosan megjelenő 2.0 kiadás annyi újdonságot tartalmaz, hogy azok taglalása helyett inkább egy összefoglaló jellegű cikk megírása mellett döntöttem, így aki most olvas erről megoldásról először, annak sem kell ‘feleslegesen’ a régi cikkeket is átolvasnia ahhoz hogy képbe kerüljön a Qubes által nyújtott remek lehetőségek összességével. Az is emellett szól, hogy tulajdonképpen ezek már mind dokumentálva vannak a projekt saját wiki oldalán és/vagy a fejlesztők blogján.

Keep reading →

Lifebook S751 (vPro)

Munkáltatómnak köszönhetően, először csak tesztelés céljából,  majd a tesztek sikerén felbuzdulva végül munkaeszközként hozzájutottam egy remek laptophoz: Fujitsu Lifebook S751

A technikai paraméterei – némi marketingömlennyel megfűszerezve – megtalálhatóak a fenti linket követve, így én leginkább a munkám során való használhatóságáról igyekszem megosztani néhány hasznos információt:

Hardver

  • Burkolat

 A gép burkolata teljes egészében műanyag, de a jobbik fajtából, így már első fogásra is érezhetően masszív keretet ad a masinának. Fedőlapja erős és bordázott, ami  praktikus és egyben stílusos is :)

  • Kijelző

Kétféle 14″ matt kijelzővel kapható: a normál 1366 x 768 felbontású, illetve 1600 x 900. Mindkettőhöz volt szerencsém, a különbség közöttük eléggé jelentős, ami viszont az árán is megmutatkozik.

  • Billentyűzet

A billentyűzete igen kényelmes, és nincs túlzsúfolva numerikus kiegészítőkkel.

  • Egyéb perifériák

Jól elhelyezett csatlakozók, kivehető optikai meghajtó, aminek helyére 2. akkumulátor vagy  HDD/SSD meghajtó pakolható. A meleg levegőt – általában igen halkan – hátrafelé fújja.

  • Akkumulátor

Az eddigi tapasztalatok alapján bőven az elvárásokon felül teljesít, hogy meddig az persze csak később derül ki, amikorra valószínűleg már az elavult modellek közé kell hogy soroljuk.

Munkánk során alapvetően Linux-on futó rendszereket üzemeltetünk/fejlesztünk, így a munkaállomásokon és a laptopjainkon is Linux az elsődleges operációs rendszer, tehát alapvető, hogy minden szükséges eszköz megfelelően működjön Linux alatt.

Ubuntu 12.04

Mivel ez az egyik legelterjedtebb disztribúció, ami várhatóan támogatja a legújabb hardvereket is, így ezzel tettem egy első próbát:

A telepítő CD (valójában pendrive) gond nélkül bootolt, a telepítés gyorsan és zökkenőmentesen zajlott, miközben a gép alapvető eszközei egyből – bármiféle izélgetés nélkül – használhatóak voltak. Meg is lepődtem rendesen, amikor a telepítés végén a felhasználóhoz rendelhető szokásos avatarok mellett ott láttam magamat is: a beépített kamerával azonnal készíthettem volna képet magamról, hogy saját avatarom lehessen :)

Mivel nem a telepítés és az Ubuntu testreszabásának ismertetése a cél, így inkább lássuk mi van a dobozban, és azt hogyan látja az Ubuntu:

$ uname -a
Linux LIFEBOOK-S751 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller (rev 04) (prog-if 02 [16550])
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) (prog-if 00 [Normal decode])
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4) (prog-if 00 [Normal decode])
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) (prog-if 00 [Normal decode])
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4) (prog-if 00 [Normal decode])
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) (prog-if 01 [AHCI 1.0])
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
0a:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
0b:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI])
0c:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)
0c:00.1 SD Host controller: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)

A PCI eszközökkel semmi gond nem akadt, mindegyikhez volt megfelelő driver a disztribúcióban. Bővebben lásd: dmidecode, lspci, lsusb, lsmod, dmesg és Xorg.log

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 08ff:2683 AuthenTec, Inc. 
Bus 002 Device 004: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 002 Device 006: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
Bus 002 Device 007: ID 0489:e031 Foxconn / Hon Hai 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 004: ID 04f2:b240 Chicony Electronics Co., Ltd

AZ USB-s eszközökkel már más a helyzet, a legtöbbre ugyan nem is lesz szükség, azokat majd a BIOS-ból fogom letiltani, itt most csak a teljesség kedvéért van engedélyezve minden vacak:

  • ID 08ff:2683 AuthenTec, Inc.

Ujjlenyomat olvasó: Vicces dolog, és semmiképp sem nevezhető komoly authentikációnak. Jelszó helyett használni igen nagy merészség (hiszen az egész laptop tele van az ujjlenyomatainkkal), kiegészítőnek lehet vele próbálkozni… Én biztosan nem használom, így nem tudom mennyire működőképes, és hogyan lehet integrálni a rendszerbe.

  • ID 0489:e031 Foxconn / Hon Hai

Bluetooth: Az alap telepítés után nem volt használható. Mivel én ki fogom kapcsolni, így nem is nagyon érdekelt, hogy használható-e egyáltalán Linux alatt.

  • ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader

Elvileg létezik hozzá driver, a gyakorlatban nincs semmilyen kártyám, amivel használni lehetne, így ez is kikapcsolásra kerül.

  • ID 04f2:b240 Chicony Electronics Co., Ltd

Kamera: Ahogy említettem már, Ubuntu alatt egyből használható. Hasznos lehet videó konferenciákra :)

 

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 50:26:90:xx:xx:xx  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 Memory:e2700000-e2720000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:122 errors:0 dropped:0 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:9990 (9.9 KB)  TX bytes:9990 (9.9 KB)

wlan0     Link encap:Ethernet  HWaddr 10:0b:a9:xx:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 MB)  TX bytes:0 (0.0 KB)

Ahogy látható, a legtöbb integrált cumó simán használható Linux alatt. A fenti információk alapján működésre bírhatóak a megfelelő driverekkel bármilyen egyéb disztribúció esetén is. Egyedül a külön kihelyezett gyorsbillentyűk nem működtek – ezekkel majd futok még pár kört.

Qubes OS 1.0

Ahogy az már ismert lehet olvasóim számára, a célom hogy Qubes OS alatt is használható gépet találjak. Ez a speciális operációs rendszer extra igényeket támaszt a hardverekkel kapcsolatban, hogy valóban hardveresen támogatott szeparációt tudjon biztosítani a felhasználóknak. Ez a gép tökéletes hardver a Qubes OS használatához is.

Az alapvető hardver eszközök használhatóságában annak ellenére sincs nagy különbség, hogy ez esetben fedora 17-re épülő rendszerekről beszélünk. Így ezeket nem is igazán részletezném, jöjjön inkább a Qubes specifikus rész.

Mivel Qubes alatt a PCI eszközöket a VM-hez rendelhetjük, így fontos, hogy melyik eszközök függenek egymástól. Az alapvető hálózati interfészek esetében nincs is különösebb probléma, könnyedén megvalósítható, hogy pl: külön Ethernet, és külön WiFi netVM-eket hozzuk létre.

Az izgalmas rész az USB eszközöknél kezdődik, hiszen itt egy-egy USB HUB az, amit egy adott VM-hez tudunk rendelni, így nagyon nem mindegy, hogy melyik eszköz melyik HUB-ra csatlakozik:

00:1a.0    Bus 001
    ID 04f2:b240 Chicony Electronics Co., Ltd

00:1d.0    Bus 002
    ID 0489:e031 Foxconn / Hon Hai 
    ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
    ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
    ID 08ff:2683 AuthenTec, Inc.

0b:00.0    Bus 003

Ebből látszik, hogy ha pl. a kamerát szeretném odaadni valamelyik VM-nek, akkor pontosan melyik PCI eszközt kell az adott VM-hez rendelnünk. Rögtön kiderül ezen működési elv limitációja is: ha pl. a Bluetooth és a SmartCard readert akarnám különbözö VM-ek számára odaadni, akkor azokat egyszerre nem fogom tudni használni…

Erre jön még egy érdekes dolog, a külső USB csatlakozók. Ugyanis ezek is valamelyik HUB-on lógnak, így a HUB-bal együtt ezek is az adott VM alá kerülnek – ami nem feltétlenül cél. Hogy ezzel tisztában legyünk végigpróbálgattam, hogy melyik kivezetés melyik HUB-ra csatlakozik:

Bal oldali csatlakozók:

  • eSATA: Bus 001
  • USB:    Bus 003

Jobb oldali csatlakozók:

  • USB:    Bus 001
  • USB:    Bus 001

Így viszont máris sokkal macerásabb a helyzet, de azért elfogadható kompromisszumok árán pl.: oda lehet adni egyetlen USB külső csatlakozót mondjuk egy mobilnet VM számára, így azt is külön tudjuk kezelni. Ehhez a fenti információk alapján a 003-as USB HUB-ot kell PCI szinten az adott VM-hez rendelni.

Qubes – 1.0

Kiadásra került a Qubes OS 1.0 RC1 verziója. A Telepítő DVD, és a használatához szükséges információk megtalálhatóak a projekt wiki oldalán.

Ez a verzió a Beta3 kiadáshoz képest rengeteg újdonságot tartalmaz:

  • Továbbfejlesztett Qubes VM Manager, aminek segítségével szinte minden (virtuális gépeket érintő) beállítást elvégezhetünk egy könnyen és egyszerűen használható grafikus felületről.
  • Az összes VM egy frissített, Fedora 17 template-en alapul.
  • Továbbfejlesztett és egységesített Dom0 és VM kezelő CLI parancsok.
  • Frissült a Dom0 és a VM-ek kernele is, ami immár a 3.2.7-pvops verzión alapul. Ennek köszönhetően javult a különböző hardver elemek, és az energiatakarékos üzemmódok támogatása.
  • Praktikus újítás, hogy a menüből egyszerűen indíthatunk eldobható (Disposable) VM-eket.
  • Opcionálisan engedélyezhető lett az egyes VM-ek számára a fullscreen üzemmód.
  • Ezeken kívül rengeteg hibát is javítottak az új verzióban…

Mindezen újítások közül a legszembetűnőbb, és talán az egyik legpraktikusabb az új:

VM Manager

Ezen a felületen szinte minden VM műveletet elvégezhetünk:

vm-manager-01

Az általa megjelenített VM tulajdonságokat is a saját igényeinkhez igazíthatjuk:

vm-manager_view

Az összes VM-re vonatkozó globális beállítások:

vm-manager_globalsettings

Egy adott VM-re vonatkozó alapbeállítások:

vm-manager_vm-settings-basic

Egy adott VM-re vonatkozó extra beállítások és információk:

vm-manager_vm-settings-advanced

Ha az adott AppVM egy ProxyVM-en keresztül csatlakozik a fizikai hálózatba, akkor lehetőségünk van tűzfalszabályok definiálására is:

vm-manager_vm-settings-firewall

Egy VM-hez könnyedén hozzárendelhetünk PCI eszközöket is:

vm-manager_vm-settings-devices

Beállíthatjuk, hogy az adott VM-en belül milyen alkalmazások jelenjenek meg a menüben:

vm-manager_vm-settings-apps

Akár szolgáltatásokat is indíthatunk, amik a VM indításakor automatikusan elindulnak majd:

vm-manager_vm-settings-services

Az adott virtuális géphez kapcsolódó beállításokat egy külön menüből is elérhetjük:

vm-manager_vm-settings-vm

Ezek közül igen hasznos a virtuális géphez tartozó naplóállományok megtekintésének lehetősége:

vm-manager_vm-settings-vm-logs

A tervek szerint ez a verzió már a végleges 1.0 lesz – persze a tesztelések során esetlegesen előkerülő hibák javítása után…

A hivatalos bejelentés a fejlesztők blogján olvasható.