Software-update: Qubes OS 4.2.4

Versie 4.2.4 van Qubes OS uitgebracht. Qubes OS is een op privacy en beveiliging georiënteerd besturingssysteem. Het maakt gebruik van security by isolation, wat inhoudt dat de verschillende onderdelen van het OS in aparte VM's draaien. In tegenstelling tot bijvoorbeeld VMware Workstation en Virtualbox is er geen host-OS, maar draaien de VM's direct op de aanwezige hardware. De virtualisatie wordt door bare-metal hypervisor Xen verzorgd en voor de gebruikersomgeving kan onder meer worden gekozen uit Fedora, Debian, Whonix en Windows. Meer informatie over Qubes OS kan op deze pagina worden gevonden. De releasenotes voor deze uitgave zijn hieronder voor je op een rijtje gezet.

Qubes OS 4.2.4 has been released!

We’re pleased to announce the stable release of Qubes OS 4.2.4! This patch release aims to consolidate all the security patches, bug fixes, and other updates that have occurred since the previous stable release. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO. The ISO and associated verification files are available on the downloads page.

What’s new in Qubes 4.2.4?

• All security updates to date
• All bug fixes to date
• Included Fedora template upgraded from Fedora 40 to 41

For more information about the changes included in this version, see the Qubes OS 4.2 release notes and the full list of issues completed since the previous stable release.

Versienummer	4.2.4
Releasestatus	Final
Website	Qubes OS
Download	https://www.qubes-os.org/doc/QubesDownloads/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (16)

[NitSuA]

Goed, ik heb hier geen verstand van, maar waarom wordt het OS verdeeld over verschillende VM's en niet over verschillende containers? Lijkt mij veel minder overhead. Als de VMs gekozen zijn als security maatregel, zit er dan niet iets al intrinsiek niet goed in het ontwerp van het OS? Het voelt allemaal een beetje omslachtig (houtjetouwtje), maar zoals ik al zeg, ik ben een noob in dit onderwerp. Het geeft mij een 'omdat het kan' gevoel, maar lost het nu echt een reeel veiligheidsrisico op?

[Reactie gewijzigd door NitSuA op 18 februari 2025 13:06]

[DigitalExorcist]

Containers delen teveel met het host-OS en zijn dus bij voorbaat al niet betrouwbaar.

[zenlord]

Dat is toch wat kort door de bocht. Als je natuurlijk docker rootful uitvoert op een host network omdat het snel moet gaan, dan ga ik je stelling zeker niet ondergraven. Maar met technologieën zoals cGroups en user namespaces kan je rootless containers draaien die veel voordelen van vm's delen zonder de nadelen.
En uiteraard heb je ook nog tussenliggende vormen zoals BSD Jails en LXC/D.

[WigaDan]

Hier nog wat uitleg van de Qubes-OS website zelf:

¨¨¨¨¨¨
Throughout our lives, we engage in various activities, such as going to school, working, voting, taking care of our families, and visiting with friends. These activities are spatially and temporally bound: They happen in isolation from one another, in their own compartments, which often represent an essential safeguard, as in the case of voting.

In our digital lives, the situation is quite different: All of our activities typically happen on a single device. This causes us to worry about whether it's safe to click on a link or install an app, since being hacked imperils our entire digital existence.

Qubes eliminates this concern by allowing us to divide a device into many compartments, much as we divide a physical building into many rooms. Better yet, it allows us to create new compartments whenever we need them, and it gives us sophisticated tools for securely managing our activities and data across these compartments.

¨¨¨¨¨¨¨

[beerse]

Als je een container vergelijkt met een virtuele-machine, even los van details uit qubes;

Een container krijgt toegang tot die delen van de host waar ze recht op heeft meer niet. Maar die rechten krijgt ze dan ook volledig en alsof ze lokaal draait. Hier geen simulatie of vertaling of zo iets. De software die buiten de container draait kan zonder problemen in de container kijken en doen, daar is geen beperking.

Een vm is zelf een volledige machine met alles er in. Binnen die machine kan en mag ze alles alsof het een fysieke machine is. Alle hardware wordt echte gesimuleerd door de host. Er vind dus een zekere vertaal slag plaats. De software die buiten de vm draait ziet 1 process, dat van de vm. En de processen die de virtuele hardware simuleren.

