I have a fully hardware compatible computer (all green checks HSI) with the latest Qubes. As there has always been–having been working with Qubes for many years–there are still weaknesses in the Updater mechanism. I know; it is difficult. The metadata: they want to know what and profile your packages .
Templates never list on the Qubes Template Manager if networking is tor. The only way to list and get a Template is via VPN or encrypted DNS. And it appears just getting an arch or noble (Ubuntu) template over VPN is enough to expose Dom0 to risk, never mind that i3 noble has not implemented passwordless as is the security paradigm of the OS.
Furthermore, there is no way to “rename” or “re-designate” a Standalone qube to a Template qube and no way to network a cloned Template without exposing Dom0 to risk. So if I want Kicksecure-17 to be my default dvm, the whole system would have to be exposed to risk by cloning Debian-12, tor networking the clone, and then distribution morphing to Kicksecure.
Also, if you have Mullvad-VPN in a Standalone qube, it can no long update over tor via Qubes Update. Why is that? yum / dnf has an onion repo but that just must be for Dom. Does the Updater onionize all repos? Debian and Fedora qubes are updated by the Qubes Updater mechanism via onion if updates over tor is selected?
For some reason, any Standalone qube will not update with Qubes Updater strategy if any VPN applications are installed (Mullvad or Proton). So I removed them. Encrypted DNS should be sufficient unless they start blocking the news on the IP level in the US and the news site also blocks tor. VPN doesn’t provide any further layer of network security than encrypted DNS, wouldn’t you agree?
But I wonder why updates can proceed through qube terminal but not through Qubes Updater which is supposed to take special precautions. VPNs can also not work disp like sys qubes. Is this because certs change?
I deleted the qubes but did have the keyrings installed according to their respective installation instructions.
Rise Up VPN still does not work on Debian-12. The Ubuntu Nobel Template is a risk to get close to Dom0 but probably Rise Up work work then
I had to get the configs for ovpn and wireguard (wg-quick would work) and use cli since the ProtonVPN gui would abort with an error message.
Mullvad strangely wouldn’t run multi-hop wg but would ovpn (but you can tor to ovpn unlike wg). Months ago Mullvad worked without issue and was fully functional on Qubes
Then Discord did an ssl downgrade attack over VPN. That and other anomalies ended my relationship with VPNs. My new paradigm is either tor or encrypted (TLS, DOH, ODOH) DNS (for when you need online banking or non-crypto shopping).
All VPN qubes cannot be run as dvm after completely loaded. Why not? Whonix Gateway doesn’t because it is good to keep stable guards until changing every three months. What is it about sys networking qubes that cant be dvm?
Probably best to have more than one Qubes; one for not compromising on security which is just a hardened host for Whonix and another for trying new things out with different OS templates and applications which an adversary will mess up every way possible (but we can always delete him).
Nope. You’re not “dominant” just because you supplied an answer to a question I did not ask.
sys qubes are not app qubes. The documentation you provided states that dvm can be made out of app qubes. They can also from Standalone if they do not have any VPN code. Add VPN code and then, all of a sudden, everything stops functioning as it should even if installed over tor with conf files from onion sites.
Why is sys Whonix not dvm by default then? I answered myself already.
You don’t answer. I just answered you so you are not dominant now. The people in the audience think “disposable” means trash and inferior (non-rich) not a security feature. You understand nothing.
I don’t know what do you mean by “VPN code”.
I have a named disposable sys-vpn qube that is using wireguard and it works for me.
I just created an app qube, configured the VPN there, set this app qube to be a disposable template and then created a named disposable based on this disposable template.
Unlike sys-whonix, this sys-vpn named disposable qube don’t need any data persistence to work so it works fine for this case.
Perhaps updating Dom0, although supposedly secure, was a mistake or there is something below ring 0 (BIOS is latest stable Libreboot so should be good). But they seem only interested in VPNs and Social media apps.
But then they turn off tor updates so I cant get templates over tor (to attack when getting a template) and to know which packages so they can target specific app and package maintainers.
They also like nmap with -O for OS profiling and make noise about version number, which is weird. It is like they want to know which Devs to target specifically. Disturbing hate group.
It is as though there is a filter at an ISP level (Comcast) that says:
If nmap -v -O is Qubes, then block all tor and obfs4 and all possible bridges. They also block Debian net-vm and want F39 (something to do with their superstitions and turn on tableau). Weird, creepy cyber attacker.
Looks like this probe https://nmap.org/book/man-os-detection.html
(Kind of like an ice pick to the hippocampus. Happy Psychoween!)
But tor (plus hypervisor and VMs) are the whole point of Qubes.
All access points are unrelated. Cellular track and block LAN at that location? Very strange.
It means the attacker did the same thing to Proton they did to Mullvad (and they might have done something to Rise Up too). Mullvad used to be fully functional months ago. Proton only works with wg. Both are removed from my system due to anomalies.
If you ping 127.0.0.1 on Kicksecure, you get nothing. ICMP requests are blocked. But if you check your sys-net template that dvms, you will get a response. What is the trade off between blocking probes of your stack (to prevent OS filtering and tor bridge blocks) and still having functional networking?
What are the best ways to block hostile probing?
What is the safe way to make Kicksecure the default dvm? As a Standalone it cannot be made a template for sys-net dvm and a cloned template cannot be connected to tor to create the morphing.
Telling the firewall to drop all incomming ICMP protocol still returns reply packets on sys-firewall but Kicksecure does not respond. ICMP Timestamps have already been taken care of in Qubes, but Qubes still responds to ping while Kicksecure does not. How important is that and how–if it is–can the same solution be applied to firewall or sys-net?
