I used it when I worked as a hiring manager. For this task it is ideal. All the behavioral security measures, like only to open attachments from people you trust, break down when your job description is basically to figure out who you can trust.
Qubes comes with a "Convert to trusted PDF" out of the box. Joanna Rutkowska explained how it works under the hood pretty nicely[1]. The tldr is that it is very thorough. With Qubes it is convenient too.
I used Qubes to open the application mails and their attachments and converted the interesting ones to trusted PDFs which I then forwarded to the relevant people. All further communication was only with the trusted versions.
The problem is that containers rely on the OS kernel to enforce separation, and kernel exploits are an awful lot less rare than anyone would prefer.
If someone is delivering targeted malware to a company through HR channels, it's safe to assume that if they can escape the document viewer, they can probably also try for a local root/kernel exploit and escape the container.
Containers are separation of convenience - not a hard security boundary.
Dangerzone is an implementation of a concept known as CDR (Content Disarm & Reconstruction), where you convert anything to an image inside a sandbox, and then convert the raw pixel data back into an image inside a different sandbox.
It is a common workflow inside the government or other places where you need to move data across airgaps, or view content that is highly untrusted.
Shameless plug, I wrote my own that supports over 200 file formats: https://preview.ninja/
I didn't know about that but that looks really nice. From a quick glance I understand that they can even utilize OCR to make the trusted PDF into more than an image container. Back in the day when I used Qubes it could not do that. (I haven't used it for a while so I don't know if it can now)
I still think security-wise Qubes is a bit better because it relies on VMs instead of containers.
I personally daily drove QubesOS for about half a year when in school, and personally, I loved it. When I first tried it out, I fully expected it to be a nightmare to use, given that's how it's usually advertised by non-users. But in using it, I really enjoyed its workflow and the seamless compartmentalization of applications on a computer.
Program isolation is honestly a feature that other distros should use more often. The idea that programs can only access networks, USB devices, files, and X windows of programs that it's been explicitly let to access is an extremely useful tool that isn't just for people who are worried about government surveillance.
I personally enjoyed having about 5 different Firefox apps that each led to their own VM with its own files, browser history, cookies, and extensions, and even networks that automatically put traffic through a VPN at times. Chrooting and Firefox profiles only help so much, if you can even set them up to be as seamless as Qubes.
I'm of course not getting into the security benefits and all that of Qubes, but its where I feel a lot of people don't realize the benefits of an OS like this. The workflow improvement is just as inspiring as the security improvement from the system.
My laptop broke and I had to buy a new one. The new one was intel 12th gen, which was unsupported at the time.
Why haven't I come back to it? I now often use programs that require hardware acceleration for optimal use, which is unsupported by Qubes due it being a potential security issue. If you mainly use your laptop for non-intensive tasks though, I still highly recommend.
I highly recommend it. Since I tried it a couple of years ago I can't imagine working without it.
Examples of things that I can't imagine doing in any other system:
- curl|bash or similar
- pip install, npm install etc
- run any random github project
- sudo install the drivers of my Brother printer
- install zoom
- plug random cheap USB devices to eg update their firmware
In addition to that you can easily restart frozen VMs without restarting the whole system, keep backups of your VMs (very handy when restoring or changing PCs), reinstall some VMs if you mess up, etc.
Not suitable is for GPU intensive work, though (although if you have a dedicated GPU in theory you can assign it to a VM).
Ashamed to say but I do all these things on my main OSs for ~15 years and I never had any problem (IIRC). Yes, I'm not huge on security and I realize what this could do, but I figure the chance is as big as getting it through a channel I don't expect.
I hadn't checked on this project in some time, and last I looked it seemed to be stagnant. Good to see it going strong again.
I just remember that, hardware wise, there wasn't a lot of things that could run all aspects of the OS and be 100% with it. The "certified hardware" on the site also looks like it's out of date.
It has remained quite active since I started using Qubes in 2016. I think when Joanna left day to day work it's possible things slowed a bit but I didn't have enough context since that wasn't long after I started.
Based on hanging out in the support forums it seems like there have been some pretty large groups of new users, honestly I have no idea why many came at once but they did. Of course for a project this small, "large" is relative.
The current work includes making dom0 smaller by delegating the gui to a service Qube.
What kind of threat model requires someone to use Qubes? I know Snowden uses it and there's even a testimonial of him on the Qubes site recommending it. Is this for people on 'lists' or are high value targets because they visited the wrong site or said something the authorities didn't like and their machines are now being targeted?
I know what Theo says about (x86) virtualization[1], but I think it's still useful to virtually separate your random browsing the web from things like health and banking, or where you keep your ssh keys (if you don't use a Yubikey or similar to keep it off your laptop) -- or other secrets.
You can be a victim of a random drive-by, you don't have to be a person on a "list".
Yeah. He's probably right. When we first saw Meltdown/Spectre/etc, and he preemtively disabled hyperthreading out of an abundance of paranoia, turned out he was right...
It's all broken, all the way down. However, compromising a browser or kernel is still a lot easier than compromising a hypervisor. At least in terms of number of known exploits.
Qubes tends to make very limited use of the riskier parts of Xen anyway, though. A lot of the security notices for Xen don't apply to Qubes because of how they've configured things or what features they use.
> What kind of threat model requires someone to use Qubes?
"Not trusting modern software to be correct nor secure" is sufficient.
I do almost all my web browsing in disposable VMs with no access to interesting things like my password manager, email, SSH keys, etc. I also run JITless (disable Javascript JIT engine), because those are a common attack point on browsers.
If you compromise my browser from a random site, you get nothing of interest. Even if you pop the kernel. You still have to get through Xen to get to anything I consider of value.
I used it for sifting through job applications (see my other comment).
I think it was worth it because even though we were a small boring company we received a fair share of drag-net style malware via the application channels.
Some of the attempts were pretty good also. I used to joke that the bad guys tailor their cover letters better than most real applicants. Which of course is a bit of a hyperbole, but there is a kernel of truth. It's not too hard to write a believable application letter that fits the archetypal IT position. Similar to not all fishing mails being full of spelling errors malicious application letters aren't either.
I don't know if we ever received a targeted attack, but I wouldn't know. I think bigger companies certainly will and I can only consider every HR department a high risk area.
I'd say everyone that has the ability to use it. Society is in a dark age where basically nothing else is fit for use; one bad click on most machines could compromise you for years, it is an insane situation. Even if you have other needs that can't be fulfilled with Qubes, you should have a Qubes machine for other tasks that are security-sensitive
Honestly you don't need to be super paranoid to benefit from Qubes. Windows and Linux default sandboxing is still pretty mediocre at best, people can't be perfect with security all the time and sometimes even legit programs get compromised, so the sandboxing security model helps contain the damage.
That said you can still setup sandboxing without Qubes.
I really like QubesOS, but you cannot run VMs inside a qube, or other things that require VMs like Docker Desktop for Linux, because the xen hypervisor does not support nested virtualization.
It's a good question - docker doesn't require a VM on Linux, but Docker Desktop does. I assume it's to make it basically the same experience as on Docker Desktop on Windows and macOS, but I'm not totally sure. You can install docker the same way one would on a server in a qube in QubesOS and it works fine, I think I tried that once just to be sure, I just wanted to be able to have Docker Desktop. I also didn't want to paint myself into a corner in case I should need to run something else that also expects to be able to run a VM.
> Huh… why does Docker require VMs on Linux? Isn’t the selling point of Docker that it uses the same kernel on Linux?
docker has been playing rather loose with security for quite a long time in the past, so I per-se wouldn't trust it to be secure
additionally there are (oversimplified) 3 ways to run it:
1. a "root" deamon, the default docker daemon setup in most distros and the way docker originally was designed to be used. This is needed for some advanced (non secure) features (which IMHO should not exist) but has pretty serve security issues IMHO, like either being in the docker group being a de-facto root/sudo or it forcing you to use sudo all the time and bugs in the docker deamon potentially leading to catastrophic exploits.
2. as a unprivileged user using cgroupsv2 like podman does by default, this has some limitations but works really well and as long as "linux containers" are secure it should be secure (oversimplified). Still the security of containers isn't perfect as they share the kernel. As a rule of thump only use if you get reliable kernel security updates.
3. starting VMs, much more overhead in many ways and needing virtualization, but works with old "outdated" kernels or hardened kernels(1) not allowing unprivileged cgroups
The 3rd method is the most secure and works across most dirstros/linux setups even if unusual setup and is the same kind of path docker takes on windows/mac. So no wonder a product like Docker Desktop uses it. Also the overhead of virtualization is today not "that" bad.
The the first method is still the default method for docker CLI on most linux distros is honestly far beyond my understanding. In the past pre reliable cgroups v2, maybe, but today omg no. It has some valid use cases, but the default should be VMs or unprivileged containers especially on desktop systems (whatever distro maintainers prefer).
----
(1): On instresting conflict is security hardening vs. unprivileged cgroups/containers. On one side unprivileged cgroups allow a lot of additional security. For example they allow running various sandboxes without needing a suid binary or using sudo for setting up the sandbox. Which is really grate. At the same time (oversimplified) it increases the security sensitive kernel interface by a non negligible margin, which isn't grate and hence why hardened linux often disables it by default.
EDIT: Sorry for the bad spelling, I need to go to bed.
Shoot, as soon as I hit reply some neurons lit up and now I remember I was actually able to enable nested virtualization in QubesOS, and the relevant options in the VirtualBox preferences inside a qube became enabled once I did that, but whenever I tried booting any VM the whole system hanged. The same system and BIOS settings worked in Ubuntu to boot a nested VM in VirtualBox, so I think I had the BIOS settings correct. Anyhow, it seemed like a dead-end, so I abandoned it.
I did that very thing about a year ago when I still had QubesOS installed, and it did not work. There seems to be a lot of misinformation about this swirling around the web. It simply does not work. There is a post somewhere that confirms it but I don't have the link. Unless the QubesOS devs/maintainers made a 180 degree turn since I tried it and decided to start compiling QubesOS with xen nested virtualization enabled, but I doubt it because their reason was that xen's nested virtualization feature is basically broken anyway.
If your hypervisor supports nested virtualization, it should work. It'll probably grumble about the lack of IOMMU and various other things, but you should be able to run it in VMWare or KVM, if you're willing to jump through some hoops.
Not sure why you'd bother, though. If you're already spinning up VMs, just use that capability. Qubes makes "spinning up a ton of VMs on the iron" a lot easier and more usable.
As someone who often runs multiple entire virtualized datacenters on top of ESXi hosts which are actually virtual machines themselves running in ESXi, I highly disagree.
Nested virtualization is a game changer in any kind of lab scenario. It also runs great on Chromebooks. The ChromeOS Linux environment is actually a KVM, so launching virtual machines from there is nested but you would never know it (based on my experience with the (framework Chromebook edition). Having 64GB of memory doesn't hurt either of course.
I use Qubes because of one exact feature: single Desktop Environment for windows from different Virtual Machines. And AFAIK there are no alternatives.
Use it for work, development, personal tasks for about 2 years so far.
But it has many restrictions, e.g. gaming is problematic because of this single "main" desktop and trucking cursors bug, recording screen when there are several monitors is bugging and problematic, streaming or working with graphics is problematic, development that requires other virtualization like android (as i heard) is problematic (though docker works, tested).
This OS is enough for my tasks, I like concept of separating activities, e.g. when i share desktop on skype, people see only skype's VMs windows. And single Desktop Env is killer feature.
But because of many restrictions this OS is definitely not for everyone.
QubesOS is very cool but I've always thought it'd cool/better if it was a patchset or repo on top of an existing distro like Archlinux or NixOS. I think that would be useful so you could adopt features from QubesOS individually and swap out different components. For example, it'd be nice to use KVM (QEMU or even crosvm) instead of Xen or build a Wayland based system instead of X11.
They did consider KVM initially; I don't know how much things have changed and if they've reconsidered. The reasoning was that KVM's means of virtualization is too closely coupled with the Linux kernel, whereas Xen's hypervisor and dom0 are more separable.
> In Xen, at no point does the execution path jump out of the hypervisor to e.g. Dom0. Everything is contained within the hypervisor. Consequently itʼs easier to perform the careful security code audit of the Xen hypervisor, as itʼs clear which code really belongs to the hypervisor.
If you have the skills to port the tools to KVM, please do so. There's a shortage of sufficiently paranoid low level sorts with the time and interest in the hacking on Qubes.
Readit News
Qubes comes with a "Convert to trusted PDF" out of the box. Joanna Rutkowska explained how it works under the hood pretty nicely[1]. The tldr is that it is very thorough. With Qubes it is convenient too.
I used Qubes to open the application mails and their attachments and converted the interesting ones to trusted PDFs which I then forwarded to the relevant people. All further communication was only with the trusted versions.
[1] https://blog.invisiblethings.org/2013/02/21/converting-untru...
If someone is delivering targeted malware to a company through HR channels, it's safe to assume that if they can escape the document viewer, they can probably also try for a local root/kernel exploit and escape the container.
Containers are separation of convenience - not a hard security boundary.
It is a common workflow inside the government or other places where you need to move data across airgaps, or view content that is highly untrusted.
Shameless plug, I wrote my own that supports over 200 file formats: https://preview.ninja/
I still think security-wise Qubes is a bit better because it relies on VMs instead of containers.
Program isolation is honestly a feature that other distros should use more often. The idea that programs can only access networks, USB devices, files, and X windows of programs that it's been explicitly let to access is an extremely useful tool that isn't just for people who are worried about government surveillance.
I personally enjoyed having about 5 different Firefox apps that each led to their own VM with its own files, browser history, cookies, and extensions, and even networks that automatically put traffic through a VPN at times. Chrooting and Firefox profiles only help so much, if you can even set them up to be as seamless as Qubes.
I'm of course not getting into the security benefits and all that of Qubes, but its where I feel a lot of people don't realize the benefits of an OS like this. The workflow improvement is just as inspiring as the security improvement from the system.
Not suitable is for GPU intensive work, though (although if you have a dedicated GPU in theory you can assign it to a VM).
Deleted Comment
I just remember that, hardware wise, there wasn't a lot of things that could run all aspects of the OS and be 100% with it. The "certified hardware" on the site also looks like it's out of date.
Concerning the certified hardware, few vendors try to make the certification, and also coreboot is required: https://www.qubes-os.org/doc/certified-hardware/#hardware-ce...
Based on hanging out in the support forums it seems like there have been some pretty large groups of new users, honestly I have no idea why many came at once but they did. Of course for a project this small, "large" is relative.
The current work includes making dom0 smaller by delegating the gui to a service Qube.
You can be a victim of a random drive-by, you don't have to be a person on a "list".
[1] https://marc.info/?l=openbsd-misc&m=119318909016582
It's all broken, all the way down. However, compromising a browser or kernel is still a lot easier than compromising a hypervisor. At least in terms of number of known exploits.
Qubes tends to make very limited use of the riskier parts of Xen anyway, though. A lot of the security notices for Xen don't apply to Qubes because of how they've configured things or what features they use.
"Not trusting modern software to be correct nor secure" is sufficient.
I do almost all my web browsing in disposable VMs with no access to interesting things like my password manager, email, SSH keys, etc. I also run JITless (disable Javascript JIT engine), because those are a common attack point on browsers.
If you compromise my browser from a random site, you get nothing of interest. Even if you pop the kernel. You still have to get through Xen to get to anything I consider of value.
It's not unthinkable, as Xen is huge, at hundreds of kLoCs. But there's an effort[0] to make a Qubes that uses seL4 in place of Xen.
0. https://trustworthy.systems/projects/TS/makatea
I think it was worth it because even though we were a small boring company we received a fair share of drag-net style malware via the application channels.
Some of the attempts were pretty good also. I used to joke that the bad guys tailor their cover letters better than most real applicants. Which of course is a bit of a hyperbole, but there is a kernel of truth. It's not too hard to write a believable application letter that fits the archetypal IT position. Similar to not all fishing mails being full of spelling errors malicious application letters aren't either.
I don't know if we ever received a targeted attack, but I wouldn't know. I think bigger companies certainly will and I can only consider every HR department a high risk area.
That said you can still setup sandboxing without Qubes.
Qubes is my daily driver by the way. My attempt of explaining it to a layman: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Browser escapes are cheap enough and common enough that we've seen malware delivered through advertising networks before.
And it should be quite lightweight as it’s just a container…
It’s not that I don’t believe you but I don’t understand it… why would you need VM on Linux for Docker?
edit: huh
https://docs.docker.com/desktop/faqs/linuxfaqs/#:~:text=Dock....
that’s… a bit stupid in my opinion. But you can always just use the default daemon so, eh. whatever. maybe I’m wrong. there are reasons I guess
docker has been playing rather loose with security for quite a long time in the past, so I per-se wouldn't trust it to be secure
additionally there are (oversimplified) 3 ways to run it:
1. a "root" deamon, the default docker daemon setup in most distros and the way docker originally was designed to be used. This is needed for some advanced (non secure) features (which IMHO should not exist) but has pretty serve security issues IMHO, like either being in the docker group being a de-facto root/sudo or it forcing you to use sudo all the time and bugs in the docker deamon potentially leading to catastrophic exploits.
2. as a unprivileged user using cgroupsv2 like podman does by default, this has some limitations but works really well and as long as "linux containers" are secure it should be secure (oversimplified). Still the security of containers isn't perfect as they share the kernel. As a rule of thump only use if you get reliable kernel security updates.
3. starting VMs, much more overhead in many ways and needing virtualization, but works with old "outdated" kernels or hardened kernels(1) not allowing unprivileged cgroups
The 3rd method is the most secure and works across most dirstros/linux setups even if unusual setup and is the same kind of path docker takes on windows/mac. So no wonder a product like Docker Desktop uses it. Also the overhead of virtualization is today not "that" bad.
The the first method is still the default method for docker CLI on most linux distros is honestly far beyond my understanding. In the past pre reliable cgroups v2, maybe, but today omg no. It has some valid use cases, but the default should be VMs or unprivileged containers especially on desktop systems (whatever distro maintainers prefer).
----
(1): On instresting conflict is security hardening vs. unprivileged cgroups/containers. On one side unprivileged cgroups allow a lot of additional security. For example they allow running various sandboxes without needing a suid binary or using sudo for setting up the sandbox. Which is really grate. At the same time (oversimplified) it increases the security sensitive kernel interface by a non negligible margin, which isn't grate and hence why hardened linux often disables it by default.
EDIT: Sorry for the bad spelling, I need to go to bed.
https://forum.qubes-os.org/t/nested-virtualization/14790
Poke around /etc/libvirt/libxl and your particular VM's config file. You'll find some lines like:
<feature name='vmx' policy='disable'/> <feature name='svm' policy='disable'/>
Enable it, and you should have working nested virtualization.
Not sure why you'd bother, though. If you're already spinning up VMs, just use that capability. Qubes makes "spinning up a ton of VMs on the iron" a lot easier and more usable.
Such abstraction is very unstable. You can always VNC into a machine from a browser though, so 'vmception' can be achieved.
Nested virtualization is a game changer in any kind of lab scenario. It also runs great on Chromebooks. The ChromeOS Linux environment is actually a KVM, so launching virtual machines from there is nested but you would never know it (based on my experience with the (framework Chromebook edition). Having 64GB of memory doesn't hurt either of course.
Deleted Comment
Use it for work, development, personal tasks for about 2 years so far.
But it has many restrictions, e.g. gaming is problematic because of this single "main" desktop and trucking cursors bug, recording screen when there are several monitors is bugging and problematic, streaming or working with graphics is problematic, development that requires other virtualization like android (as i heard) is problematic (though docker works, tested).
This OS is enough for my tasks, I like concept of separating activities, e.g. when i share desktop on skype, people see only skype's VMs windows. And single Desktop Env is killer feature.
But because of many restrictions this OS is definitely not for everyone.
Unrelated to QubesOS.
Or even better, seL4, for which an effort exists[0].
0. https://trustworthy.systems/projects/TS/makatea
> In Xen, at no point does the execution path jump out of the hypervisor to e.g. Dom0. Everything is contained within the hypervisor. Consequently itʼs easier to perform the careful security code audit of the Xen hypervisor, as itʼs clear which code really belongs to the hypervisor.
From the original 0.3 spec
Getting it working on ARM is also of interest.