XenClient XT – 3.1

A Citrix XenClient máig az egyetlen desktop virtualizációt célzó kereskedelmi termékcsalád. Korábbi cikkeimben már volt róluk szó, ám akkor még eléggé gyermekcipőben jártak ezen a viszonylag újnak számító területen. Volt is nagy kavarodás (az állítólagos) különböző verziók között, miközben publikusan csak egyetlen verzió volt elérhető, ami akkor XenClient Express néven futott.

Jelenleg ezek a változatok már határozottan külön – de legalábbis ketté – váltak. A továbbiakban a XenClient XT verzióról lesz szó.

Különbségek az XenClient Enterprise változathoz képest

A XenClient XT technikailag sokkal inkább a régi Express változat utódja, felépítésében erősen elválik az Enterpise-től, amiben a fő hangsúlyt a központi management kapta. Ez a változat sokkal inkább a biztonsági megoldásokra koncentrál:

xenclientxt

  • Network Isolation

Ahogy a fenti ábrán is jól látható, a külső hálózatokkal kapcsolatot tartó szolgáltatások – és eszközök! – külön erre a célra dedikált virtuális gépekbe (Service VM) kerültek.

  • Hardened Dom0

A Dom0 operációs rendszere – ami természetesen ez esetben is Linux – SELinux támogatással is rendelkezik.

  • Hardware-assisted security

Az Intel vPro technológiának köszönhetően lehetőség van különböző „hardveresen támogatott biztonsági lehetőségekre” is – ám ezekről ugye nemrég derült ki, hogy valójában inkább beépített backdoor szolgáltatásokat nyújt.

Telepítés

A rendszer telepítése ez esetben is egyszerű, azonban ha szeretnénk komolyabb biztonsági megoldásokat is használni (Trusted Boot, SELinux, XSM), javasolt még a telepítés előtt elolvasni az egyébként remek és bőséges dokumentációhalmazt, amit a termékhez kapunk.

 A motorháztető alatt

A rendszer a 4.1.3 verziójú Xen kernelre épül, a dom0 és a Service VM-ek pedig egy 2.6.32 verziójú SELinux támogatással rendelkező kernelen futnak.

Az Enterprise változathoz képest nem elhanyagolható különbség az sem, hogy nem próbálják meg lehetetlenné tenni a rendszerhez való mélyebb hozzáférést: Crtl + Shift + T – és máris kapunk egy Dom0 terminált :)

Így a rendszer felépítésével és működésével kapcsolatos részletes információkat nem volt nehéz összeszedni – persze azért a Service VM-ekbe való bejutáshoz utána kellett járni néhány nem (publikusan) dokumentált fícsörnek ;)

XenClient Synchronizer

Az Enterprise változathoz hasonlóan természetesen itt is használhatunk központilag létrehozott és karbantartott virtuális gépeket, amihez azonban egy teljesen külön szerver arzenálra lesz szükségünk:

  • Oracle 11g Database Server
  • Citrix License Server
  • Web Server
  • CLI Host

Ezen megoldások telepítése és beállítása is remekül dokumentálva van, így ezekre én most itt nem is térek ki.

 

Ahogy látható, ez a változat valóban a biztonsági megoldásokra helyezi a hangsúlyt. Ezt már érdemben össze is lehetne hasonlítani a Qubes megoldásával, azonban a felhasználó által használható virtuális gépek itt is kizárólag HVM típúsúak lehetnek. Ezzel szemben a Qubes OS Seamless GUI Integration megközelítése sokkal kényelmesebb felhasználói élményt biztosít, lényegesen több biztonsági megoldás mellett! És ráadásul mindezt ingyen – míg a XenClient XT licencköltségei közel sem elhanyagolhatóak.

Ezen kívül sajnos azt sem lehet figyelmen kívül hagyni, hogy a Citrix is ‘csak’ egy amerikai multi, így várhatóan az ő termékei is tartalmaznak az NSA által megrendelt fícsöröket ;)

XenClient Enterprise – 5.0

A Citrix XenClient máig az egyetlen desktop virtualizációt célzó kereskedelmi termékcsalád. Korábbi cikkeimben már volt róluk szó, ám akkor még eléggé gyermekcipőben jártak ezen a viszonylag újnak számító területen. Volt is nagy kavarodás (az állítólagos) különböző verziók között, miközben publikusan csak egyetlen verzió volt elérhető, ami akkor XenClient Express néven futott.

Jelenleg ezek a változatok már határozottan külön – de legalábbis ketté – váltak, a továbbiakban a XenClient Enterprise 5 illetve a XenClient Express  verziókról lesz szó.

Mi a különbség a most tárgyalt két verzió között?

Technikailag semmi, mindkettő ugyan arra a XenClient Engine-re épül. Azonban az Enterprise a nevének megfelelő célközönségnek szól – tehát nagyvállalati felhasználásra. Ennek megfelelően erre is van kihegyezve, legfőbb tulajdonsága a központi felügyeletről szól, és persze nincs ingyen.

