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.
VPN státusz ikonok – Qubes OS alá
A Qubes OS egyik remek megoldása, hogy különböző típusú VM-eket lehet benne használni, köztük az egyik legérdekesebb a ProxyVM (vagy FirewallVM).
Qubes – 3.0
Október 1-én megjelent a Qubes OS legújabb, 3.0 verziószámot viselő kiadása, amelyet a fejlesztői csapat Caspar Bowden emlékének ajánlja.
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.
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:
- 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 ;)
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:
Az általa megjelenített VM tulajdonságokat is a saját igényeinkhez igazíthatjuk:
Az összes VM-re vonatkozó globális beállítások:
Egy adott VM-re vonatkozó alapbeállítások:
Egy adott VM-re vonatkozó extra beállítások és információk:
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:
Egy VM-hez könnyedén hozzárendelhetünk PCI eszközöket is:
Beállíthatjuk, hogy az adott VM-en belül milyen alkalmazások jelenjenek meg a menüben:
Akár szolgáltatásokat is indíthatunk, amik a VM indításakor automatikusan elindulnak majd:
Az adott virtuális géphez kapcsolódó beállításokat egy külön menüből is elérhetjük:
Ezek közül igen hasznos a virtuális géphez tartozó naplóállományok megtekintésének lehetősége:
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ó.