Release candidate beveiligd 'virtualisatie-OS' Qubes komt uit

Het researchbedrijf Invisible Things Lab heeft de eerste release candidate van het beveiligde besturingssysteem Qubes uitgegeven. Dit besturingssysteem beveiligt applicaties door ze in virtuele machines te laten draaien.

De Poolse root-kit-expert Joanna Rutkowska kondigt op haar blog de eerste-releaseversie van Qubes OS aan. De oprichtster van het bedrijf Invisible Things Lab raakte in 2008 bekend door de ontwikkeling van de rootkit Blue Pill. Met deze rootkit kan een besturingssysteem verstopt worden in een virtuele machine dankzij hardwarematige virtualisatie, zodat belangrijke systeeminformatie niet-detecteerbaar onderschept kan worden. Kennis die bij het maken van de root-kit is vergaard, is gebruikt bij de ontwikkeling van het besturingssysteem.

Qubes is een besturingssysteem waarin applicaties ieder een eigen virtuele machine toegewezen krijgen. De applicatie draait dan in deze virtuele machine, zodat beveiligingslekken in de software niet gebruikt kunnen worden om bij andere delen van het systeem te komen. Ook op systeemniveau worden processen, zoals netwerkverbindingen en het bestandssysteem, gevirtualiseerd, zodat bij aanvallen het systeemonderdeel kan worden afgesloten, terwijl het systeem intact blijft.

Het besturingssysteem is gebaseerd op virtualisatiesoftware Xen binnen een Linux-omgeving. De eerste bèta werd in april 2011 vrijgegeven. Sinds maart 2012 is het mogelijk om naast Linux-applicaties ook Windows-applicaties in het besturingssysteem te draaien. Nieuw in deze versie is onder andere de grafische interface om de virtuele machines in te stellen. De virtuele machines zijn in deze versie gebaseerd op Fedora 17. Geïnteresseerde gebruikers kunnen een iso-bestand downloaden en installeren. De makers roepen gebruikers op problemen te melden via de mailinglijst, zodat deze verholpen kunnen worden voor het uitbrengen van Qubes 1.0.

Reacties (60)

[bert_m]

In hoeverre verschilt dit systeem van bestaande virtualisatieoplossingen? De screenshot doet vermoeden dat de gebruiker gewoon verschillende VM's kan aanmaken (zoals 'personal', 'banking', 'untrusted'), waarin hij volledige machines tot zijn beschikking heeft. Dat zou wat anders zijn dan een VM per applicatie.
Als het inderdaad om een VM per applicatie zou zijn, dan ben ik benieuwd hoe ze interprocescommunicatie willen toestaan in dit OS. Dat is uiteindelijk de kern van een samenhangend systeem.

[RedPixel]

De architectuur staat hier uitgelegd: http://qubes-os.org/Architecture.html

Je kunt dus meerdere VM's binnen één OS aanmaken, waarbij ze verschillende rechten hebben. Applicaties kunnen wél bij het netwerk en opslag, maar niet andersom.

[hardwareaddict]

Het leunt heel sterk op intels hardwarematige virtualisatie zo lijkt het en ook heel specifiek geduid wat wel en wat niet.

Met AMD processoren kun je het schudden.

Lijkt dat alleen wat laptops ondersteund worden; ATI/AMD kaarten worden niet ondersteund en bij Nvidia is de opensource driver niet stabiel genoeg dus moet je de proprietary binary van nvidia downloaden, wat natuurlijk het systeem gelijk onbetrouwbaar maakt qua security

[wizzkizz]

Volgens leunt inderdaad op hardwarematige virtualisatie, maar dat is voor zowel AMD als Intel beschikbaar. IOMMU/VT-d wordt aangeraden, maar ook zonder is het werkbaar (maar iets minder veilig) door AMD VT/Intel VT-x.

[Reactie gewijzigd door wizzkizz op 24 juli 2024 03:48]

[hardwareaddict]

Waar is het wiskundig bewijs dat dit minder veilig is?

[wizzkizz]

Ik weet het niet tot in details (ben ook maar een gewone gebruiker ). In de architecture description (PDF alert) staat dit:

quote: http://qubes-os.org/files/doc/arch-spec-0.3.pdf

In case of the x86 hardware, one would also assure that the drivers cannot program devices to issue malicious DMA transactions that could potentially compromise the microkernel or other parts of the system. This would require the microkernel to support programming of the IOMMU/VT-d, as otherwise one would need to prove correctness of every single driver, which is unfeasible in reality. However, addition of IOMMU/VT-d support to the seL4 microkernel might likely result in rendering the formal proving much more difficult.

Ik ben niet zo goed thuis in de details van deze systemen dat ik de achterliggende principes allemaal kan doorgronden. Ik ben een geïnteresseerde thuisgebruiker, die dus soms ook moet vertrouwen op de deskundigheid van anderen. En toevallig vertrouw ik Joanna Rutkowska en Rafal Wojtczuk best wel. Op dit gebied iig