A XenClient Express ettől annyiban különbözik, hogy (a megfelelő licencek hiánya miatt) nem képes központi szerverhez csatlakozni, így csak lokális virtuális gépek futtatására alkalmas. Cserébe ingyen használhatjuk – bár az ide vonatkozó licenceket érdemes egy jogásszal értelmeztetni először ;)

1350049701200

XenClient Engine

Ez tulajdonképpen maga a hypervisor – azaz a virtualizációért felelős szoftver, kiegészítve egy grafikus kezelőfelülettel. Mindebből a felhasználók természetesen csak a grafikus kezelőfelületet látják, annyira hogy a lehetőségeink erősen le is vannak korlátozva a következőkre:

  • Felhasználó regisztráció

Nagyvállalati környezetben egy központi, egyébként lokális felhasználó létrehozása.

  • Hálózathoz (WiFi és Ethernet) csatlakozás.

Ez ugye alapvető, hiszen hálózat nélkül nincs is élet :)

  • Beépített alkalmazások használata

Ez egy igen praktikus és hasznos lehetőség, tulajdonképpen olyan előre telepített mini virtuális gépben (Citrix Receiver) futó alkalmazásokról van szó, mint pl: böngésző (google chrome) Remote Desktop kliens…

  • Lokális virtuális gépek létrehozása

Vagyis a lényeg: hogy futtathassunk több egymástól független virtuális gépet :) Fontos azonban, hogy ezeknek semmi közük a központilag létrehozott virtuális gépekhez!

  • Citrix Receiver

Vállalati környezetben ezzel (ami tulajdonképpen egy speciális virtuális gép) kapcsolódhatunk a központi szerverhez, hogy onnan virtuális gépeket töltsünk le, majd használjunk azokat.

Mindezt persze hasonló feltételekkel, mint amit az előző verzióknál is láthattunk, tehát kizárólag HVM guest-ek futtatására képes, bármiféle komolyabb biztonsági megoldást nélkülözve, de lehetőségünk van több virtuális gép egyidejű futtatására. De mindez meg sem közelíti a Qubes OS által nyújtott biztonsági és kényelmi szolgáltatásokat.

Telepítés

A rendszer telepítése nem igényel különösebb szakértelmet, és rengeteg dokumentáció is rendelkezésünkre áll a témában, amihez a linkeket a regisztációt követően el is küldenek számunkra. Regisztrálni pedig mindenképp kell a Citrix oldalán, anélkül ugyanis a telepítőkészletet sem tudjuk letölteni..

 A motorháztető alatt

Egy átlagos felhasználó ezt már el sem olvassa, neki elég hogy szép és működik. Örül, és használja :) Azonban ahogyan az előző verziókat is igyekeztem kibelezni, ennél is pontosan ezt tettem. Annak ellenére, hogy ezt a gyártók igyekeztek „lehetetlenné” tenni. Persze lehetetlen nincs, így ki is derültek a turpisságok.

A rendszer a 4.2.2 verziójú Xen kernelre épül, a dom0 pedig egy 3.8.13-orc verziójú Linux kernelen fut.

Shadow partíciók

ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk1' [128.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk2' [128.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk5' [2.00 GiB]   inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk6' [2.00 GiB]   inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk7' [512.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk8' [512.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk9' [227.63 GiB] inherit

Furcsa, nem dokumentált fícsör. A célja egyelőre ismeretlen, talán valamiféle LVM backup számára fenntartott hely. Az éles rendszer ugyanis így néz ki:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/NxDisk5  2.0G 1003M  878M  54% /
udev                 350M  4.0K  350M   1% /dev
tmpfs                152M  972K  151M   1% /run
none                 5.0M     0  5.0M   0% /run/lock
none                 380M   16K  380M   1% /run/shm
/dev/mapper/NxDisk1  120M   56M   59M  49% /boot
/dev/mapper/NxDisk8  488M  2.5M  460M   1% /var/log
/dev/mapper/NxDisk9  224G  2.0G  211G   1% /nxtop

Beépített backdoor hegyek

#
# Root password
#
ROOT_PASSWD=biker1
# When a fatal error occurs, the installer will put a screen
# that this password can be typed in to access the shell.
# Dont use a $ in the password.
INSTALLER_BACKDOOR_PASSWD="Q"
# Password needed to enable FIST mode
# Dont use a $ in the password.
INSTALLER_FIST_BACKDOOR_PASSWD="f1St"
#
# Encryption
#
DEFAULT_LUKS_PW=9nvnWRHiX0as6gCSRAP

Természetesen mindezt biztosan nem ártó szándékkal csinálják, tutira benne van a több oldalas licenc szerződés valamelyik értelmezhetetlen szövegezésű, apró betűs részében ;)

Ettől függetlenül biztonsági szempontból eléggé kérdéses mindegyik fent látható „fícsör”. Ezek ugyanis a telepítő CD-n is megtalálható install script részletei.

És nem, ezeket később a telepítés során NEM változtatja meg, sőt a default LUKS jelszó sem lesz törölve, miután a felhasználó sajátot állított be:

UUID:          	e631ff96-82af-420c-b5f5-6cb0247f2b8f

Key Slot 0: ENABLED
	Iterations:         	126451
	Salt:               	2d 43 84 fc e3 52 74 6c ed 01 0e 7d 81 55 6b 35 
	                      	de 14 bb f7 8e 33 6b d0 e3 e8 30 55 77 da de 5d 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	127953
	Salt:               	60 a4 45 34 97 76 1e 3c 8a a8 05 6d 03 b6 fd 16 
	                      	5a f1 a7 f2 6f a8 a7 f4 d7 5b d7 49 32 1d 7e 12 
	Key material offset:	264
	AF stripes:            	4000

Kikapcsolt dom0 console

Szintén biztosan egy újabb felhasználóbarát fícsör, hogy még véleltlenül se lehessen (könnyen) felfedezni/megváltoztatni a rendszer azon elemeit, amik a GUI alatt vannak. Természetesen azért mindig van kerülő út, így azért csak sikerült begyűjteni néhány információt a rendszerről ;)

 