Hoe deze details in qubes worden ingezet, dat heb ik zelf nog niet op een rijtje gezet. Overigens zijn er bij diverse implementaties van containers en virtuele machines wat detail verschillen maar globaal komt het wel op het bovenstaande neer.

[valhalla77]

Dit systeem is niet voor iedereen bedoeld, maar het design is doordacht. De kern ligt in de compartimentalisering van het besturingssysteem, waarbij VM's nooit directe toegang hebben tot Dom0 (de kernomgeving). Hardware wordt bewust gescheiden vanwege potentiële security bugs in firmware en drivers. Zo draait de netwerkstack in een apart Network Domain, en USB-toegang in weer een ander domain. Door de rechten per domain tot een minimum te beperken, kan bij een compromis slechts één onderdeel worden getroffen in plaats van het hele systeem. Het regelmatig vervangen van VM's, vergelijkbaar met containers, versterkt deze beveiliging verder.
De keuze voor VM's is historisch verklaarbaar: dit concept bestaat al sinds 2012, toen containers nog niet wijdverbreid waren (Kubernetes kwam pas in 2014). Xen staat bekend als een veilige hypervisor en wordt bijvoorbeeld in auto's gebruikt om de boordcomputer te scheiden van het entertainmentsysteem.
Voor desktop-gebruik zou een vergelijkbaar veilig systeem gebaseerd op Kubernetes, met name wat betreft de hardware-stack scheiding, aanzienlijk complexer zijn om te implementeren.

[Digimann]

Xen staat bekend als een veilige hypervisor en wordt bijvoorbeeld in auto's gebruikt om de boordcomputer te scheiden van het entertainmentsysteem.

Heb je refenties hierover? Ik had hier namelijk nog nooit iets over gelezen

[valhalla77]

https://xenproject.org/projects/embedded-and-automotive/ en https://www.epam.com/cont...ation_by_Xen_Brochure.pdf

[Digimann]

bedankt!!

[rob12424]

Uhm dit is wel een Hardened Xen omgeving. De standaard Xen hypervisor zaten destijds nog aardig wat gevaarlijke bugs in

[s.dehaan]

Containers delen de kernel-space, een infiltratie van je kernel-space betekend dat alle containers compromised zijn. Bij volledige virtualisatie heb je alleen die ene VM die volledig overgenomen is. Maar niet de rest.

[zenlord]

Juist, maar als je rekening houdt met een infiltratie van je kernel-space, dan is niets nog veilig hoor: noch containers, noch virtuele machines.
Ik wil zeker niet zeggen dat je daar geen rekening moet mee houden, maar je hebt het over de meest ingrijpende security breach die je je maar kan voorstellen. Er zijn heel wat andere vormen die veel vaker voorkomen, bvb een security breach van een container die leidt tot escalatie naar de host. En dat kan in principe niet met een virtuele machine.

[rob12424]

Daarvoor bestaan dingen als tripwire enz. Dat zit hier overigens ook in de IDS ingebouwd.

1 van de oprichters hiervan is een bekende vrouwelijke blackhat hacker. Ze zijn echt niet over 1 nacht ijs gegaan met het ontwerp.

[Matthijs8]

Je kunt uit een container breken met een kernel exploit. Bij een VM geeft je dat alleen controle over de VM. Je hebt ook nog een hypervisor exploit nodig om bij ander VM's te kunnen. De hypervisor heeft een veel kleinere attack surface waardoor dit een stuk lastiger is. Xen heeft bovendien vergeleken met andere hypervisors zoals KVM ook sowieso ene kleinere attack surface. Qubes heeft dit ook verder gehardened dan Xen standaard doet.

[Marve79]

In principe niet, toch zijn er genoeg bekende gevallen.

Even ChatGPT gevraagd:

Xen Hypervisor Vulnerabilities (VENOM - CVE-2015-3456)

A flaw in the virtual floppy disk controller used in QEMU (which Xen, KVM, and other hypervisors relied on) allowed a guest VM to execute arbitrary code on the host.
This meant an attacker could escape a VM and execute malicious actions at the hypervisor level.

Cloudburst Attack (2009 - VMware)

A proof-of-concept attack demonstrated at Black Hat showed how a vulnerability in VMware Workstation allowed a guest VM to break out and execute code on the host.

[valhalla77]

Dubbel

[Reactie gewijzigd door valhalla77 op 18 februari 2025 14:23]