Software-update: Qubes OS 4.2.1

Qubes OS logo (75 pix) Versie 4.2.1 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 uit Fedora, Debian, Whonix en Windows worden gekozen. Meer informatie over Qubes OS kan op deze pagina worden gevonden. De releasenotes voor deze uitgave zijn hieronder voor je op een rijtje gezet.

What’s new in Qubes OS 4.2.1?

Qubes 4.2.1 includes numerous updates over the initial 4.2.0 release, in particular:

  • All 4.2 dom0 updates to date
  • Fedora 39 template
  • Linux 6.6.x as the default kernel, significantly reducing the need for kernel-latest on newer systems

For more information about the changes included in this version, see the full list of issues completed since the release of 4.2.0.

Applications running in different security domainsQubes OS arch diagram
Versienummer 4.2.1
Releasestatus Final
Website Qubes OS
Download https://www.qubes-os.org/doc/QubesDownloads/
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

27-03-2024 • 19:50

12

Submitter: danmark_ori

Bron: Qubes OS

Update-historie

18-02 Qubes OS 4.2.4 16
18-09 Qubes OS 4.2.3 5
07-'24 Qubes OS 4.2.2 5
03-'24 Qubes OS 4.2.1 12
12-'23 Qubes OS 4.2.0 11
07-'22 Qubes OS 4.1.1 0
02-'22 Qubes OS 4.1.0 8
10-'15 Qubes OS 3.0 22
Meer historie

Reacties (12)

12
12
6
0
0
6
Wijzig sortering
Ik heb dit OS een aantal jaar geleden gebruikt, maar toen was het meer een idee dan een praktische tool naar mijn idee, is dit al wat verbeterd? Het idee is wel interessant.
Ik heb dit OS een aantal jaar geleden gebruikt, maar toen was het meer een idee dan een praktische tool naar mijn idee, is dit al wat verbeterd? Het idee is wel interessant.
Network chuck heeft er wel een stuk over. https://www.youtube.com/watch?v=i3sRSS6fN0g
Zelf staat het bij mij nog op het lijstje om eens uit te proberen, Al denk ik dat ik met 32gb niet genoeg heb voor dagelijks gebruik.

[Reactie gewijzigd door Cybermage op 26 juli 2024 16:15]

Moeilijk doen voor iets wat OS functionaliteit hoort te zijn. Procesisolatie.
Dit gaat nog wel iets verder dan standaard procesisolatie. Isolatie van processen wordt afgedwongen door de kernel en gebeurd op de meeste OS-en al, maar als jij het recht hebt om processen op kernel niveau uit te voeren kan je dit omzeilen. Legitiem gebruik daarvan is bijvoorbeeld een debugger, een semi-legitiem voorbeeld is een kernel-level anti-cheat oplossing in een game, maar het kan net zo goed worden misbruikt door malware. Bij Qubes OS moet je uit de Xen hypervisor zien te breken om bij de processen in een andere VM te komen. Ik zeg niet dat het onmogelijk is want het blijft software, maar het is een stuk complexer.

edit: bewoording wat aangepast ter verduidelijking.

[Reactie gewijzigd door rbr320 op 26 juli 2024 16:15]

Ow boy dat gaat wel wat geheugen vreten :o
Het is mijn dagelijks systeem. Embedded development vergt soms wat extra geduld, heel soms moet ik daarvoor een andere machine pakken die dan multi boot in net welk OS ik nodig heb. Maar veruit het meeste gaat vanuit Qubes voor mij goed genoeg.
Grootste issue is de basis. Uit de User FAQ https://www.qubes-os.org/faq/#users
What is the recommended build environment for Qubes OS?

Any rpm-based, 64-bit environment, the preferred OS being Fedora.