[hardwareaddict]

Maar dit bewijst nog niet dat je ook maar 1 cent veiliger af bent noch dat het onveiliger is.

Verder klopt de aanname niet natuurlijk. Het kernprobleem zit hem juist in de drivers. Lijkt er sterk op dat dit project dat probleem niet probeert te tackelen. Wat wel natuurlijk praktisch enorm helpt wordt hier wel gedaan is de simpele manier waarop op dit moment iedereen die online browsed gehacked wordt.

We moeten echter niet doen alsof dit het ei van columbus is en dat je er speciale hardware features voor nodig zou hebben die het veiliger zouden maken of onveiliger als je het niet hebt. Dat lijkt handig, maar in de praktijk is de software zo'n enorme gatenkaas dat het aanpakken daarvan al vele malen belangrijker is dan mogelijkheden in de hardware...

Verder is het zo dat we niet moeten doen alsof we voor een prikkie hardware kunnen kopen die features heeft die de zaak veilig maken - de speciale hardware die je namelijk wel daarvoor kunt kopen is stinkend duur en dat gaat niet veranderen...

Wat dus al een hele prestatie is, is als het enigszins de duizenden hacks via javascript van al de websites, waarmee ze je hele computer leegroven, een beetje tegenhoudt.

[MAX3400]

Software kan niet bij andere delen van het systeem komen. Briljante/late uitvinding, juist nu VMware & Hyper-V gewoon toestaan dat virtuele machines (en hun software) bij wijze van spreken direct communiceren met hardware van de host.

Qubes is dus eigenlijk een teruggang in de ontwikkeling van hypervisors.

[Reactie gewijzigd door MAX3400 op 24 juli 2024 03:48]

[hardwareaddict]

Nee zie het anders.

het security probleem van zowel windows als linux is dat het operating systeem monolithisch is.

Dat is dus geen hardware probleem maar een software probleem.

monolithisch betekent dus dat elke driver in de kernel dus kan doen wat hij wil.
Linus geeft glashelder aan waarom: snelheid.

Hij interesseert zich niet voor security.

Een project als dit interesseert zich daar wel voor. Op het moment dat je dat doet, dan kijk je natuurlijk ook: "welke hardware mogelijkheden heb ik om het NOG veiliger te maken?"

Deze developer kwam dan uit op een intel virtualisatie techniek (al erg oud) en bouwt dan voor die laptop iets.

Leuk als je zo'n laptop hebt. Iets minder voor mijn macbookpro 17'' zo lijkt het. Vooral als je je realiseert dat afgezien van het toetsenbord op de laptop alles gedaan wordt met een USB toetsenbord en die werkt dus voor geen meter hier.

Dus je strandt gelijk in de driver ellende - dat is juist iets waarvoor Linus zich inspant.

Kennelijk met nvidia lukt dat niet erg best en met AMD/ATI helemaal niet. Dan is dus direct ook de vraag waarom in dit project het alleen lukt met intel gpu's.

Of all gpu's on planet earth...

p.s. als ik marketing manager intel was zou ik direct een paar nieuwe laptops en machines naar deze persoon sturen - baat het niet dan schaadt het niet - zoals altijd stappen de grote fabrikanten altijd als laatste in om iemand te supporten.

[Reactie gewijzigd door hardwareaddict op 24 juli 2024 03:48]

[the-dark-force]

ik dacht toch echt dat vm ware zelf viruele hardware gebruikte (vandaar ook die lagg bij gamen in een vm, generic drivers e.d.)

qubes is al een tijdje beschikbaar maar het is echt niet veel anders als bijv. windows 7 met vm ware of sandbox om bestanden te testen. het enige voordeel op dit moment is dat mogelijk veel hackers/scriptkiddy's geen code tot beschikking hebben die qubes detecteert en het virus bellemmert zichzelf uit te voeren (zoals bijv. met darkcomet met anti-sandbox e.d.)
daardoor zou je het virus alsnog in een virtuele omgeving kunnen draaien waardoor je waarschijnlijk de ware aard van het bestand zult zien terwijl je systeem nog steeds veilig is.
terwijl voor vm al meerdere keren code is geschreven dat uit de virtuele machine kan ontsnappen.

die dame had verder ook eerder een concept "blue pill"
ik vraag me af of dit systeem juist dat soort malware niet in de kaart werkt.

daarnaast denk ik dat een paranoide win7 gebruiker veiliger is als een qubes gebruiker die zich veilig waant en dus geen antivirus oid gaat gebruiken. (gebeurt weleens vaker dat mensen hun o.s. onterecht als veilig beschouwen en daardoor a.v. overbodig vindt... )