XenClient Synchronizer

Vállalati környezetben ez a szerver oldal, aminek segítségével központilag kezelhetjük a felhasználókat, azok munkaállomásait, és az általuk használt virtuális gépeket. Nem meglepő módon ez egy Windows alatt futó alkalmazás, tehát kell alá tenni egy külön szervert, amire előre kell telepíteni egy Hyper-v és egy windows 2008 (vagy 2012) operációs rendszert is. Ezen követelmények miatt, ezt egyelőre nem volt (kedvem) lehetőségem kipróbálni.

Mindezekből is világosan látszik, hogy a célközönség a nagyvállalati környezet, ahol a felhasználóknak semmi köze sem lehet a keze alá adott géphez – még ha az valójában egy hordozható eszköz is. Az is világos, hogy nem a biztonság az első szempont, sokkal inkább a központi management. – Persze ez már így is sokkal biztonságosabb mint egy átlagos „egy oprendszeres” munkaállomás…

Az Express verzió tehát mindennek a lebutított változata, csak véletlenül(?) benne maradt a nagyvállalati környezetben akár fícsörnek is tekinthető vicces backdoor csokor.

 

Firefox, fészbúk és a sütik

Amióta aktívan használom a facebook-ot, folyamatos de nem konzekvensen jelentkező problémákkal találtam szembe magam az oldal elérésével kapcsolatban:

  • nem töltődött be a teljes TimeLine a főoldalon,
  • a legördülő menük nem mindenhol jelentek meg,
  • a képek nézegetésekor nem ugrott fel az ajax-os képnézegető,
  • a chat ablakok és az üzenetek nem minden esetben jelentek meg,
  • nem tudtam ‘lájkolni’ sem az egyéb oldalakat..

Mivel igyekszem magamat (és a böngészőmet, ami jelenleg: Firefox 14.0.1 ) távoltartani a manapság már szinte minden egyes oldal látogatásakor az arcomba nyomuló reklámhalomtól, a kéretlen sütiktől, és a gonosz célokra használt script izéktől egyaránt, ezért szigorú beállításokat, Adblock Plus és NoScript kiegészítőket is használok a mindennapi böngészés során is. Éppen ezért, eleinte ezek együttes hatásának tudtam be a problémákat, de nem volt időm hogy a végére járjak mi is a probléma valójában – Egészen mostanáig:

Mivel Qubes OS van a gépemen ezért viszonylag könnyen és gyorsan sikerült ezt megoldani, úgy hogy teljesen szűz, alapbeállításokkal rendelkező – de ugyan azon verziójú – böngészővel próbálkozhattam, amivel természetesen a fenti problémák nélkül tudtam használni az oldalt.

Aztán persze elszórakoztam vele egy darabig: Adblock kikapcsolás, NoScript kikapcsolás, böngésző beállítások kapcsolgatása – és ezek permutációjával.. mire aztán rájöttem hogy bizonyos sütik el nem fogadása okozza a problémákat:

A fenti kép az egyéb oldalak látogatása esetén probléma nélkül használt beállításaimat mutatja, amiből a lényeg, hogy a „third-party” sütiket nem fogadom szívesen…

Mindemellett ott van az „ask me every time” beállítás is, ami azt eredményezi, hogy minden egyes süti esetén egy felugróablaknak jelenik meg, amiben dönthetek a gépemen elhelyezni kívánt süti sorsáról…

A facebook esetében az az érdekes helyzet áll fent, hogy hiába engedélyezem a „third party” sütiket, az oldal első látogatásakor a www.facebook.com-ról kapok néhány sütit, de a helyzet nem változik: a fent említett problémák ugyan úgy fennállnak, és  látszólag nem is akar máshonnan sütit adni az oldal…

De csak látszólag, ugyanis ha kézzel hozzáadom a ‘www.facebook.com’ URL mellett a ‘facebook.com’ URL-t is a sütik elhelyezését engedélyező listára, akkor egycsapásra megjavul az összes eddig felmerült probléma!

Ha megnézzük pontosan miket kaptunk, akkor is látszik hogy valójában minden süti a facebook.com-ról jön:

Hogy ez a böngésző hibája vagy a facebook küldi rosszul a sütiket? – ezt sajnos egyelőre nem tudom.

