Qubes: egyszer használatos VM-ek

 ( trey | 2010. június 4., péntek - 13:13 )

Joanna Rutkowska és csapata az Invisible Things Labs-nél már korábban felvázolta a Qubes névre hallgató elképzelését, amely a számítógépes desktop biztonságát virtualizáció segítségével valósítaná meg. Most Joanna egy friss blogbejegyzésben arról ír, hogy kollégája, Rafal Wojtczuk egy új, a Qubes Beta 1-ben bemutatkozó "killer" funkción kezdett el dolgozni. A neve: egyszer használatos VM-ek.

Az egyszer használatos VM egy rendkívül pehelysúlyú virtuális gép, amely rövid idő alatt ( < 1 másodperc) jön létre és bootol fel, és amelynek nincs semmi más feladata, mint egy adott alkalmazást hostolni. Ez lehet akár egy PDF olvasó vagy egy médialejátszó.

Joanna egy egyszerű példával szemlélteti az egyszer használatos (ha úgy tetszik eldobható) VM-ek létjogosultságát itt.

A szolgáltatás alapvető funkcionalitással várhatóan a nyár végén megjelenő Qubes Beta 1-ben bukkan majd fel.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

a java VM nem ugyanez? :)

Olvastad a korábbi cikket?

...

nem, de a lényeg és a smiley arra utal, hogy kicsit vicces, hisz minden nem java -server -rel indított VM ugyanez, csak kicsiben... sztem. :) bocsánat mindezért :)

Röviden arról van szó hogy meglevő eszközöket és ötleteket összegyúrnak/tak és egy olyan környezetet csinálnak ahol minden egyes elindított alkalmazás automatikusan egy elszigetelt VM-ben indul el.

...

Csak én vagyok aki szerint gyakorlatilag a memóriavédelmet találják fel újra ezzel pepitában és erősebb változatban, mint ami már most is létezik szinte az összes OS-ben? :) A hardver ugyanis már évtizedek óta képes minderre, más kérdés, hogy az OS-ek API/ABI-jai, fájlrendszerei, stb úgy vannak megtervezve, hogy rést ütnek a falon, ezért most húznak az egész fölé még egy layert, amivel végre ismét bezárható minden alkalmazás a saját kis világába. Hogy aztán újabb API-kat lehessen definiálni, ami az ilyen VM-ek közötti interoperabilitást biztosítja, ami persze megint rést üt a falon. És a kígyó máris a saját farkába harapott.

A probléma örök, miszerint a nagyjából biztonságos számítógép csak az, amit kiöntöttek egy betonkockába és elástak kb. 5km mélyre. Az összes többi ilyen csak maximum próbálkozásnak dícséretes.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nem :)

+1
------------------------
Everyone is a winner*

+1
ezt még párszor feltalálják újra olyan hype nevekkel hogy ihaj.

+1

biztonságos számítógép az, ami előtt nem ül user... :)

Es amire be sem tud jutni user. Meg rendszergarazda sem.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ami ki van kapcsolva. :)

na, ez sem igaz, mert sötétben elbotolhatsz benne. :)

rendes gépet be lehet kapcsolni távolról...

de ha csak rendszergazdák lennének a gépek előtt, userek nem, sok gondot megoldana...
nem lenne pl. spam... egy rendszergazdát hiába spammeled, hogy xxx oldal, ő töltötte fel az anyagot... user meg nincs a gép előtt, akit érdekelhetne az infó...
nem lenne vírus.. minek?
és nem lenne foglalt a hálózaton a sávszélesség előlem:PPPPP

Windows XP-k előtt csupa rendszergazda ül, és ez minden baj forrása :)

Hogy aztán újabb API-kat lehessen definiálni, ami az ilyen VM-ek közötti interoperabilitást biztosítja, ami persze megint rést üt a falon.
Már majdnem hozzá akartam ezt okoskodni, amikor megláttam, hogy te is leírtad. :)

Nem igazán tudok mit hozzáfűzni, nagyjából az egész problémakört leírtad.
---
Internet Memetikai Tanszék

mennyivel egyszerűbb lenne az eredeti kódot rendesen megfaragni, mint állandóan körbedolgozni...

Szerintem nem lenne egyszerűbb... a szoftver verifikáció messze el van maradva attól a komplexitástól, amit ma egy átlagos felhasználói program GUI-val és mindennel képvisel. Kb az italautomata-vezérlő bonyolultságú projekteket lehet teljes egészében verifikálni, különben kezelhetetlen méretű állapotterekkel találja szembe magát az ember. Egyszerűsíteni kell a feltételeket, hogy hatékonyabban lehessen verifikálni, de innentől kezdve máris teret nyitunk annak a bizonyos "jó ötletnek", amire a fejlesztők nem is gondoltak és amivel megintcsak megkerülhetővé válnak a biztonsági intézkedések.

Gondolj bele, hogyan nyitották ki az Xbox360 DRM rendszerét... gyakorlatilag nem is volt kihasználható hiba a bootloader DRM rendszerben (a Microsoft elképszető erőforrásokat ölt bele, hogy ne legyen), csak éppen a CPU-nak volt egy olyan kevéssé ismert feature-je, amire a fejlesztők nem gondoltak. Így is azt hiszem 10 hónapba került megtalálni és kifejleszteni a "modchip-mentes" exploitot hozzá.

UPDATE: sajnos nem találtam meg azt a videót, amiben eredetileg ezt a CPU mode-alapú hacket Michael Steil elmagyarázta, ugyan a linkelt videóban is szó van róla, de talán a másikban jobban el van magyarázva.
---
Internet Memetikai Tanszék

Ebben akkor látnék fantáziát, ha a virtualizációs cuccok hibátlanok lennének. De nem azok. Így vm-be rakni egyes kódokat nem a probléma megoldását jelenti, hanem a döglött ló áthúzását a másik utcába.

A problema azert orok, mert a kiindulopontja a Neumann-architektura, meg manapsag a modositott Harvard-architektura. Egy tisztan Harvard-architekturas geppel ilyen problema nem lenne.

Egy tisztan Harvard-architekturas geppel ilyen problema nem lenne.
Az első interpreterig...
---
Internet Memetikai Tanszék

+1

lxc rulz


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mivel lassan mindenkinek lesz otthon 4GB ram, meg 4 magos (+HT -es) proci, ezért valamivel fel kell zabáltatni az erőforrásokat.. erre teljesen jó lesz szvsz.

Akkor már inkább sandboxie meg hasonlók, nem?

--
joco voltam szevasz

Igen, erre én is gondoltam, hogy sima app virtualizálás és e között mi a jelentős különbség a teljes virtualizálás javára.

Őt idézve:
"Linux native security mechanisms (even including SELinux) don't provide GUI-level isolation, i.e. if two apps are allowed to talk to the same X server, each should be considered to be able to control the other one (or steal the other one's secretes)."
És még emliti a "több kód - több hiba" elméletet is. (a hypervisor párszázezer sora vs. linux/bármilyen kernel csillió sora)

Ez nem tudom mekkora problémát jelenthet úgy általában. Persze, lehet biztonságosabb mindenre külön vm, de szerintem ez kb egy workaround egyelőre(?). Nem akarok nagyon okoskodni, de jelenleg igy látom, attól még lehet jó kezdeményezés.

ui.: a sandboxie nem teljesen működik 64bites windows vista-án és windows 7-en, és mellesleg nincs !windows-ra.(bár létezik chroot, és társai)

Továbbra is azt gondolom, hogy ez teljesen jó ötlet.