QubesOS isolates almost everything and does very good job in that. but “Qubes, however, does not attempt to provide any security isolation for applications running within the same domain. For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. [which, out of the box, almost has no sandboxing at all]. The difference that Qubes makes is that now the attacker doesn’t have access to all the software running in the other domains.”
What do you suggest for someone who wants to isolate between apps within the same domain?
Would something like AppArmor or SELinux be sufficient?
Also, it’d would be beneficial as open discussion for people who want to limit the trust in the bundled apps from linux repos.
@germanman - bear in mind that there is no reason why you need to have
all your eggs in one basket - that’s why Qubes has the concept of
“security domain” which is different from qube.
So for work, you may have a work-mail qube, a work-file qube, a work-gpg
qube, a work-zoom qube, and use offline disposableVMs to load and view
files.
This way you leverage Qubes isolation to provide isolation between apps
in the same security domain.
If you must share files between these qubes, (and qvm-copy/move isn’t
enough), then there are solutions like GitHub - unman/qubes-sync: Simple syncin between qubes over qrexec which will allow you to make files
from one qube available in another (rw or ro), provided you are aware
of the risks.
But despite that, the trust is still there in linux apps. If I use, say firefox, in two domains, any bug in firefox would affect both domains anyway.
The isolation between domains didn’t solve the problem of non-isolation between firefox and thunderbird, for example, in the same domain. So, if I put my stuff in too many qubes, I didn’t do anything to limit the trust in these apps since AppVMs will still inherit all apps from the templates anyway. It’s still not isolated regardless of my practice.
The idea is to isolate the apps in the same domain. Otherwise, I’d have like 20 qubes or something. Same apps run in multiple domains yet.
I think there may be a confusion here. When having say a “thunderbird” running in work-mail and a firefox in work-web, you have a stronger isolation between them. As far as Qubes security is concerned, they cannot communicate with each other even if one privilege escalates, which is not the case when running in the same domain.
By having them on the same domain, all you are saying is: “I delegate this trust to Linux instead of Qubes”. In which case the question should become:
how do I isolate applications in Linux? - probably best addressed in linux forums
If your concern is that you’re trusting too much on an application by having it in multiple domains, then the solution is simple: use equivalent applications in different VMs
I meant thunderbird and firefox in the same domain. But, I think it might be better as a linux-related question not qubes as you suggested.
“If I use, say firefox, in two domains, any bug in firefox would affect both domains anyway”. I meant that the bug in firefox will be in all vms that I use firefox in, which might later affect other apps in the same vms. That seems linux problem not qubes though and it’s not part of qubes’ security model anyway.
Perfect. Just don’t forget to address a bit the Qubes hardening, particularly disabling the “passwordless root”. Otherwise all linux mitigations will be in vain.
So, if I put my stuff in too many qubes, I didn’t do anything to limit the trust in these apps since AppVMs will still inherit all apps from the templates anyway. It’s still not isolated regardless of my practice.
Hi. The recommendation here is to have multiple minimal templates and you would install, for example, Thunderbird on one template, and firefox on another template, and each template is for its own AppVM.
Exactly so, exact that even here, each template can be used for many
AppVMS, across different security domains.
As to your fear of having “20 qubes or something”, don’t worry about
this. I have a ludicrous number of templates, and qubes, on some of my
systems - if you keep them controlled, use sensible naming and colour
policies, it isn’t an issue.
Also, if you use KDE then you can leverage KDE activities to force
related qubes together on the same desktop, so there’s minimal risk of
bleeding between different security domains. KDE also has a very
intuitive menu editor which makes it much easier to create a custom menu
based on what you use qubes for, rather than the qubes themselves.
The important thing is to stop worrying about qubes at all - think about
what you want to do and how the qubes will become part of that - the
important thing is how you structure your digital life. Focus on
that.
I think you should treat VM as any desktop unix system, same things applicable (SELinux, reasonable protection from LPE, etc)
Unfortunately Joanna is very skeptical about that and is very enthusiastic about VM isolation, thus disabled SELinux, passwordless sudo and so on. I am, in the contrary, quite skeptical about the hypervisor security, especially when the guest root is easily obtainable
Qubes OS v4+ does not use typical software virtualization methods. VT-d hardware virtualization it uses was broken only once, and it was done by Joanna: Blue Pill (software) - Wikipedia.
Also, the number of security-related issues is not high for Qubes over the last years: Xen Security Advisory (XSA) Tracker | Qubes OS. Note that not all XSAs lead to issues in Qubes. Any other systems with better security statistics?
I’m leaning towards that as well. I don’t know why the project doesn’t target the security within the VMs. If isolation between apps is wanted, then use them in different AppVMs or even use them in AppVMs that are based on different TemplateVMs.
The user would end up installing at least two apps in each TemplateVM and will use at least two apps in each AppVM. I can’t see how these two apps are isolated. But that’s a Linux issue and not in the scope of the security goals of QubesOS.
DispVMs would be the savior in that regard
It’s an amazing feature!
Also, the Whonix project works on full system policies for AppArmor. Still under development.
I see what you mean here. However Qubes OS is based on concept of security domains, inside which you don’t need isolation. See Rutkowska’s article about it.
If you really need to isolate the two programs, you should use different VMs for them…
Because doing the virtualization right is tricky. The attack surface is not as small as one might expect even with VT-d. I would feel much more safe if I had a few more layers I can get cheap enough.
That’s what I said already before, that’s “not in the scope of the security goals of QubesOS”. That’s why also I suggested to discuss the topic since it’s not supported by QubesOS.
I don’t just want to isolate the two programs. That was an example to illustrate my point. I want to isolate all programs in the TemplateVM, which might be done by running all files/apps in DispVM alongside a full system policies for SELinux or AppArmor, which both are not supported in Fedora and debian TemplateVMs.
The idea is to even extend the concept of isolation/compartmentalization inside the TemplateVMs.