[wizzkizz]

Dit is wel degelijk veiliger dan de oplossingen die jij noemt. In 2011 had Tom's Hardware een interview met Joanna Rutkowska waarin ze o.a. dit aangaf:

quote: http://www.tomshardware.c...tkowska-windows,3009.html

It's just that, first, the sandboxing was designed for server applications and not for desktop applications (where all processes usually run as the same user), and second, OS kernels turned out to be buggy, and not so effective at enforcing this isolation.

Today's sandboxing technologies attempt to address the first problem in that they try to be more suited for desktop applications.

This might, for example, require splitting a browser into several processes: one for rendering, another for user interface handling, and so on. This is all good, but the second problem mentioned above still remains unsolved. Can we rely on a big, fat, and buggy kernel that has hundreds of drivers inside, networking stacks, and so forth to enforce strong isolation?

People who regularly release kernel exploits for popular OSes (Linux being no exception) seem to be yelling: NO!

[hardwareaddict]

Afgezien van 100 leaks in de server implementaties waardoor die servers te hacken vallen, zij het niet doorbeginners.

Neem alleen al de encryptie die windows gebruikt voor zijn file system. Dat is bitlocker. Die is niet veilig geimplementeerd. Eenvoudig te hacken. Zo werkt dat overal voor.

[wizzkizz]

Dat is dus precies het probleem dat zij ook ziet. Daarom heeft ze Qubes-OS ontwikkeld, die dat probleem niet zou moeten hebben door zo weinig mogelijk in dom0 te draaien, de netwerk- en opslagstack in aparte VMs te draaien etc. En dus gebruik te maken van de hardwarematige virtualisatiefeatures. Daarboven draaien dan alle desktop applicaties weer in een andere VM, afhankelijk van hoe je het systeem zelf inricht.

En zijn er "disposable VM's", die slechts leven zolang je de applicatie open hebt staan. Bijvoorbeeld een browser. Als je de browser afsluit, wordt de hele VM vernietigd. En communicatie met andere VMs was al niet mogelijk, behalve door het speciale uitwisselingsmechanisme dat draait via dom0, waardoor malware dit niet kan aanspreken.

Ze zegt nog veel meer in het interview waar ik uit citeerde, erg interessant om te lezen!

[hardwareaddict]

Allemaal heel interessante materie, maar we moeten in de praktijk zien hoe het werkt.

Daarnaast is er altijd het theoretische probleem versus praktijk. Als iets theoretisch niet deugt, dan maakt de rest niet meer uit.

Verder is er nog het volgende probleem altijd en dat is dat alles wat op het net staat aan security, dat werkt tot nivootje secret ( symmetrisch algoritme als AES bijvoorbeeld).

Het hacken door de inlichtingendiensten zelf online, en dat zijn er duizenden (dan hebben we 't alleen nog maar over de NSA's van de verschillende landen - want bijvoorbeeld alleen al USA heeft 1200 officiele inlichtingendiensten en Nederland 100, terwijl elke dienst zijn eigen afdelinkje heeft voor het gehack) , daar gooien ze echter topsecret algoritmes en hardware en militaire scanners tegenaan. Overigens die scanners zijn niet zo geheim - de software om de zaak te analyseren wel. Alles wat niet in een bunker staat dat scannen ze wel dwars door het raam en de computerkast heen op de harde schijf. Dat doen ze desnoods voor die ene patch en commit die ze erdoorheen willen drukken.

Dat is een enorm probleem bij het beveiligen van JUIST linux - want zij redeneren altijd: "wie moeite doet om zich te beveiligen, die willen wij JUIST hacken". Daar sturen ze desnoods mensen voor op pad, die letterlijk langs je huis dan komen lopen. Om over bedrijfsspionage geintjes die ze uithalen maar te zwijgen. Daar parkeren ze gewoon een truck naast die vol zit met apparatuur (scanners veel stroom nodig - electrische bestelbusjes in de toekomst zijn dus geniaal daarvoor).

Als je dus bij al die distributies kijkt zie je ook dat een aantal belangrijke componenten, met name filesysteemcomponenten, daar zit altijd wel een Rus tussen die dat 'vrijwillig' bijdraagt aan zo'n project. Dit waar de Russen juist geniaal zijn in het bouwen van compilers - ze domineren daar. Maar bijdrage leveren aan GCC, ho maar. In de steering committee 0 Russen en in de bijdrage lijst vind je heel sporadisch 1 Rus die een keer wat gedaan heeft.

Van binnenuit worden de grootste gaten altijd gecreeerd - en bewust.

Dus als programmeur klooi je wat om dingen werkend te krijgen - maar als het gaat om het hacken van wat je doet - daar gooien ze budgetten tegenaan - het is niet leuk zelfs.

Daar zal dit project veel problemen en ellende mee krijgen als het serieus tot leven komt.