Mivel a tapasztalt problémákkal várhatóan csak azon paranoid egyedek találkoznak, akik hozzám hasonlóan eléggé szigorúra állított böngészővel próbálnak netezni, így ez várhatóan nem globális probléma, de ha mégis: a fentiek alkalmazásával gyorsan kiküszöbölhető.

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ó.

Qubes – Beta3

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos desktop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

Úgy tűnik, az egyetlen projekt, ami pontosan ezt tűzte ki célul: a Qubes OS.

A projekt fejlődését régóta nyomon követem, tartottam is már erről egy rövid előadást az az egyik Budapest New Tech Meetup rendezvény keretében, íme az akkori előadásom anyaga, amiből egy gyors, de átfogó képet kaphatunk az alap problémáról, és annak lehetséges megoldásairól.

Most, hogy a projekt az utolsó tesztelési fázisában tart, nézzük milyen lehetőségeket biztosít mindez számunkra a gyakorlatban…

A megoldás

Ahogy a bevezető cikkből, és a rövid előadásomból is kiderülhetett az egyetlen – a gyakorlatban is működő – megoldás: a szeparáció.

A szeparáció alapját ezen projekt esetében is a Xen hypervisor jelenti, ami egy Type1 típusú – azaz közvetlenül a hardveren futó – virtualizációs megoldást biztosít számunkra.

Szemben a Citrix hasonló megoldásával, itt valóban a biztonság a legfontosabb szempont, amihez alapvető elvárás, hogy a Dom0-ban egyáltalán ne legyen hálózatkezelés. Ez ugyanis a rendszer ‘lelke’ – azaz aki ehhez hozzáfér, az teljes jogokkal rendelkezhet az operációs rendszerünk felett, a rajta lévő összes virtuális géppel együtt!

Használatba vétel

Az elmélet szép és jó, át mit sem ér mindez, ha csak beszélünk róla ;) Vegyük hát használatba, és nézzük mit is kapunk valójában:

Tervezés

Igen, ez fontos!

Létezik ugyanis ‘nex-next-finish’ jellegű telepítés is, de így az egésznek semmi értelme nem lesz. Ez ugyanis nem egy windows, hogy sikeresen feltelepítjük, aztán nézzünk körül mi hol van, és irány a fészbúk…

De mégis mit is kellene tervezni??

Ha erre a kérdésre még nem tudod a választ, akkor biztosan nem olvastad el a bevezető cikket, és a  Qubes-ról szóló rövid előadás anyagomat ;)

Tehát, azt szeretnénk, hogy a különböző biztonsági szinten lévő alkalmazásainkat külön-külön, egymástól független környezetben futtathassuk. Persze ne essünk túlzásba – mert a jelenlegi hardverünk azt biztosan nem fogja tolerálni. Jelenleg túlzás (azon felül, hogy egyelőre technikailag sem megoldható) az az igény, hogy minden alkalmazás külön VM-ben fusson… Az pedig kevés, amit egy jelenlegi átlagos operációs rendszer biztosíthat számunkra…

Akkor hol is az arany középút??

Hát, valahol a kettő között ;)

App VM-ek

Ezek az általunk valójában használt virtuális gépek, és ezekben fognak futni a böngészőink, a levelező klienseink, a szövegszerkesztő, és bármi egyéb alkalmazás amit csak használni szeretnénk…

Tehát, ezekből annyi kell, ahány féle dologra használjuk őket. A lényeg a biztonság, tehát  a céges oldalainkhoz a böngészőben ‘megjegyzett’ jelszavaink semmiképp se kerüljenek ki egyéb (nem céges) oldalakra. Így biztosan kell egy céges VM…

A privát adataink (gmail, facebook, blogok, fórumok) már nem olyan kritikusak (vagyis inkább más okból kritikusak) de ezeket sem szeretnénk az átlagos – egyszer látogatott – ismeretlen oldalak számára hozzáférhetővé tenni. Ezért praktikus egy privát célra fenntartott VM-is…

Egyéb, kevésbé fontos weboldalakat lehet hogy egészen más böngésző, (levelező vagy akármi) beállításokkal szeretnénk használni… ezek számára szintén praktikus egy külön VM…

Vannak ezen kívül a teljesen ‘megbízhatatlan’ oldalak – nem is hoznék példákat, biztosan mindenki látott már ilyen-olyan jellegű oldalt, amiről nem tudta (vagy nem is érdekelte) hogy ki üzemelteti ;) De ha ilyet nem is, gyanús levél csatolmányokat biztosan mindenki látott már… Az ilyen ügyeket egy speciális, eldobható (azaz egyszer használatos) úgynevezett ‘Disposable’ VM-ben végezzük…

Ezzel szöges ellentétben, lehet olyan igényünk is, hogy az adott VM semmilyen hálózati eléréssel ne rendelkezzen. Ilyen elszeparált helyen biztonságosan tárolhatjuk jelszavainkat, titkos kulcsainkat, stb…

Service VM-ek

Net VM (ek)

Egyre mindenképp szükségünk lesz, enélkül ugyanis nem fogunk tudni hálózatra csatlakozni.

Egyetlen NetVM használata esetén, az összes hálózati csatolót (ethernet, WiFi, 3G) PCI szinten ehhez a VM-hez rendeljük, és az AppVM-ek ezen keresztül jutnak hálózati eléréshez…

