It would be nested virtualization and I wonder if it works and there is a tutorial?
Virtual box seems doable, although buggy
It would be nested virtualization and I wonder if it works and there is a tutorial?
Virtual box seems doable, although buggy
Yeah that’s the answer! I looked into dual boot, it’s not that quick either (the other OS can change Qubes grub entries, as it happened to me).
@Eli, what do you mean by this?
Whilst it is definitely possible to achieve what it is you wish to do, the reason why none of the options come with the standard install ISO is because the security features that require direct hardware access may not work as expected.
Remember that it’ll be in an environment that:
If you do give this a go, we recommend you do NOT do anything mission-critical on top of that Qubes OS installation, because we cannot guarantee functionality and integrity to the same standard as running on bare metal.
This is actually why it’s a lot less hassle for all of us if we just tell people that’s it’s better not to do it
But, if you understand all of this and still wish to proceed, then by all means, who are we to stop you?
If your hardware has multiple physical drives, then dual booting with each OS on its own physical drive is more manageable, as the drives tend to interfere with each other less.
But that opens up a whole other can of worms in terms of security and machine integrity…
Yeah, it’s for testing. The point is, the users cannot switch completely in one day. They run it alongside something else, and once they are confident that it serves their needs, they switch completely.
I don’t have extra drives now (I had before and Ubuntu used to delete Qubes grub entries). Dual boot on one NVMe is an option , though I’m not sure how well it works.
I understand the can of worms, this is only for transition, nothing security critical for me.
I use it mostly for compartmentalizing my workload. Which is why I missed Qubes and coming back
I had before and Ubuntu used to delete Qubes grub entries). Dual boot on one NVMe is an option , though I’m not sure how well it works.
An option is to manually keep a backup of your Qubes OS grub.cfg
in a separate location on your boot partition.
Thanks. Is this the right guide to add Qubes to an existing Ubuntu desktop with UEFI boot, for some fun Christmas project:
Introduction You should think carefully before dual booting Qubes on your box. Read the guidelines carefully. One problem is that when you dual or multiboot, even if you are using encryption on your Qubes installation, /boot is still unprotected and could be maliciously modified by the other OS, possibly leading to Qubes itself being maliciously modified. The other problem is firmware security - for example the other system could infect the BIOS firmware, which might enable compromise or spyi…
That is the correct topic, but you could also create a new one in the Community Guides or High Quality Guides category.
Most likely, yes. Can;'t speak from experience, though.
It would be nested virtualization and I wonder if it works and there is a tutorial?
Virtual box seems doable, although buggy
That VirtualBox-based tutorial was written for the release 4.2.0, and I never updated it to work with newer releases, so no guarantees there. However, with the recent licensing changes, you could just grab a free copy of VMware Workstation, since it’s now free for both personal and commercial usage. Qubes OS works virtualized in it pretty much out of the box.
you could just grab a free copy of VMware Workstation, since it’s now free for both personal and commercial usage. Qubes OS works virtualized in it pretty much out of the box.
I’d be curious to see how deep the host OS can see into Qubes OS under that configuration, and whether it could be vulnerable to bit-flipping attacks or arbitrary memory writes (both ways, Qubes to host, and host to Qubes).
I mean, my guess is that it would provide absolutely no security whatsoever, and would be suicide to use in production over running on bare metal.
But if it doesn’t throw too many errors, I’d happily set up a “Try out Qubes OS” website that spins up a fresh install on an instance for 3-4 hours, so people who want to “try” Qubes OS workflow can do so.
Even better if it could be done on something open source instead of VMware….
I’d be curious to see how deep the host OS can see into Qubes OS under that configuration, and whether it could be vulnerable to bit-flipping attacks or arbitrary memory writes (both ways, Qubes to host, and host to Qubes).
It’s an equivalent of playing a video game with a trainer. As a simple demo, see me using Cheat Engine to replace all the occurrences of the string “Dom0” with “Cheat Engine Test”, and what happens to the window borders with the unspoofable domain name being used as a prefix for the actual title:
I mean, my guess is that it would provide absolutely no security whatsoever, and would be suicide to use in production over running on bare metal.
When it comes to things like working with sensitive data in offline vaults, there’s no benefit to itself having an offline vault, which an online system can see and monitor the whole time.
But if it doesn’t throw too many errors, I’d happily set up a “Try out Qubes OS” website that spins up a fresh install on an instance for 3-4 hours, so people who want to “try” Qubes OS workflow can do so.
Even better if it could be done on something open source instead of VMware….
Sounds nice! You could try setting things up in KVM, and once some things require tweaks and workarounds, maybe someone would know, how to resolve them, and help out.