Neemt niet weg dat het machtig interessant project is.

[Reactie gewijzigd door hardwareaddict op 24 juli 2024 03:48]

[BoringDay]

Paranoide windows gebruikers weten dus niet of ze veilig zijn?
Dat lijkt mij al een probleem op zich.

Ik gebruik liever mijn OS op een manier zodat ik weet wat ik doe.
Over beveiliging en nog steeds niet zeker van je zaak zijn ... is not the answer

[tes_shavon]

Ik ben vooral benieuwd hoe snel een applicatie start.

[m_w_mol]

Een paar seconden extra wachten is een acceptabel offer dat ik graag maak als mijn systeem er qua stabiliteit op vooruit gaat ...

[SuperDre]

ho ho ho, dit wil nog niet zeggen dat je systeem er ook stabieler van gaat draaien..

[m_w_mol]

Vanzelfsprekend heb ik het dus niet over de stabiliteit van één applicatie in één sandbox. Maar als een crash van applicatie A niet meer zorgt voor een crash van applicatie B, omdat alleen de gevirtualiseerde omgeving crashed, is er dus wel degelijk sprake van meer stabiliteit.

[_Thanatos_]

Als de ene de andere applicatie meetrekt in een crash, dan zit het OS fundamenteel niet goed in elkaar. Dat geldt ook voor een applicatie die de rest van het OS op z'n knieën brengt. Dat hoort sowieso niet te kunnen, sandboxing of niet.

[hardwareaddict]

Dan mag je systeem geen grafische kaart hebben behalve van intel.

Het staat allemaal nog in de kinderschoenen dit project dus het is leuk om te zien hoever ze komen.

De meeste projecten die gestart worden door hackers hebben als nadeel dat ze regelmatig omvallen wegens enorme rechtszaken die gestart worden op het moment dat zo'n project succesvol lijkt te zijn.

Meestal wacht men eventjes tot het duidelijk is of het slagingskans heeft en als dan veel users in die richting dreigen te gaan dan komt er een schip advocaten aan die je wel eventjes gaan aanpakken.

Linus en Richard Stallman die hebben dat altijd proberen te vermijden, maar op het moment dat je andere developers wat laat doen dan kan het gelijk misgaan en is dat soms ook gegaan bij Linus en de FSF.

Het probleem is dat een developer kan zweren bij laag en hoog dat wat hij doet ok is en zelfgebouwd is, maar als er een rechtszaak uit voortkomt, dan is die developer ook spoorloos verdwenen en sta je recht tegenover een bende advocaten.

We zullen zien in hoeverre dit project levensvatbaar is in dat opzicht.

Dan het volgende probleem is soms dat als een project succesvol is dat de tent verkocht wordt. Met angst en beven zien we uit naar het moment dat dit met Ubuntu gaat gebeuren - deze succesvolle Afrikaan/Engelsman heeft al vaker de tent verkocht.

[terror538]

Eeuhm.... ik weet niet waar je je druk om maakt.

Het grootste gedeelte van de open source community, zeker de wat meer prof mensen, zijn handig genoeg om om patenten heen te programmeren en die zaken die ze nodig hebben zodanig te reverse engineeren dat er geen problemen zijn. Vrijwel alle rechtszaken tegen open source producten draaiden dan ook op niets uit, behalve die paar bedrijven die in paniek meteen licenties kochten die achteraf niet noodzakelijk bleken te zijn (zie het SCO debacle van enkele jaren terug).

Het klopt dat er problemen kunnen ontstaan als een tent wordt verkocht, echter dan is de licentie vele malen belangrijker dan het weg doen. Bij Open Solaris is het fout gegaan, binnen de CDDL waren er paragrafen opgenomen dat alle copyright ten alle tijden bij het moederbedrijf kwam te vallen, toendertijd voelde dat goed voor de programmeurs omdat ze het gevoel hadden dat het nooit fout zou gaan. De tijd heeft ons geleerd dat zodra Oracle binnen kwam alle open source solaris kapot is gemaakt.
Dat risico is er niet als de licenties GPL (achtige) zijn, dan is een project binnen een minuut geforked en neemt de community (mits groot genoeg natuurlijk) het project gewoon over onder een nieuwe naam en is er vrijwel niets aan de hand.

Sterker nog, ik voel me eigenlijk veiliger bij Open Source software zowel qua licentie/patent gebeuren als zicht op de toekomst. Ik weet dat als het product wat ik gebruik belangrijk genoeg is voor meerdere mensen het zowieso ondersteund zal blijven door diezelfde mensen, en anders kan ik het mezelf aanleren en het zelf blijven ondersteunen DAT is het enorme voordeel van open (vrije!) source in mijn ogen