Több NetVM használata akkor indokolt, ha külön szeretnénk választani a különböző hálózati interface-eket – és így akár egyik AppVM etherneten, míg a másik WiFin-keresztül kommunikálhat a külvilággal, anélkül hogy a hálózati adataik bármilyen közös ponton áthaladnának!

Proxy (firewall) VM (ek)

A NetVM-(ek), és az AppVM-ek közé ékelődő, speciális (a NetVM számára AppVM, az AppVM számára pedig NetVM) hálózati tulajdonságokkal megáldott VM-ek, amik biztonságos, és könnyen áttekinthető tűzfal/proxy megoldást nyújthatnak alkalmazásainknak.

A gyakorlatban leginkább VPN kapcsolatok, és/vagy TOR proxy használata esetén van jelentőségük.

Mindebből jól látszik, hogy leginkább tőlünk (és a rendelkezésünkre álló hardver teljesítményétől) függ, hogy miből mennyit hozunk létre, és ezeket pontosan mire használjuk. Így nem lehet látatlanban, mindenki számára megfelelő megoldásokat előre kitalálni…

Hogy mindez érthetőbb legyen, íme a ‘default’ hálózati struktúra:

És íme, egy bonyolultabb (több NetVM-es felállás), amiben még olyan VM is szerepel, aminek egyáltalán nincs internet elérése:

A fenti topológia nem csak példa, nagyjából ez lett megvalósítva a saját laptopomon is…

Telepítés

Maga a telepítés nem egy agyműtét, bárki – aki telepített már valaha valamilyen operációs rendszert – könnyedén elboldogul vele. Aki esetleg közelebbi ismeretségben van a redhat, fedora – vagy ezek leszármazottjaival – annak pedig kifejezetten ismerős lesz az Anaconda telepítő felület.

A sikeres telepítéshez a legfontosabb információkat a projekt wiki oldalán találjuk.

Az izgalmas rész az első boot után következik, ekkor hozhatjuk létre ugyanis a rendszerünk alapvető építőkockáit – a virtuális gépeket. Ezzel kapcsolatban 3 lehetőségünk van:

  • default Service és AppVM-ek létrehozása

Ilyenkor a telepítő elkészíti a (szerinte) szükséges összes virtuális gépet, beleértve a majdan használni kívánt AppVM-eket is – amikben az általunk használni kívánt alkalmazások fognak majd futni. Ez az opció azoknak való, akik szeretnének egyből egy használható rendszert a kezükbe kapni. Azonban én ezt maximum kiindulási alapnak ajánlom, ugyanis biztosan nem a saját igényeinket fogja tükrözni… így pedig valós felhasználásra nem lesz alkalmas a kapott rendszer.

  • csak a Service VM-ek létrehozása

Köztes megoldás, AppVM-eket nem hoz létre, csak a (szerinte) lényeges Service VM-eket. Ezek ugyan sok helyzetben megfelelőek lehetnek, azonban ez sem azt fogja tükrözni amit valóban szeretnénk…

  • semmilyen egyéb VM-et nem kérünk.

Ilyenkor semmi egyéb VM-et nem hoz létre, megkapjuk az üres dom0-át. Ez kell nekünk, hiszen innentől úgy alakítjuk a rendszert, ahogy az nekünk valóban megfelel majd a gyakorlatban is…

VM-ek létrehozása

Ha az előzetes terveinknek megfelelően, saját magunk szeretnénk minden VM-et létrehozni, akkor ezt  (parancssorból) a következőképp tehetjük meg:

[dom0]$ qvm-create Ethernet --net --label orange
[dom0]$ qvm-create Wifi --net --label purple

Majd, hozzáadjuk  a kívánt PCI eszközöket a megfelelő NetVM-hez:

Ezt a qvm-pci paranccsal tehetjük meg, pl:

[dom0]$ qvm-pci -a WiFi `lspci |grep -i Wireless |cut -d ' ' -f1`
[dom0]$ qvm-pci -a Ethernet `lspci |grep -i Ether |cut -d ' ' -f1`

Ezek után, létre kell hoznunk a proxy VM-eket is:

[dom0]$ qvm-create Andrews-VPN --proxy --label gray
[dom0]$ qvm-create Firewall --proxy --label gray
Majd, csatlakoztatni őket a megfelelő NetVM-hez:
[dom0]$ qvm-prefs -s Andrews-VPN netvm Ethernet
[dom0]$ qvm-prefs -s Firewall netvm WiFi

Végül beállítjuk, hogy melyik AppVM melyik proxy VM-hez csatlakozzon :

[dom0]$ qvm-prefs -s Banking netvm Firewall
[dom0]$ qvm-prefs -s Andrews netvm Andrews-VPN
[dom0]$ qvm-prefs -s Vault netvm none
...
Természetesen, a hálózati összerendeléseket később bármikor – akár menet közben is – megváltoztathatjuk, ezzel könnyedén elérve hogy az aktuális helyi adottságokhoz igazítsuk a hálózati kapcsolatainkat…

Finomhangolás

