Hi everybody ! 
What do you think about QubesOs installed on a virtual machine (KVM…), installed on a system-live with datas persistence, installed on a USB key with a physical write protection (that I would take off only for updates/upgrades) ? Do you think this could be a more secured Qubes installation ? Is installing Qubes on a system-live risky for security ? Which system-live should I use for the best security ?
Thanks a lot for your answers !
Hi @YvesR! Welcome to the forum!
I think you’d be missing out on a lot of the benefits that are baked into dom0 by running it inside a VM. Not only would half of the stuff likely not work as intended, performance would likely be so painfully slow that it could be unusable.
Sure it would create an extra layer if your Qubes dom0 got compromised, but there’d be nothing to protect you going the other way. So if your bare metal OS was pwned, then your Qubes OS VM would be pwned.
It’s for this very reason (and many others) that Qubes OS is designed the way it is.
That’s exactly what TAILS is……
Again, that’s exactly what TAILS is….
Define “more secured” more specifically.
Define “risky” and “security” more specifically.
Again. Define “security” more specifically, and you’ll have your answer.
Hi Alzer89,
Thanks for your answer.
When I talk about ‘risks’ and ‘security’, I am mainly talking about remote hacking, via the web. Having already been hacked by very competent people, I try to put in place the necessary security.
Although Qubes is one of the most secure OS, it is not invulnerable and can still be compromised. So I assume my installation will be compromised by my enemies.
If I install Qubes on VM on a live system on a USB stick with physical write protection, could it make more difficult the persistence of a potential compromission ?
That would lead to system crash on a standard install, because Qubes is not optimized for running in that way. You may need this:
That still isn’t specific enough
I’m not trying to belittle you. I don’t do that, it’s a waste of energy. Plus, I have no doubt that you’re an intelligent person
I’m trying to draw attention to the fact that it’s not enough to say “better security” and “I’ve been hacked” you need to understand how you get pwned (attack vectors), if you want to protect yourself against it.
So that means that your attack vectors are:
You can then gauge these attack vectors against your proposed mitigation solution of using a LiveUSB. Then, you will be able to determine whether or not it will effective against these attack vectors
Absolutely. I compromise it deliberately on a regular basis, so I can identify potential attack vectors, and mitigate them. It’s actually quite fun to do so (as long as you do it in a safe environment) 
Ah yes, I remember my first pwnage 
In all honesty, probably not. At least, not in the way it would be effective when using an OS inside a VM that doesn’t use the Xen hypervisor…
The concept of sacrificial protection by doing everything inside a virtual machine is very effective against containing anything nasty that gets into that VM.
Qubes OS already deliberately structures every single aspect of system operations like this for this very reason 
But unlike using regular VMs (for example, Kali Linux VM running on Ubuntu bare metal), the “bare metal” OS (Ubuntu in this case) is usually used like a regular computer (ie the user likely daily drives Ubuntu as well).
So what if something nasty got into the bare metal OS? Well, then the bare metal OS and the VM are both pwned! 
What’s the point of hardening Qubes OS by caging it inside a virtual machine, when the host OS always has direct access? 
This is where the concept of dom0 (Xen Domain 0) comes in. The bare metal OS is designed to have the absolute minimum required to facilitate all the Qubes (AppVMs), and nothing else.
If you’ve ever played around with big powerful servers (no problem if you haven’t), this is basically the model that “the cloud” is based on. Most server motherboard contain an SD card slot. Why? For hosting their dom0 on
As for preventing persistence from a potential compromise if something nasty gets into an AppVM, that’s already accounted for:
In Getting Started, we covered the distinction in Qubes OS between where you install your software and where you run your software. Your software is installed in templates. Each template shares its root filesystem (i.e., all of its programs and system files) with all the qubes based on it. App qubes are where you run your software and store your data.
The template system has significant benefits:
- Security: Each qube has read-only access to the template on which it’s based, so if a qube is compromised, it cannot infect its template or any of the other qubes based on that template.
- Storage: Each qube based on a template uses only the disk space required to store its own data (i.e., your files in its home directory), which dramatically saves on disk space.
- Speed: It is extremely fast to create new app qubes, since the root filesystem already exists in the template.
- Updates: Updates are naturally centralized, since updating a template means that all qubes based on it will automatically use those updates after they’re restarted.
An important side effect of this system is that any software installed in an app qube (rather than in the template on which it is based) will disappear after the app qube reboots (see Inheritance and Persistence). For this reason, we recommend installing most of your software in templates, not app qubes.
The default template in Qubes is based on Fedora, but there are additional templates based on other Linux distributions. There are also templates available with or without certain software preinstalled. You may find it useful to have multiple templates installed in order to provide:
- Different security levels (e.g., more or less trusted software installed)
- Different environments (e.g., Fedora, Debian, Whonix)
- Different tools (e.g., office, media, development, hardware drivers)
So if anything gets into your Qube, a reboot should make it disappear immediately
At least, that’s the idea. The only thing that could compromise this is a bug in the Qubes OS codebase, and so far, we’ve been pretty lucky.
I mean, you’re more than welcome to try. Your machine, your rules
…but I think a Live version of Qubes OS would be a lot of extra effort for very little gain.
Unless your threat model assumes physical access to your “bare-metal”. But, even then, no Live OS can help you…
When they ask me why I have car alarm, I say to prevent amateurs and junkies to rob/steal my car. No illusion of anything more if even that.
And for them, luks password looks like “car alarm” and should be enough.