Qua Ubuntu: meer dan 90% van die hele distro is gewoon open source, dus mocht Ubuntu ooit de deur uit gedaan worden en de nek om gedraaid dan zal dat gewoon overgepakt worden door de community in een mooie nieuwe fork!

[hardwareaddict]

Redhat was ontzettend populair en SUSE ook. Geniale distributies waren het.

toen eigenlijk binnen een paar jaar waren ze weg en superduur en commercieel.
open solaris was natuurlijk al tevoren duidelijk wat daar zou gaan gebeuren. een kind kon de was doen.

Veel goede alternatieven waren er niet en een rechtszaak die eigenlijk X-windows helemaal uitkleedde en dat omtoverde tot een rampzalig iets wat x.org heet en tot op de dag van vandaag enorme ellende is, dat kwam er voor terug.

Ubuntu werd eigenlijk noodgedwongen geaccepteerd - maar het is natuurlijk een ontzettend lekke distributie vanuit beveiigingsopzicht.

Fedora Core een enorme ramp, tot op de dag van vandaag. OpenSuse ook niet je van het.

Uit armoe gebruik ik Debian. De nieuwere debians moet je ook vanalles voor doen voor het veilig is overigens. Aantal services eruit knikkeren en vrij paranoia firewall nodig.

typerend voor suse en redhat was: net op het moment dat ze geniaal waren, werden ze verkocht.

Nog zo'n ellende applicatie is OpenOffice. Het is zo erg dat ik dus fysiek ergens een internet kabel eruit moet trekken, want zo enorm druk communiceert dat over het internet op het moment dat ik het net gestart heb. De machine hangt regelmatig als ik OpenOffice wil afsluiten.

Ellende joh.

De securitygaten in alles wat onder linux draait is net zo groot als onder windows - als ze maar WILLEN binnenkomen op je computer. Waar een wil is is een weg dan ineens.

Die gaten zijn veel GROTER geworden de afgelopen jaren en ze zijn gebouwd door GROTE bedrijven. Open Office is geheel in India ontwikkeld - een paar van die Indiers ken ik bij naam zelfs.

Dus die hebben 99% van hun tijd gestoken in hoe gaten te creeren en 1% in Open Office neerzetten - dat had een relatief klein team in recordtijd gedaan.

Al die gaten word ik wel strontziek van hoor. In dit opzicht wordt linux alleen slechter.

Kijk DAAR is Qubes dus de toekomstige belofte dat dit beter gaat draaien
Het is het toekomst geluid. Het voorbeeld van iemand die zegt: "kom we gaan dat even proberen te verbeteren". Die spirit is aanstekelijk.

Uiteindelijk is het toch zo dat zo'n distributie bepaald of jij je happy voelt bij linux of niet.

Op dit moment domineert Ubuntu. Zelf ben ik wat huiverig het te gebruiken. Meestal op 1 machine draait het ergens in een hoekje hooguit. Als Ubuntu echter verkocht wordt aan een marktpartij die er geld uit wil slaan, dan zit de linux wereld met een megaprobleem hoor.

Niet zo'n enorm probleem als dat Linus omvalt natuurlijk - want voor de kernel zijn er 0 alternatieven.

[Reactie gewijzigd door hardwareaddict op 24 juli 2024 03:48]

[Icekiller2k6]

Het probleem dat ik eerder zie, is de sandboxing alles gescheiden houdt, wat uiteraard goed is, tenzij je applicaties hebt die moeten interacten..


Sandboxie is een applicatie dat je vaak voorbij ziet komen in de meuktracker.
Wat feitelijk hetzelfde doet maar dan op windows. Over het algemeen werkt het allemaal zeer goed.
linkje:
meuk: Sandboxie 3.72

[Gamebuster]

Interessant. Iemand ervaring mee?

[hardwareaddict]

ik download het nu en dan kijk ik of de source code erbij zit. Zo niet dan ga ik kijken of die sourcecode downloadbaar is. Op de homepage zie ik er geen links naar.

Iemand kan vanalles claimen in dit wereldje, als het gaat om linux dan wil ik wel die sourcecode zien. Zo niet dan actie ondernemen.

Alleen dit al kost tijd en moeite.

Dan gaan we uitgebreid kijken wat er nu in de kernel veranderd is.

Op het eerste gezicht lijken ze heel sterk te leunen op intels virtualisatie technieken.
De vraag is hoe verstandig dit allemaal is.

Ik heb hier ook ARMs, MIPs en bende AMD cpu's.

Een project als dit zie ik met name als een software project. Als de softwarematige afhandeling veilig is en werkt dan is het ok.

Tegen hardwarematige hacks van intel en anderen doe je toch weinig. De NSA verzint wel wat (of beter: had al wel wat verzonnen bij het ontwerpen van die cpu en productie ervan in Tel Aviv waar 3 intel fabrieken staan).

