Sure, do it if you decide it’s better. I was just thinking that sometimes people use too many qubes, like shopping ones or translation ones, while (I think) it does not provide any additional security or convenience, so in some way my usage of disposable qubes for everything is non-standard. But most of the details still do not belong here.
Unfortunately, in the current state of things, this is technically not true. Due to the existence of many covert channels, even a VM with no NetVM is not completely leak-proof.
However, I think such attacks would generally be considered “advanced,” so the existing protection may be good enough for many people.
Thank you for the information! Can I read more about it? Do you mean the exchange of files with a comprimised qube could lead to a covert channel? Does it help if I never let any files out?
Another problem is probably connecting USB devices to this VM (even through sys-usb). Does it help when I only connect my devices to (disposable) sys-usb and transfer files exclusively via “copy to VM”?
And indeed, even if I am not protected from those things, it is still a much higher protection than any typical OS, which feels great.
My general policy (for what it’s worth) is if it’s that valuable or mission-critical, it shouldn’t be on a networked computer. Period.
Complete air-gapping allows for a much smaller attack surface and a larger degree of certainty. With virtualization-gapping, you open yourself many more unknown-unknowns–on top of the known-knowns like Spectre and Rowhammer.
I’m not really familiar with the terminology. I call it a ‘layout’ because in my mind the VMs are connected like a flow chart, with nodes and links. @fsflover “How are you using Qubes OS” sounds too vague to me–the thread might get diverted to discussing what tasks are performed on Qubes, which isn’t really what I’m interested in. However, that’s just my perspective, and I’m probably not representative of the userbase. I’m open to changing the title if there’s a consensus that the term ‘layout’ is misleading to the userbase.
This thread not gaining much attention might also because Qubes users tend to be cautious, which means there’s a natural reluctance to post details about their systems’ operations. On top of that, this is a copy of the Reddit thread linked above.
Fair enough, but I also suggested word “setup”. For example: “How did you setup your Qubes?”. Alternatively, one could use something like “Which qubes did you create?”.
It could of course be the reason, but I personally missed this thread due to its name, so we have at least one data point…
An example of a cooperative covert channel in Qubes would be abusing the CPU cache to exfiltrate data from an offline VM via a network-connected VM (e.g., sys-net). This is different from the scenarios you describe, though the scenarios you describe are additional ways that data exfiltration could occur.
You can read more here:
Also mentioned in:
Indeed, it makes such attacks more difficult and requires a higher level of skill from the attacker. Nothing is ever 100% secure, so making attacks more costly is pretty much the best you can do.
I was about to link to the same paper.
Physical air gaps are not always superior! For certain use cases (particularly those mentioned in the paper), Qubes compartmentalization is arguably be more secure.
Of course, the converse is also true: There are certain use cases for which physical air gaps are more secure. The point is that it’s situational an depends on many factors. One is not always better than the other.
It’s true. Even something like posting a screenshot of your dom0 desktop (without any confidential data in view) could be used to launch an attack against you, since knowing exactly what your dom0 desktop looks like might allow an attacker to take over a VM with fullscreen permissions to create a convincing simulation of your dom0 within that VM, inducing you to perform sensitive actions like entering passphrases.
Of course, such an attack should be easy to thwart by using a protected shortcut like alt+tab, so going to such great effort is unlikely to be worth it (unless the attacker somehow knows that you rarely use protected shortcuts).
Ok, but (returning to my original point of having just one offline qube for everything) how having multiple offline qubes could help here? Perhaps only switched off/paused qubes are safe in this case, but whenever you switch them on, you’re screwed.
It could help if one offline VM gets compromised while the other doesn’t. Data exfiltration would be limited to the compromised VM (unless the attacker chains it with another attack).
ed on my very limited knowledge). At least, it’d tide us over until someone bothers to make an ethernet unikernel.
Further discussion:
I see the concerns, but since nothing as specific as a screenshot of dom0 is needed, Kermit’s Law should be a good enough assurance. If an attacker has enough information about your system (across many VMs) to identify you from some details given here, then you have much bigger problems that not posting wouldn’t have prevented.
Pictured: Kermit’s Law
And @fslover I see the argument, especially since BadUSB is a massive issue (though USB isn’t the only means of data transfer)–but considering the unknown unknowns, physical airgapping just makes me feel safer. It’s this big baby’s security blanket, if you will. Or maybe that should refer to the faraday blanket wrapped around the computer.
Physical air gaps require you to transfer files via USB (or less convenient methods) rather than secure qvm-copy/move. BadUSB is a big problem. Therefore, qvm-copy/move has the security advantage over physical USB sneakernet. The attack surface of qvm-copy/move is incredibly minuscule compared to plugging the same USB drive into multiple conventional physical machines. This is a point in favor of Qubes over physical air gaps.
I might have been unclear–what I wrote agrees with what you’re saying.
Because BadUSB is a massive issue, I see the argument against physical airgaps, because such airgaps tend to rely on USB for data transfer, and BadUSB is hard to detect (impossible for those without specialized equipment, training, and tons of time AFAIK). This is why I brought up my point that “USB isn’t the only means of data transfer”–MicroSD cards are very hard to compromise, for example, and SATA (like eSATA) are less targeted AFAIK.
i’ve gotten tired of torbrowser not loading youtube videos and started using disposable firefox-esr with add-ons ; i might get a few videos, but then yt starts complaining and i have to reload the circuit, just time consuming