Having virtualized Qubes itself, I have many questions

User Support General
1

I have been grinding on Qubes installs this weekend using my backup workstation with the goal being moving at least some of my daily work to an environment that’s a bit sturdier than Linux VMs under VirtualBox. That is coming along well enough that I’m going to shift some remote access work over this coming week.

I also took the time to install Qubes under VirtualBox 6.1.38 and Proxmox 8.1.3. I understand this isn’t secure and I don’t plan on using these for production. My thinking is that this will be like my other virtualization experiments. Both of the systems have ZFS, so I can instantly snapshot/rollback a VM, instead of having to wade through another thirty minute install procedure every time I make a mistake.

The things in my queue that I think make sense to do in a virtualized environment involve working on the backup/restore process and experiments on networking configurations without having to order a PCIe ethernet card, haul some noisy switch in here, etc.

Both virtual installs finished, rebooted, installed templates, complained about lack of IOMMU and VT-x access, and I can open the Qube Manager. Seems like a decent starting point.

Is there an existing body of knowledge on what will and won’t work when virtualized?

2

for what is worth, on Qubes OS you can rollback a VM disk to its n previous state as differential disks are created and merged after n boots. (it’s a feature often overlooked)

3 Likes
3

Not really, this will mostly depend on your hardware compatibility with Qubes OS, otherwise the experience should be pretty similar (and faster)

1 Like
4

I wouldn’t call that body of knowledge, but the information is out there, scattered across time and space. For example, here’s a comment, where I mention applying certain parameters to certain places ( pv-l1tf=false and qubes.enable_insecure_pv_passthrough). What I think should be done is an unofficial (unsupported by the core team) documentation, which describes cases like this with clear warnings, why this is for prototyping and will make the system insecure.

If there’s a demand for that, we could set up a repository with notes like this, but in a more organized and easier to follow manner.

1 Like
5

The problem I have is that I’ve repeatedly lost, or at least thought I lost entire installs, due to some sort of stepping on GPT or other things required for boot. I mentioned this in another thread and got a tip on being more liberal in my use of ctrl-alt-f2.

6

While I have a computer science background, that was a very long time ago. Having spent twelve years with Pascal, the same amount of time with Perl, and now in my twelfth year with Python … which I approach like a preschooler presented with his first pair of shoes with laces :slight_smile:

I am barely a developer for my own stuff, the word I use to self-describe is “integrator”. I will take on complex apps like ArangoDB, Elasticsearch, Open Semantic Search, Proxmox, etc, and I’m happy building clustered high availability solutions.

My Substack this year was a month of a sort of “boot camp” for people new to online conflict, then I spent Q4 digesting The Online Operation Kill Chain. For better or worse, stuff like this is where my expertise is.

Large, hierarchical orgs don’t use things like Qubes, at least not that I’ve seen. There are “misattrib” services, Ntrepid is the best known, such that there is no technical burden on users, the systems are centralized and browser accessible. So what I am doing with Qubes is for me first, but there is a non-zero chance that I would end up herding small groups of others using it. I know what a seat of Ntrepid costs per month and I could fit out a dozen Qubes users with nice laptops or workstations for the same price.

So my virtualization stuff is just for testing, permits me to use a 4K monitor and a keyboard that is much more comfortable than the one on the actual machine I have running Qubes.

2 Likes
7

I’ve read a bit of the blog - some entries that I can understand considering it’s about 6:00 AM right now and I’m tired. Great work!

I recall a forum post about these hierarchical organizations that may not be using Qubes due to no trainings, certifications, among others despite the current offers by Invisible Things Lab. Still, I believe that security-aware people may still want the system, so a bootcamp will benefit them - especially considering the platform requirements and how many manual interventions are usually needed.

While I myself am happy to own a compatible laptop, where Qubes works like a charm, it’s not always the case and people may not be using the certified hardware as well - I primarily mean this blog entry.

I’d be happy to write a guide that could help with testing Qubes OS on VirtualBox, but it’s a matter of priorities, as a certain research after job-related work hours already takes my time and I’ve been postponing a certain thing to check, where a friend of mine provided an enormous amount of help, for about a month, barely getting any free time to relax. As said earlier, it’s about 6:00 AM right now and I should be getting some rest.

The thing is definitely possible, as I’ve been doing this myself and even posted a screenshot here, though a guide on how to achieve this would really come in handy.

1920×1080 110 KB

If nothing of a higher priority turns out, I’ll try to write such a guide by the end of the month and will schedule some free time for this after tiring myself from doing the important things. Feel free to ask me, how it’s going if no public “loose notes” document arises soon - polishing it to be straightforward is also energy-hungry for me.

1 Like
8