Wat me tegenvalt is dat er geen ATI gpu's ondersteund worden.

Zo iets gebeurt als de ontwikkelaar zelf natuurlijk over weinig hardware beschikt cq gewoon weinig tijd gehad heeft voor het toch o zo belangrijke driver aspect.

Het is niet niks om iets als dit op te zetten.

[wizzkizz]

GIT: http://git.qubes-os.org/gitweb/
WIKI: http://wiki.qubes-os.org/trac/wiki/SourceCode

Edit:
Het is gebaseerd op een gestripte en aangepaste versie van de Xen hypervisor en de templates zijn gebaseerd op Fedora 17 afaik.

[Reactie gewijzigd door wizzkizz op 24 juli 2024 03:48]

[hardwareaddict]

Dank! Haal het gelijk af

[matty___]

FreeBsd komt daar met een beter oplossing voor:

FreeBSD 9.0 ships with experimental support for Capsicum
http://www.cl.cam.ac.uk/research/security/capsicum/


lekker alles in een sandbox ala Chrome.

[Reactie gewijzigd door matty___ op 24 juli 2024 03:48]

[blorf]

Interessant, ik had me er nog niet in verdiept. maar de manpage was er al

Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. Capsicum can be used for application and library compartmentalisation, the decomposition of larger bodies of software into isolated (sandboxed) components in order to implement security policies and limit the impact of software vulnerabilities.

Wel moeilijke taal. Een hybrid capability system model? Volgens mij draait dit wel een niveau hoger dan Xen/Linux, hoewel die capsicum ook een aangepaste kernel nodig heeft.
Maar als het alleen voor de veiligheid is lukt het met jails ook wel. Die zijn alleen maar afhankelijk van de host kernel.
Ik geloof dat DragonFly zelfs al jaren een virtuele kernel ondersteunt waardoor ook de zichtbare hardware binnen de jails geselecteerd kan worden.

Wat ik me trouwens afvraag wat betreft dat Qubes OS: er wordt gezegd dat je er windows programma's mee kan draaien maar heb je dan niet nog een Windows API nodig om de boel te ondersteunen? Het lijkt me eigenlijk niet zo'n strak plan om daar wine voor te nemen.

[Reactie gewijzigd door blorf op 24 juli 2024 03:48]

[matty___]

Doordat het een sandbox framework is hoef je dus niets in een virtual machine op te zetten om hetzelfde te bereiken: Dat programma's niet zo maar bij een ander proces kunnen (heel plat gezegd)

Dat zou met jails ook kunnen maar een sandbox lijkt me de betere oplossing met minder overhead en rompslomp erom heen

[hardwareaddict]

Ik zou me daar niet te veel van voorstellen van windows draaien.

Tenslotte doet m$ vanalles om te voorkomen dat je iets voor elkaar krijgt. Daarvoor verwijs ik ook naar de enorme rechtszaken die m$ gevoerd heeft die alleen al gingen over de Device Context - een kritiek iets natuurlijk, want elk dingetje wat je tekent moet via een DC gaan.

Ze verzinnen wel wat.

Wat interessanter is dan deze 'call voor sponsors and attention' door het woord windows te schreeuwen, is natuurlijk hoe veilig het geheel werkt als je een beetje browsed.

[SeelenSchmerz]

In Fedora 17 is dus ook al soortgelijke functionaliteit aanwezig:

Virt-sandbox: http://fedoraproject.org/wiki/Features/VirtSandbox

Met deze tool kun je een toepassing in zijn eigen afgeschermde sandbox opstarten, naar keuze met LXC of KVM.

De overhead van een sandbox met KVM is wat hoger dan één met LXC, aangezien bij die laatste geen kernel meer opgestart moet worden. Een LXC-container is in 200 ms opgestart en heeft geen cpu-overhead.

Meer info: http://webwereld.nl/tips-...ingen-met-lxc-of-kvm.html

[MAX3400]

De overhead van een sandbox met KVM is wat hoger dan één met LXC, aangezien bij die laatste geen kernel meer opgestart moet worden. Een LXC-container is in 200 ms opgestart en heeft geen cpu-overhead.

Is dat een nette manier van zeggen: het opstarten van een LXC kost geen overhead maar wat je daarna doet, dat kan wel extra overhead betekenen?

Misschien dat ik erg achtergesteld ben met mijn opleidingen maar welke hypervisor of sandbox werkt effectiever dan de originele kernel met daarop geinstalleerde applicaties? Ik durf te stellen: geen enkele.

Dus KVM, LXC of welke andere manier van isoleren: aan het eind van het verhaal is er altijd iets wat meer overhead heeft dan je zou hebben op een bare-metal install van OS+apps.

[hardwareaddict]