Természetesen, akár melyik telepítési módot is választjuk, szinte minden esetben utólag is módosíthatjuk a VM-ek paramétereit, és egymással való kapcsolatukat. Erre a már használt qvm-prefs parancs használatos… De minderről bővebben később…

Alkalmazások telepítése

Az eddigiekből láthattuk, hogy egy-egy VM létrehozása, és használatba vétele igen egyszerű és gyors. Mindez azért lehetséges, mert a VM-ek egy közös template-re épülnek.

A projekt jelenlegi fázisában egyetlen ilyen template létezik, ami pedig egy Fedora 15 alapú linux operációs rendszer. Ebből az következik, hogy ha valamilyen új alkalmazást szeretnénk telepíteni (vagy a meglévőket frissíteni) azt csak a használt template-ben kell megtenni, és utána az összes VM-ben rendelkezésünkre áll…

Használat

Ha mindezzel megvagyunk, máris használhatjuk a rendszert… Ehhez persze azt minden esetben el kell döntenünk, hogy milyen alkalmazást, melyik VM-ben szeretnénk elindítani. Ebben nagy segítség a speciálisan erre a feladatra módosított KDE menü:

Miután elindítottunk egy-egy alkalmazást, az a VM-re jellemző színű keretben fog megjelenni, ezzel reprezentálva, hogy éppen mi melyik VM-ben fut:

Így könnyen megkülönböztethetjük a céges böngészőt a privát célra használttól, vagy az ideiglenesen megnyitott ismeretlen oldat tartalmazóktól…

További dokumentációk, és felhasználási esetek a projekt wiki oldalán…

A témáról hamarosan egy ingyenes előadást is tartok, ahol élőben fogom bemutatni a rendszer működését. Eerre jelentkezni itt lehet.

Összegzés

A fentiekből láthatjuk, hogy a Qubes egy olyan, eddig elképzelhetetlen biztonsági megoldást nyújt számunkra, aminek segítségével remekül elkülöníthetjük egymástól alkalmazásainkat – és a bennük tárolt érzékeny adatainkat…

Természetesen, az is látszik, hogy ez esetben is nagyon sok múlik a felhasználótól. Neki kell ugyanis eldönteni, hogy milyen oldalt melyik VM-ben nyitja meg, vagy épp melyik VM-et milyen hálózatba csatlakoztatja… Tehát, a Qubes ‘csak’ egy eszköz ahhoz, hogy végül egy biztonságos desktop gépen dolgozhassunk, tesztelhessünk vagy épp szórakozhassunk.

A projekt jövőbeli tervei között elsőkét szerepel további operációs rendszer (többek között windows!) alapú AppVM-ek támogatása is, ami még szélesebb felhasználói körnek biztosít majd egy rendkívül jó, és biztonságos, virtualizált desktop környezetet…

Az eredeti, sokkal bővebb cikk itt olvasható.

 

XenClient – 2.0

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos destop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

A Citrix elsőként jelent meg a piacon egy  széles körben használható desktop virtualizációs megoldással, amely alapjául egy valódi Type1 típusú hypervisor szolgál: a Xen

A hivatalos marketing ömleny természetesen a Citrix oldalain olvasható, én ezt a részt ugranám, és rátérnék arra, hogy mit is kapunk valójában.

Verziók

Először is tisztázni kell, hogy pontosan melyik verzióról is van szó:

Ez a XenDesktop részeként használható, nagyvállalatoknak szánt megoldás.

Ez egy titokzatos, magas biztonsági szintet ígérő verzió – ám erről egyelőre kizárólag marketing anyag érhető el…

Ez lenne a nép számára is ingyenesen használható megoldás, ami vizsgálatunk további tárgyát is képezi :)

Telepítés

Hardver Követelmények

A hivatalosan támogatott hardverek listája megtalálható a termék weboldalán

Ezek között sajnos az én laptopom sem szerepel, de ettől függetlenül egy próbát megért, és kiderült hogy mik azok a bizonyos sarkalatos pontok:

  • VT-x

Ezen a fícsör megléte elengedhetetlen, nélküle egyáltalán nem telepíthető a rendszer (ahogy semmilyen más egyéb Type1 hypervisor sem)

  • VT-d

Ennek hiányát a telepítő jelzi, ám a gyakorlatban csak a VM-ek 3D támogatás hiányát okozza.

  • GPU

Ezzel kapcsolatban a telepítő nem nyilatkozik, a telepítés gyakorlatilag bármilyen GPU-val sikeres lesz, ám a rendszer támogatott GPU hiányában csak „Safe Grapics Mode”-ban hajlandó elindulni. Ez később a VM-ekre is kihatással van, ők is csak limitált felbontással (1024×768) és sebességgel (fbdev) fogynak működni…

  • HDD

Erről csak annyit, hogy a telepítés során a TELJES diszket birtokba veszi a rendszer, külön partícióra nem telepíthető. Erre amúgy a telepítés során fel is hívja a figyelmet.

Ha a fenti követelményeknek (többé-kevésbé) megfelel a hardverünk, akkor hipp-hopp fel is települ, és az első sikeres boot után a rendszer grafikus felülete fogad bennünket, ahol többek között virtuális gépeket hozhatunk létre – és végül is, ez volt a cél :)

