Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want.
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/
> Apart from the fact that this is extremely rare,
So are bubblewrap escapes, which is the sandbox flatpak uses.
> the first vulnerability is not a complete escape.
It could potentially lead to one, and being able to obtain information from other VMs defeats much of the point of isolation, and so defeats much of the point of why people use qubes.
> For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
That's not true. Strong MAC would suffice, no VT-d needed.
> Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology
Of course they do, in fact they have more to do with it than solutions like flatpak, which is why Qubes releases security advisories and patches to address those vulnerabilities.
>> Apart from the fact that this is extremely rare,
> So are bubblewrap escapes, which is the sandbox flatpak uses.
Not only they are much more frequent, including possibly kernel privilege escalations, not affecting Qubes, - the bubblewrap repository itself says that you have to be really careful to stay secure with it, even in the lack of vulnerabilities. This is not what people should seriously rely on. Again, my secrets in vault VM are safe since the introduction of VT-d in Qubes 4.0 in ~2021. There is no comparably secure OS in the world.
I don't understand your unsubstantiated attack on Qubes.
> and being able to obtain information from other VMs defeats much of the point of isolation
It does not. Even if a VM becomes hostile and starts reading the RAM, it will not get any privileges in any other VM. Also, it can be easily cleaned. Also, you can just stop all VMs when performing a secure operation. Tell me how you protect yourself in such case with Flatpak.
> Not only they are much more frequent, including possibly kernel privilege escalations,
No, that's simply not the case.
> not affecting Qubes,
Maybe, qubese would still be vulnerable to kernel vulnerabilities even if they didn't allow VM escape - anything in the disposable VM would be at risk.
> the bubblewrap repository itself says that you have to be really careful to stay secure with it, even in the lack of vulnerabilities.
Source? I assume they are referring to misconfigurations.
> There is no comparably secure OS in the world.
You've said before you don't have a lot of security knowledge and it continues to show. Qubes is one specific approach to a problem not suitable for all goals, it's useful for hobbyists who use browsers and such. Anything in the disposable VM is still at risk.
SEL4, ASOS and CuBit are all more secure than Qubes. Qubes doesn't offer any more security than having a bunch of different machines to do different tasks on. Not even airgapped. If the machines have a vulnerability, then whatever is on the machine is fair game.
> I don't understand your unsubstantiated attack on Qubes.
There is no attack, I'm just refuting your preposterous zealotry for it. It's fine for what it is, but you make it much more than what it is. The developers of Qubes would absolutely disagree with your claims.
> Even if a VM becomes hostile and starts reading the RAM, it will not get any privileges in any other VM.
You keep repeating this without providing any actual statistics. I provided statistics about Qubes vulnerabilities, https://www.qubes-os.org/security/xsa/. Show me the numbers please.
> anything in the disposable VM would be at risk.
This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It's in the name: Disposable. Moreover, nothing prevents you from running Bubblewrap inside Qubes. Then one single VM will be as secure as your whole setup, and in addition, you get reliable isolation.
> Source? I assume they are referring to misconfigurations
> bubblewrap is not a complete, ready-made sandbox with a specific security policy.
> As a result, the level of protection between the sandboxed processes and the host system is entirely determined by the arguments passed to bubblewrap.
> Everything mounted into the sandbox can potentially be used to escalate privileges.
This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
> Anything in the disposable VM is still at risk.
Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
> You've said before you don't have a lot of security knowledge and it continues to show.
I see the same about you. You keep repeating some myths about Qubes OS based on misunderstandings of its security approach. I don't have to be a professional in security to understand simple concepts. Qubes is not an OS made for professionals but for users.
> Qubes doesn't offer any more security than having a bunch of different machines to do different tasks on.
> SEL4, ASOS and CuBit are all more secure than Qubes.
Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
> I'm just refuting your preposterous zealotry for it
Relying on professionals in the field is not zealotry. In contrast, you show exactly the latter. I see no references.
> The developers of Qubes would absolutely disagree with your claims.
> You keep repeating this without providing any actual statistics. I provided statistics about Qubes vulnerabilities, https://www.qubes-os.org/security/xsa/. Show me the numbers please.
You can find this yourself. For any software running in the guest OS, you can look up it's security history.
> This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It
I understand it perfectly, but you seem to be missing my point. Yes, the qubes are disposable, but you need to have information in them while you are using them, yes? So, you make a new qubes to do your taxes, your tax information is in the qubes because you need it to do that. While the qube is running, if it is vulnerable, then that information is at risk. I get that it is no longer at risk once the qube is destroyed, but that is irrelevant to my point.
Consider an example, back in 2024 if you were running SSH in a Qubes for some reason, you would likely be vulnerable to the regreSSHion vulnerability. Sure, an attacker could only access what was on the disposable VM, but that could still be a lot.
> This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
Neither is qubes. It's designed for specific use cases, and doesn't do much to protect the information running within a qube aside from destroying it after disposing of it.
> Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
It's at risk while the VM is running, which is the point.
No, it doesn't. Those points are rather nonsense. Malware that can bridge airgapped systems? Sure, if you have a compromised USB stick and stupidly run something from it, I guess. The disposable VM would be at risk also.
> Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
You have no security knowledge at all, though, you just repeat your chosen solution because it's FLOSS. It makes this discussion very frustrating. Do you understand anything about capabilities, mandatory access controls or formal verification?
> Relying on professionals in the field is not zealotry.
You are exaggerating claims you can't backup in a field you don't understand due to the software meeting your only real criteria, being FLOSS. That is absolutely zealotry.
> This is plain false:
Not only do your links not support your exaggerated claims at all, meaning I am correct the author would absolutely not agree with you, but the FAQ entry dismissing formal verification and safe languages refers to a paper from 2010 - back when Rust didn't even exist. You might not know this, but the tech world moves pretty fast...
Do me a favor, spend some time with your favorite FLOSS AI and ask it why SEL4 would be considered superior to Qubes from a security perspective.