Elke vorm van afscherming is een stuk trager. Dit is met name waar voor de grafische kaart. De grafische kaart is natuurlijk honderden malen sneller in haar taak dan de CPU. De communicatie cpu naar grafische kaart is soms al enorme bottleneck, vooral voor laptops met 1 of 2 trage cores (vooral bandbreedte probleem). Extra afscherming betekent extra copien dus enorm verlies aan bandbreedte. Dat maak je nooit goed.

Een distributie als dit is natuurlijk alleen voor de utlra-paranoia die niet eenvoudig gehacked wilen worden.

Het gaat enorm trager zijn.

Maar dat is een prijs die veel bedrijven en personen graag betalen voor hun privacy...

[wizzkizz]

De beta 3 werkt op mijn laptop anders behoorlijk soepeltjes. Alleen het opstarten van een nog niet opgestarte VM duurt even, maar dat is niet te vorkomen denk ik. En zeker acceptabel, gezien de veiligheid die je er voor terug krijgt. En met het grafische systeem heb geen problemen gehad qua snelheid. Maar ik game dan ook niet. Ik kan me voorstellen dat het daar niet zo heel erg geschikt voor is.

[mBull]

Hoe pakken ze dan het schrijven van bestanden naar de HDD aan? doen ze dit dan in op een virtuele HDD, en kunnen de virtuele machines (processen / applicaties) er dan wel aan, of zijn deze ook afgeschermd zodat enkel bepaalde vm's aan bepaalde types bestanden kunnen?

Verder vind ik dit zeer inovatief, zeker omwille van het feit dat je zowel Windows als Linux applicaties kan draaien.

En hoe zit het met performance van deze applicaties?

[hardwareaddict]

Een heel kritieke vraag. Ontzettend veel geavanceerde hacks werken door het wegschrijven van bepaalde informatie op een bepaalde manier, wat je machine dus ook hacked als je bijvoorbeeld VMWARE erop draait.

Performance vind ik aanvankelijk minder belangrijk dan de veiligheid. Performance is kwestie van meer CPU kracht ertegenaan smijten.

[PolarWolf]

Technisch gezien een leuk ding, licensiematig een drama.

Leuk voor thuis.

[_jorrit_]

Sandboxing, the next frontier...

[beany]

Je hebt een mooie First Post te pakken, maar ergens heb je wel een punt.

Ik zie het niet gebeuren dat Qubes het OS gaat worden, als in een vervanger voor Windows. Wat natuurlijk wel kan is dat deze technologie(of de concepten) gebruikt gaan worden in bijvoorbeeld Windows. Wat dat betreft zou je Qubes kunnen zien als een research-OS.

[TvdW]

OS X gebruikt voor alle nieuwe apps op de App Store al een sandbox. Dus ik denk dat het niet eens meer echt zo experimenteel is. Uiteraard is er wel een verschil tussen virtualisatie en sandboxing.

-edit-
En Windows heeft natuurlijk sandboxie

[Reactie gewijzigd door TvdW op 24 juli 2024 03:48]

[wizzkizz]

Dit gaat wel heel wat verder dan gewoon sandboxing.

Je hebt hier domeinen (besturingssystemen die gebaseerd zijn op een read-ony template) waartussen in principe geen enkele communicatie mogelijk is. Bijvoorbeeld een domein voor "werk" en voor "privé". Die draaien dan volledig gescheiden, terwijl je vanuit het "startmenu" kunt kiezen in welk domein je een applicatie wilt opstarten. Je tekstverwerker in het domein "privé" staat volledig los van die in het domein "werk". Een infectie in het privé-domein heeft dus geen enkele invloed op het werk-domein.

De enige manier om informatie uit te wisselen is via een beveiligd "clipboard" die ook altijd vraagt of je de informatie wilt kopiëren. Malware kan dat dus niet doen uit jouw naam, omdat het "clipboard" in dom0 draait en de malware hooguit in domU kan draaien.

Je kunt ook eenvoudig via een firewall instellen welke toegang een bepaald domein heeft. Zo kun je gemakkelijk een domein aanmaken voor internetbankieren, dat alleen toegang heeft tot een vertrouwde DNS server, de banksite van jouw bank en de OCSP/CRL servers van de certificaatuitgevers. Geen man-in-the-middle aanvallen mogelijk op jouw systeem, hooguit elders in het netwerk waar je toch sowieso geen invloed op hebt.

[demonite]

ja, totdat op beide domeinen dezelfde malware draait en met elkaar communiceert. Of totdat de malware toch toegang weet te krijgen tot plekken waar het niet hoort te kunnen komen (dmv een exploit bv).. Ik heb een beetje mijn twijfels bij dit soort oplossingen want het is dan misschien wel weer nog een barriere, maar het is maar 1, en al die andere barrieres blijken ook maar van beperkt nut...

[rob12424]

