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.
- A hozzászóláshoz be kell jelentkezni
- 6282 megtekintés
Hozzászólások
a java VM nem ugyanez? :)
- A hozzászóláshoz be kell jelentkezni
Olvastad a korábbi cikket?
...
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
...
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
Nem :)
- A hozzászóláshoz be kell jelentkezni
+1
------------------------
Everyone is a winner*
- A hozzászóláshoz be kell jelentkezni
+1
ezt még párszor feltalálják újra olyan hype nevekkel hogy ihaj.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
biztonságos számítógép az, ami előtt nem ül user... :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ami ki van kapcsolva. :)
- A hozzászóláshoz be kell jelentkezni
na, ez sem igaz, mert sötétben elbotolhatsz benne. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Windows XP-k előtt csupa rendszergazda ül, és ez minden baj forrása :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
mennyivel egyszerűbb lenne az eredeti kódot rendesen megfaragni, mint állandóan körbedolgozni...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egy tisztan Harvard-architekturas geppel ilyen problema nem lenne.
Az első interpreterig...
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
+1
lxc rulz
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Akkor már inkább sandboxie meg hasonlók, nem?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Továbbra is azt gondolom, hogy ez teljesen jó ötlet.
- A hozzászóláshoz be kell jelentkezni