A virtuális gépek létrehozására – egyelőre – két lehetőségünk van:

  • Local Disc

Azt hiszem ezt nem kell túlmagyarázni, lokális médiáról való telepítést jelent :) Tehát, ha van a közelünkben telepítő CD, (vagy image) akkor a guest oprendszer telepítése semmiben nem különbözik egy normális telepítéstől.

  • Synchronizer

Ezen megoldás segítségével, egy központi szerveren hozhatunk létre szabványos VM-eket, amiket aztán a kliensek letölthetnek és használhatnak, Olyan egyéb járulékos előnyökkel mint: ‘Dynamic VM Image Mode’  használata. Természetesen ennek előfeltétele, a Synchronizer szerver, és a róla elérhető VM-ek előkészítése…

Használat

Amint sikerült egy legalább egy VM-et létrehoznunk, máris használatba vehetjük. Fontos kiemelni, hogy – egyelőre – a VM-ek között, a (hálózaton kívül) semmiféle egyéb kapcsolat nincs, egyszerre mindig csak az egyik VM konzolját látjuk és használhatjuk. A közös beviteli és kimeneti eszközök (egér, billentyűzet, hangkártya, monitor!, stb) mindig az ‘aktív’ VM-hez vannak rendelve.

Fontos kiemelni, hogy a 3D támogatás – ami tulajdonképp csak marketing elnevezés – szükséges egyéb olyan fícsörök használatához is, aminek semmi köze a 3D-hez. Ilyen pl.: a külső monitor használata, ami egy laptop esetében mindennapos… Ezt azonban egyszerre csak egy VM birtokolhatja, a többieknek ilyenkor be kell érni a beépített kijelzővel.

Tehát, hiába van (akár több) külső monitorunk, több VM egyidejű megjelenítésére nincs lehetőségünk.

Közösködés

Ha már van némi fogalmunk egy hypervisor (esetünkben a Xen) működésével kapcsolatban, akkor tudjuk, hogy van egy bizonyos dom0 nevezetű izé, ami közvetlenül a hardverelemekkel tartja a kapcsolatot, így ő lesz a közös pontja a rendszernek. Aki hozzáfér ehhez, az ugyanis teljes joggal birtokolhatja és befolyásolhatja a gépünkön futó összes VM működését. Ez tehát, a rendszerünk gyenge pontja is egyben.

Amit láthatjuk, ezen megoldás esetében valóban minden eszközt a dom0 lát, kezel és birtokol:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
08:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Ebből az következik, hogy a hálózati interfészeket, és így a külső fizikai hálózattal való összeköttetést is a dom0-re bízták:

brbridged Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brinterna Link encap:Ethernet  HWaddr 82:0C:37:96:E1:4E  
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brshared  Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.25.1  Bcast:172.16.25.255  Mask:255.255.255.0
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brwireles Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.26.1  Bcast:172.16.26.255  Mask:255.255.255.0
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          UP BROADCAST PROMISC 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:162 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:296 (296.0 B)  TX bytes:296 (296.0 B)

uivm      Link encap:Ethernet  HWaddr 8A:6C:C3:83:70:B6  
          inet addr:10.169.142.1  Bcast:10.169.142.255  Mask:255.255.255.0
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  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:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  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:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:1C:BF:34:C1:A0  
          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)

Ami így, egy valós támadási felületet ad a rendszerhez, és ezt a marketing ódák figyelmen kívül hagyják!

Ezek után magától érthetődő, hogy a virtuális és fizikai interfészek közötti hálózati forgalomról is a dom0-ban kell gondoskodni:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  brshared brbridged  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brbridged brshared  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brwireless wlan0   0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  wlan0  brwireless  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  brshared *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  brwireless *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brshared  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brwireless  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ha a fenti csomagszűrő szabályokat hálózati szakemberként nézzük, láthatjuk, hogy nincs túlbonyolítva a dolog ;)

Természetesen egy Type2 hypervisorhoz képest ez semmivel sem rosszabb megoldás, ám a biztonságos szeparáció elnevezés ezesetben megtévesztő lehet. Várhatóan, a titokzatos XT verzióban a maximális biztonság érdekében ezen eszközök további szeparációjáról beszélnek…

Ilyen jellegű szeparáció nyomait fedezhetjük fel, ha megnézzük milyen VM-ek is vannak a gépünkön:

 ID  | Name               | UUID                                 | State     
-----+--------------------+--------------------------------------+--------
   1 | uivm               | 00000000-0000-0000-0000-000000000001 | running   
   2 | windows7           | d5f0e6ae-22ba-4386-8fd0-a78f15c2c6ed | running

Trmészetesen, a windows7 nevű az, amit én magam hoztam létre, a másik pedig egy gyári – a nevéből ítélve – a VM váltó felület, és a globális beállításokért, és a  Synchronizer-rel való kapcsolattartásért felelős virtuális gép lehet.

Összegzés

Ha az egyéb (biztonsággal és működéssel kapcsolatos) részletek nem különösebben érdekelnek, akkor tulajdonképpen a rendszer kész és működőképes, hiszen használhatunk egyszerre több operációs rendszert, váltogathatunk közöttük, és akár központilag előkészített céges VM-eket is letölthetünk/használhatunk. Mindezt ingyen.