I’m just a dumb civilian, and have never been anything else, but those who know what to look for on LinkedIn would see the traces of retired CIA, DIA, SOCOM, etc. A little bit of my work ended up in a Joint Special Operations University class years ago, I sometimes have interactions with National Defense University authors. I quite pointedly do NOT get along with the trolls with badges that make up DHS and FBI. So … not anti-authority, but I have a real problem with what corrupts authority.

With that background I will say that I wrote the white paper that led to twenty House offices calling for hearings on HBGary. During those years various parts of the DoD were seeking “persona management” systems and misattrib/no attrib system vendor Ntrepid’s name was mentioned. As what I do evolves, I meet new people, including the company’s founder a few years ago. The cost for a single seat of Windows with them running all the hardware/software/network was around $10k/month. I did a little work with a potential competitor, didn’t care for the people I encountered, and that’s long since gone over my event horizon.

The people who can employ something like Qubes are “operators”, that’s shorthand for resourceful, multitalented folks - hackers, journalists, human rights activists, people whose drivers are internal. The only way they stop is if someone makes them stop.

The large hierarchies get people who can do the sort of human factors/influence ops stuff I write about, but they won’t have the breadth to do their own technology, nor would they get trained to do so. It’s just too complex, too demanding, hence the $10k/seat mistattrib systems for those who can NOT get caught slipping.

So I get along with the spooks, I know a bit about the norms and economics in that world, but my daily grind is civil society orgs and their support, those multitalented folks who just can’t keep out of trouble :slight_smile: It’s normal to see groups working with their one cell phone and one laptop. A portion of them can be encouraged to keep older gear and repurpose it for safety’s sake. A smaller percentage will do things like what I do - compartmentalization and the human and hardware level.

As I look at Russia/Ukraine, China/Taiwan, Israel/Gaza, Colombia/Guyana, this all reminds me of the 1930s. It hasn’t really started yet, but it’s going to, there’s no way to pull back from it now. I’m on the side of the humans in this, I’m much closer to the end of my career than the start, so much so that I’m spending more time trying to keep folks from learning the hard way than I am actually doing anything on my own any more.

And that’s why I want to virtualize, just aiming for an economy of motion on my part, I don’t imagine anyone is going to try that in anything other than a lab environment. So I don’t need a fancy book, just some general boundaries so I don’t waste hours on end going down rabbit holes.

4 Likes
9

Hello. It’s been some time, but I managed to write that guide - yes, by the end of the month, so I can blatantly say “© 2023”, rather than starting from 2024. :stuck_out_tongue:

The guide is located here. Maybe I’ll post it to the community guides, but I’d like to polish it further, since I’ve been using older software versions, than what we currently have: I used the release candidate 3 version (Qubes-R4.2.0-rc3-x86_64.iso) - the one I’ve been using as part of another laboratory, of which I posted a screenshot earlier - despite the stable one being out there for some time. This release can still be downloaded from https://ftp.qubes-os.org/iso/.

I hope this guide will turn out useful. Please, share your thoughts after finishing the processes I described there - I’d appreciate comments and criticism.

2 Likes
10

OK, wow, it’s 1) ready and 2) not terribly complex.

I had a brief misadventure with VirtualBox7 earlier this year, mostly due to its (non)handling of host only networks. That lasted all of ten minutes before I scampered back to the safety of VB6.

I read the instructions quickly, but seems like VB6 + 4.2.0 should work just as well.

11

I was able to nested-virtualize QubesOS under KVM using Fedora 37 and VMM (with some slight tweaks as the AMD CPU ends up having slightly more issues than Intel CPU).

Presumably Proxmox, where virtualization is built on KVM, would also work.

See (a meandering) thread here:

B

12

I’ve just checked and this combination does work indeed.

I’ll rewrite this walkthrough some time in the future, so it uses the stable release 4.2.0 and mentions the workaround in the “no networking devices in sys-net, no Internet connectivity” section, since this workaround appears to be mandatory in the stable release, and it wasn’t like that in release candidate 3.

Furthermore, after getting well-deserved 16 hours of sleep I can also see some missing words and misspellings in this guide. Yes, it shall definitely be rewritten.

2 Likes
13

I just looked at VB and I did get a working install using 4.2.0rc5 and VirtualBox 6.1.38, without doing anything special to get it going. Can’t speak to its behavior, I have a lot of stuff in my queue and that’s going to be a deep dive, so much so that I’d forgotten I’d even done that until just now.

14

I just installed Qubes R4.2.0 (the final version) in Virtualbox 7.0.8 r 156879, using the recommended values and adding the workaround for sys-net.

The installation went without any problems, but sys-net cannot be started, showing the error qrexec-daemon.c:144:sigchld_parent_handler: Connection to the VM failed, which is also the only message in journalctl.

Changing the type of network adapter or the system chipset in VB has no effect.

1 Like
15

Recreated the walkthrough, so it accounts for the stable Qubes OS 4.2.0, as well as the latest VirtualBox version. Also made it shorter - should be less overwhelming.

The current revision.

1 Like