Je moet alle info op de site toch wat beter lezen! Het zijn template machines. Bepaalde dingen kun je dus wel opslaan maar dat kan maar op specifieke locaties zonder rechten! Daarnaast zijn de templates Read only. Sluit jij je werkomgeving af dan vernietigd hij dus die gehele sandbox gewoon!

Even ter info: Elke sandbox heeft ook een andere kleur! Bijvoorbeeld: werk: Groen. Prive rode rand. enz. het is dus zeer duidelijk ik doe mijn werk nu prive of niet!

Daarnaast is het zelfs mogelijk om de prive guest met een ander netwek te verbinden dan de werk quest. Zelfs de virtueele (en evt. hardware matige) netwerk controllers kun je gescheiden houden!

Klein detail: Dit was de vrouw die MS op wilde laten oppakken of een conferentie van wilde blokeren omdat hun super veilige OS met een demonstratie binnen een paar uur gehacked was.

Dit is niet op een normale xen hypervisor gebouwd maar een zeer gemodificeerde. Er is van alles tegen aangepatched enz. zodat rootkits en derdeglijke niet meer werken. De bluepill werkt hier ook niet op!

Er is geen enkelle andere hypervisor die dat heeft of kan! (virtual pc enz. zijn dus niet te vergelijken hiermee! (@max3400 dat is dus het grootste verschil!)

[Reactie gewijzigd door rob12424 op 24 juli 2024 03:48]

[demonite]

Er is van alles tegen aangepatched enz. zodat rootkits en derdeglijke niet meer werken

Isn't that what they all say?
Als ik iets heb geleerd is dat er niets is dat 100% veilig is. Door simpelweg linux te gaan gebruiken heb je echter al geen last meer van 99% van al die crap omdat het meeste specifiek op windows is gericht.. Door Qubes te gebruiken dek je waarschijnlijk die ene procent ook nog wel voor een groot gedeelte af. Maar ja, er was een reden dat ik Windows gebruik, dus close but no cigar.

[blorf]

Mee eens, het wordt allemaal enorm ingewikkeld omwille van de veiligheid. Anderzijds is het niet verplicht en een vrije keus om hier een systeem mee te bouwen.
Maar het is wel leuk dat Xen en nu dit OS laten zien dat een GB's groot monolitisch OS inclusief default programma's eigenlijk flauwekul is. Het stukje software dat voor de basic I/O zorgt en noodzakelijk geladen moet worden is minimaal. Zelfs een hypervisor, dus zo'n zelfde stukje software die als extraatje kan switchen tussen verschillende runtime-toestanden is niet erg groot. Verder kan alles wat de gebruikersomgeving aanbiedt uit losstaande programma's bestaan.

[BoringDay]

Dan pak je van elk object handlers en van je het OS-message verkeer af ...

[nst6ldr]

OS X gebruikt voor alle nieuwe apps op de App Store al een sandbox. Dus ik denk dat het niet eens meer echt zo experimenteel is.

Solaris doet dit al een tijdje langer door middel van zones.

[MAX3400]

Wat natuurlijk wel kan is dat deze technologie(of de concepten) gebruikt gaan worden in bijvoorbeeld Windows. Wat dat betreft zou je Qubes kunnen zien als een research-OS.

Technologie in Windows? Wat is er mis met VirtualPC, VMware Workstation, Hyper-V, ThinApp, APP-V, etc...?

Kan allemaal bovenop Windows draaien en laat applicaties en/of een geheel OS binnen bepaalde parameters draaien, al dan niet met beperkte/directe communicatie onderling op verschillende OSI-lagen.

[EnsconcE]

De technieken die jij benoemt zijn niet ontwikkeld met veiligheid als uitgangspunt, app-v en thinapp al helemaal niet. Die twee zijn applicatie virtualisatiepakketten waarbij eigenlijk alleen het bestandssysteem en het register gevirtualiseerd zijn. Het is nog steeds eenvoudig onderling tussen applicaties te communiceren.

[Froos]

Ik zie het als een Proof-Of-Concept. Sandboxing zoals je het eigenlijk zou willen.

Het mooie is, dat zodra iets virtueel 'draait', het niet meer uitmaakt WAAR het draait. In het kader van alles in de cloud en co een hele mooie optie voor bedrijven die nu een Client-Server constructie hebben en geen webclient willen maken.

Uiteraard moet je dan wel van een POC naar iets productiewaardigs en dat gaat nog wel even duren, denk ik.

Kortom: uiterst interessant en zeker een goede trend! Hallo Microsoft, VMware, Symantec en alle andere grote softwarebedrijven! Wanneer komt er een commercieel implementeerbaar iets hiervan??

[BoringDay]

Maar ik zou niet elke App in een virtuele machine willen draaien.
Ik zou niet voor elke knip en plak werk ook nog eens willen toestemming moeten geven of het mag. Lijkt me een ramp als ontwikkelaar.