Hi, I have been using Qubes for a bit of time now, and looking to update to 4.1 , the only reason I haven’t in the past, is because I have learning and reading slowly through the documentation to improve my knowledge. I have a few questions before I upgrade to improve my own understanding of security after a test run with 4.1 -
Normally when I update dom0, any template or download a template it runs through a ProxyVM, on 4.1, on my test run that didn’t work, can someone clarify this please for me?
Disposable Firewall and sys-net - is there a simple way, to store firewall setup into the disposable sys-firewall after system boot? I dont want to be putting settings in after every boot but maybe a quick copy and paste of settings will help. (i want to keep these disposable for my own learning and boot up routine)
Zero clear net exchange - Is there a way in 4.1 to ensure all traffic is either only through Tor or a VPN, updates, templates, etc? (preferably VPN for the most part). and is there a way to update dom0 through a vpn proxy rather than just tor?
Safety of template updates through tor - I have used tor in the past but for the most part its quite new, what is the level of safety when updating templates, dom0, etc? and what should I look for while updating to ensure the integrity of updates/downloads.
Is it worth having two different disposable VM templates (is this possible? because the global settings doesn’t permit separation).
1 for services (sys-net, sys-firewall) other for internet browsing qubes? I was reading about templates being compromised and the resulting qubes being infected.
Minimal template security - I am going to start using these with 4.1 as my main setup, is there any security issues to be aware of? I can’t seem to find any details around security cons, only pros related to threat models and attack surfaces.
Thank you, and I am really glad I found this community and Qubes, its been a journey learning and I feel more confident in taking further steps in my understanding because of this community.
The idea was, to separate the templateVMs and dom0 from being connected to the net directly. So all updates run through a proxy, which download the updates and make them available for dom0 and templates.
Not sure, why it didn’t work on your test system - maybe you didn’t set there, which your updateVM should be (Qubes Manager > Settings > UpdateVM)
You can run sys-net or sys-firewall from a dvm-template (i.E. dvm-fedora-36), so they would always load from scratch on every boot without any own settings. More infos: Disposable customization | Qubes OS
for VPN you need to setup a VPN qube and later set it as the main netVM for your appVMs (qubes settings) and/or updateVM for your updates (in Qubes Manager settings). The latter also can be routed through tor, if you setup sys-whonix as your updateVM.
I for myself choosen “updates through tor” from the first beginning with qubes. It was a question on the first install and I chose sys-whonix as updateVM (although I didn’t know, what I’m doing at that time). Thats why all my updates for dom0 and the templates went through tor since the beginning.
I just have two dvm’s - one which was done through the installation and is based on the fedora-36 (called fedora-36-dvm) and a second which I also got from the installation procedure called whonix-ws-16-dvm (based on the whonix-ws-16 template).
I also setup a third manually, which is based on my kali template (called kali-dvm) and I use just for the work with the kali appVMs only.
don’t remember of any security issues - it’s more common, that you have to install some more features in those minimal templates, so the appVMs (which are based of) will run properly.
Quite a hard work for a Qubes beginner to work with minimal templates. You always have to know about the parts you need for the minimal, so your appVM would work proper…
For example: if you want to have your sys-net based on a minimal template you first need to install some more features/tools in your minimal template, so your sys-net qube would be able to connect to net / using WLAN adapters / etc.
Im not sure why 1. was happening, seems it was setup through sys-firewall to update, which is fine, but I want to set everything through VPN/Tor updates so I will change that.
2. I will have them set to disposable and then I might try and setup a script to use for my settings, saves me from manually tying it out/entering it into the sys-firewall, not sure how to without installing some additional software, but I will try and see if it will work.
3. thanks, i have those setup on my current system so I will maintain them for the upgrade.
4. I might look more into Tor and safety for template updates, I understand the privacy aspect, but the security aspect is blurry for me. Maybe there is some resources outside specifically for Qubes out there. I know the Whonix has some sources but my knowledge base is beginner with Tor
5. Thanks, I might setup 2 fedora dvms one for services, one for qubes, and 1 for whonix
6. I’m not sure I understand why there would be more to install than the full template for services, wouldn’t that defeat he purpose of a minimal template, from what I have calculated a min template can be half the size of the full template. All I really need is net services (for net, firewall) firefox and terminal to run.
In 4.1 templates are handled differently from other packages.
When you say “that didn’t work”, I assume that you mean that you didn’t
see the same window open and process downloads as you do with normal
package updates.
4.1 has a dedicated tool - qvm-template and a GUI version - qvm-template-gui
This tool uses the UpdateVM (of course, since dom0 has no network
connection), but works outwith the dnf framework. qubes-dom0-update
will do the Right Thing™ when working with templates.
Templates installed using these tools will not feature in dnf commands
in dom0.
I’m not clear what you mean by “firewall setup” in this context.
If you have custom firewall rules that you set in
/rw/config/qubes-firewall-user-script, you can set these in the
disposable template, and they will be inherited by all disposables
using that disposable template. (Think carefully as to whether this is
actually what you want.)
Do not run any outbound services from qubes upstream of your VPN or Tor
gateways. Make sure that Qubes services (Global settings) are running on or
downstream of those gateways.
Do not run any services on upstream qubes (e.g sys-net,sys-firewall).
Turn off update checking, and any other services.
Consider blocking outbound traffic in the OUTPUT chain.
Qubes handles integrity checking for you.
You can have as many different disposable templates as you want. Only
one will be the default template.
It makes sense to have a distinct disposable template for sys-net since
this will need firmware and drivers, that aren’t needed in other service
qubes.
You might also want to use different distros to avoid a monoculture.
There are no security cons. (Bold, I know.)
There are cons - increased maintenance and possible confusion.
If you use many templates it will pay you to run a caching proxy - this
means that common packages will be downloaded only once. You will see a
dramatic increase in update speed and a reduction in download traffic.
I hope you continue enjoying the journey.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
That makes sense why the proxy-vm wasn’t displaying when I installed new templates, it just started.
You raise a good point, especially related to VM-fingerprinting, maybe I limit all connections and only open my VPN and Firefox ports when I am using them, instead of having a big config setup with everything.
good point about update checking, i will have to look have a look at how to stop update checking, that’s a new concept for me on my journey. Do not run any services on upstream qubes (e.g sys-net,sys-firewall) - not sure if there is another way to stop this other than the firewall settings.
Thank you for clarifying
Good point, especially with monoculture and VM fingerprinting, i might look at using some debian templates more. This is something I will have to think about, but I think it will raise more questions for me when I start using it.
I will definitely need a caching-proxy for how many minimal templates I will need.
Thank you
Update checking is on Qubes General Settings.
Or you can disable the service on a per qube basis - the service is qubes-update-check. You can disable it with qvm-features.
Other qubes services can be reviewed and controlled from qvm-features.
You can also use nftables to restrict output traffic to lo, and drop all
outbound via eth0.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
but maybe a quick copy and paste of settings will help. (i want to keep these disposable for my own learning and boot up routine)