Ha azonban valós biztonságot is remélünk, akkor tisztában kell lennünk ezen megoldás részleteivel is, nem bedőlve a marketing szövegeknek.

A biztonságon kívül, van ezért még egy-két kérdéses pontja a Citrix megoldásának: kezdve a VM-ek mentési lehetőségeitől, egyészen a VM-ek közötti adatcsere lehetőségéig.

Mivel azonban a terméknek egyelőre nincs életképes konkurenciája, így más lehetőség hiján ez az egyedüli valódi deskop virtualizációt biztosító megoldás. Ha tetszik használjuk, ha nem akkor várunk bizakodva az újabb vezriók és/vagy a konkurrencia megjelenésére ;)

 

Biztonságos desktop OS?

Sajnos kevesen vannak egyáltalán tisztában azzal, hogy miféle veszélyeknek van kitéve egy átlagos felhasználó számítógépe, és a rajta tárolt bizalmas/értékes adatai. Ha pedig nem átlagos, hanem pl: magas beosztású vezetőről, vagy bizalmas adatokkal dolgozó szakemberekről, vagy éppen egy IT biztonsági szakemberről van szó, akkor a veszély még komolyabb!

A hordozható számítógépek, okostelefonok, és egyéb kütyük elterjedésével a helyzet csak egyre romlik, hiszen ezekkel az eszközökkel céges hálózatokat, leveleket, és egyéb bizalmas adatokat is elérhetünk.

A leggyengébb láncszem persze legtöbbször maga a felhasználó. Köszönhető ez a informatika világának rohamos – sokak számára követhetetlen – fejlődésének, és a marketing gépezetnek, ami pedig elhiteti velünk, hogy a fészbúk elérése a legfontosabb dolog a világon ;)

Aki képes ezen átlátni, és egy kicsit is érdekli, hogyan tudhatja biztonságban a laptopján tárolt adatait, az lapozza végig ezt a rövid prezentációt, ami valójában már egy konkrét megoldásra is fókuszál, azonban termékektől függetlenül is a probléma forrására igyekszik felhívni a figyelmet…

A megoldás: szeparáció

Előfeltételek

A fenti ábrán látható architektúra megvalósításának elengedhetetlen feltételei a következők:

Hardver

Ez alapvető fontosságú processzor feature. Ennek megléte (bekapcsolt állapota) nélkül egyáltalán nem használható egyetlen HVM Hypervisor sem. Bővebben…

A Xen azonban nem csak HVM domaineket (virtuális gépekt) képes létrehozni, sőt a Qubes 1.0 VT-x nélkül is működőképes, mivel nem HVM virtualizációt használ.

Ez a fícsört szinte minden mai processzor támogatja, ám sok laptop BIOS-ból hiányzik a ki/be kapcsolás lehetősége. Az én laptopom (Esprimo V5505) is ebbe a kategóriába tartozik, így kicsit hackelni kellet a BIOS-t hogy bekapcsolható legyen.

Ez a chipset feature ahhoz szükséges, hogy a különböző I/O eszközöket is biztonságosan hozzárendelhessünk különböző VM-ekhez. Ennek megléte nélkül technikailag működőképes megoldást hozhatunk létre, viszont biztonsági szempontból nem leszünk sokkal előrébb. Bővebben...

Megléte opcionális, ezzel még tovább növelhetjük rendszerünk megbízhatóságát.

Az Intel legújabb technológiája, ami a fent említett ‘alap’ dolgokon felül, a még teljesebb hardver virtualizáció megvalósítását tűzte ki célul. Bővebben…

Szoftver

Ha a hardveres alapfeltételek adottak, akkor már csak a megfelelő szoftver kell a megvalósításhoz. Technikailag bármelyik Hypervisor alkalmas lenne erre, a gyakorlatban mégis egyelőre csak Xen alapú megoldások léteznek:

A projekt egyelőre ‘beta’ állapotban van, azonban technikailag a legjobbat szeretnék kihozni belőle, így a biztonság az első és legfontosabb szempont. Ennek ellenére egyedülálló integrációs kiegészítő szoftvereken dolgoznak, ami a különböző VM-ek közötti állománycserét, és interakciót igyekeznek biztosítani ‘felhasználóbarát’ módon.

Egyetlen hátrányos tulajdonsága, hogy egyelőre csak Linux alapú VM-eket lehet benne használni, egészen konkrétan: Fedora Mivel sokaknak nem ez a szimpatikus disztribúció, így az ismeretlen felület és beállítási lehetőségek a tesztelés során némi kényelmetlenséget okozhatnak.

Nagyobb baj az, hogy akinek elengedhetetlen a windows-os VM, az nem sokra megy ezzel egyelőre :(

A projektről azóta több cikk is született:

  1. Qubes – Beta3
  2. Qubes 1.0 – RC1

Ez a szoftver a Citrixtől, ugyan ezt ígéri, ám esetükben a windows az alapértelmezett VM, a Linux egyelőre ‘experimental’ jelzéssel van ellátva.

A termékről azóta külön cikk is született…