Dat is wel beter dan vroeger want toen was het echt helemaal embedded in Fedora. Dat is dus een absolute no-go. Tegenwoordig kun je dus theoneetisch naar een andere rpm-based distro zoals OpenSUSE, Mageia, RockyLinux, RegataOS, PCLinuxOS, of openmamba GNU/Linux maar in de praktijk zal je daar toch wel een hoop horden moeten overwinnen (en dan zit je nog steeds vast aan rpm.
Dit is net zoiets als zeuren dat Proxmox Debian-based is ipv RPM-based. Ja, je zult de tooling van het onderliggende OS moeten gebruiken. Maar daar bovenop kun je gebruiken wat jij wilt. En dat moet je ook lekker doen.
Dit is net zoiets als zeuren dat Proxmox Debian-based is ipv RPM-based.
Niet helemaal. In Debian en in vele andere distro's kun je als het moet rpm-packages installeren via alien, maar als je dus met een rpm-based distro moet beginnen zit je dus al vast in een verkeerde distro, vooral als dat Fedora moet zijn.

Het klopt dat Proxmox Debian-based is, maar je kunt het dus in principe op alle Debian-based distro's installeren. Daarnaast is het in deb-based distro's net wat makkelijker om systemd overboord te gooien.

Een tweede verschil is dat je voor Proxmox genoeg alternatieven hebt, Xen, KVM, Qemu, ... daar kun je dus iets anders kiezen als je niet aan Debian vast wilt zitten. Iets vergelijkbaars als Cubes is er elders niet.
Ja, je zult de tooling van het onderliggende OS moeten gebruiken.
Of je ziet er compleet vanaf om die reden.
Maar daar bovenop kun je gebruiken wat jij wilt. En dat moet je ook lekker doen.
Als de basis niet bevalt gaat de rest ook niet bevallen, ongeacht wat je er bovenop gooit.
.rpm is binary troep, .deb is een archive. Een .deb kun je dus veel makkelijker installeren op een non-Debian OS. Hoe dan ook werkt het alleen met statisch gelinkte libraries. Anders krijg je dependancy hell.

Maar het is hoe dan ook helemaal niet de bedoeling dat je dergelijke binaries gaat installeren op je hypervisor/rootfs. Dus non-argument.

Ik vind Fedora niks, nutteloos. Behalve dan als je zeer bekend bent met RedHat tooling (of dat wilt/moet worden). Wat mij betreft switchen ze naar Debian-based.

Maar een dealbreaker, dat is het niet. Want je hebt nauwelijks iets met dat OS te maken. Als je het goed doet.
.rpm is binary troep, .deb is een archive.
.deb kan binary of source zijn, maar .deb heeft veel betere dependency-controle en checkt dat ook bij verwijderen - al zou dat laatste beter kunnen.
Maar het is hoe dan ook helemaal niet de bedoeling dat je dergelijke binaries gaat installeren op je hypervisor/rootfs. Dus non-argument.
Hoe installeer je nieuwe kernels, hoe installeer je distrio-updates? Je hypervisor/rootfs wil je inderdaad zo schoon mogelijk houden, maar je zult toch bepaalde tools nodig hebben en niet iedereen is een fan van emacs, vi en dergelijke om er maar een paar te noemen.
Ik vind Fedora niks, nutteloos. Behalve dan als je zeer bekend bent met RedHat tooling (of dat wilt/moet worden).
Voordat Fedora bestond, toen Red Had was wat nu Fedora is hebben ze veel betekend voor de Linux-wereld, Er was de Red Hat Certified System Engineer als tegenhanger van de Microsoft Certified System Engineer (en ja daar was toen maar één variant van). Er zijn echter een handvol punten waarop ik Fedora en Red Hat resoluut afwijs, en dat is niet eens zozeer dat ze zelf rpm gebruiken, maar dat ze overal hun dingen als verplichte standaard afdwingen, zoals
* rpm in de Linux Standard Base
* de verouderde Filesystem Hierarchy Standard
Portage, ebuild, deb, nixpkgs zijn net zo goed en met war Gobolinux gebruikt heb je zelfs aan een source tarball genoeg.
Wat mij betreft switchen ze naar Debian-based.
Min-of-meer, ook Debian gebruikt intussen systemd.
Maar een dealbreaker, dat is het niet. Want je hebt nauwelijks iets met dat OS te maken. Als je het goed doet.
Je moet het toch onderhouden, security-updates installeren enzovoorts.
Nee, RPM is een binary formaat. Terwijl .deb een archive is. Een archive kun je uitpakken met standaard tooling. Untar maar eens een .deb

Persoonlijk installeer ik Rust, cargo, cargo install topgrade en dan gebruik ik die. Werkt op vrijwel alles.

Security updates kan met unattended upgrades.

Op dit item kan niet meer gereageerd worden.