Have upgraded my dom0 to fedora-32 from fedora-30 in Qubes 4.0.3 and have now removed all fedora-30 VM’s from the system. All seems fine. However this has brought to mind a question, which so far I cannot find an answer to upon looking through the Qubes Documentation pages. I assume (maybe wrongly), that dom0 is now using the same fedora-32 template as all of my other fedora VM’s. Does this mean, that if I add programs to the fedora-32 template, such as LibreOffice for example, for use in the other VM’s, that possible weaknesses in these programs might be used as an opening to attack dom0? If so, then am I correct in also assuming, that I would need to clone the existing fedora-32 template (given another name) and use it to supply all non-dom0 VM’s, in order to completely separate dom0 from the other fedora-32 VM’s?
You need to look in the FAQ:
dom0 uses an eol Fedora 25 - there’s little security issue about this for
reasons stated in the linked pages. It doesn’t use the template system.
I must have misunderstood the following command then:
sudo qubes-dom0-update qubes-template-fedora-32
which I thought it would upgrade dom0 to use fedora-32 from what I thought was fedora-30. Thanks for clearing that up unman 
To break it down, that command means: “Use the dom0 update mechanism in order to download and install the package for the Fedora 32 TemplateVM.” In other words, the new Fedora 32 template has to get into your system somehow. The way it does so is through a package. That package has to be installed somewhere. If it were installed in any other VM besides dom0, it would not be accessible to any other VM, meaning it would not be able to function as a TemplateVM. Therefore, it must be installed in dom0.
Ahhh. That makes sense Andrew. Thanks. One thing I now don’t understand though, is how a program (like say, the LibreOffice mentioned before) won’t be able to jeopardize dom0, if it is subsequently installed in the Template VM and that Template VM is located inside dom0. Is it impossible for a vulnerability to make the escalation to dom0?
Everything is stored in dom0 in a technical file storage sense, but very little runs directly in dom0. Rather, most of it runs in securely isolated compartments called “qubes.” The idea is that if a qube becomes compromised, the damage is limited to that qube, while other qubes remain secure. To be specific:
- Dom0 is for administering and displaying Qubes OS (soon to be bifurcated into the AdminVM and the GUIVM).
- TemplateVMs are for installing (and sometimes configuring) programs.
- AppVMs are for running programs and storing your data.
If you install a malicious program in your TemplateVM, but you only ever run that program in an AppVM, then the odds are that only the AppVM will be compromised. The TemplateVM probably wouldn’t be compromised because the program never ran there, and dom0 is even less likely to be compromised because the program was neither installed nor run there.
More info:
Thanks Andrew. I think I have it now. Hadn’t picked up on the stored in dom0 with read-only access vs run in aspect, when reading the Documentation. So I guess I have to pick my poison, so to speak. To use the LibreOffice example (sorry LibreOffice, I love your program and use it a lot), installing it in the Template shouldn’t be able to reasonably jeopardize dom0, although the program files are technically stored in dom0. But if I then set my preferences for the program (which entails running it in the Template VM) for later use in an appVM, I do somewhat jeopardize the Template VM, for the time period that I was setting my preferences. And since the Template is read only from the AppVM, I gather from the link you provided, that the program itself should be safe from future-found vulnerabilities, as far as the Template goes (although in the appVM’s files created and saved from said program could conceivably be infected and should be treated as such. Cheers