BUT every few weeks I […]
Why don’t you use a stable distro instead?
how would one go about hiding you are a Qubes user?
I’ve considered it, but it just brings a different risk, of being left without silent fixes that don’t get flagged as security-related… although I haven’t really looked very hard at what’s available. Suggestions welcome!
It seems like the basic choice is between being a sitting duck (maybe), and being a moving target at the bleeding edge, with the risks that brings. Or somewhere in between. I don’t really know what is the optimal strategy.
I think I’d always use the “late adoption” strategy - which seems somehow less adapted to LTS type distributions, and which is much more reasonable in Qubes-OS, where many of the risks of delayed updates can be mitigated. Plus, Qubes seems most reliable (in order) with recent-ish Fedora, then Debian, and then everything else, although it shouldn’t really be noticeable in a banking AppVM.
My preferred method is to have a minimal template, but to have every single package I use in any VM downloaded to the packet manager cache (e.g. dnf install --downloadonly). I can then install the packages when the VM boots or when I try to launch an application, which usually is very quick (as long as you make sure the package manager only work with the cache, e.g. dnf install -Cy). The way I do this automatically is that I have a systemd service running on the guest as root listening to requests to install a package, and a small wrapper that I can install as (for example) /usr/local/sbin/tcpdump. Packages that may be installed is decided by /rw/config/auto-install.env as such:
INSTALL_AND_EXEC_PACKAGE_FOR_tcpdump=tcpdump
I also include cached packages when the system is updated. This is handled by a salt script, if anyone is interested. Note that salt scripts run as root on dom0. Don’t blindly run salt scripts from anybody, they need to be manually reviewed before you use them.
What you protect against is guest VM privilege escalation and attack surface. Take chromium based browsers for example, they come with a suid executable to use privileged sandboxing syscalls. Other packages may introduce services which for example introduces new open ports (or systemd .socket with the same effect). Other program may install npm (scary stuff
). Having a minimal template minimizes this risk to the individual guest VMs. Basically this also means that it’s an exercise in pointlessness if you have qubes-core-agent-passwordless-root installed.
So most people agree that Whonix is not secure or/else private?
No, I only have interest in addressing the OP, not off-topic hijackers. However, the OP appears to be more curious about our soliciting our individual configurations.
I don’t really know what is the optimal strategy.
What is the strategy of data centers that use stable distros? - Certainly not the bleeding edge.
Important security fixes get backported. Stable doesn’t mean abandoned.
If you really need a particular package with a newer version, you can build it from source and put it e.g. in /opt, or install it from a particular non-stable repo in a specific template.