I prefer using Whonix (in Qubes) as my default computing environment. (Thanks for that). I’ve got two dispVMs setup, one the default, and the second based on Whonix Workstation but without networking. And I’ve got other Whonix based qubes without networking for other purposes.
I’ve long been aware that the little lock icon noted that these off-line Whonix instances with a little lock with an X in the middle of them. I hadn’t put much thought into it, but I recently realized that this means that officially offline qubes are actually communicating with a network qube (sys-whonix), even if it’s just to talk to sdwdate-gui.
This seems to me to be a design defect. The expected behavior is that my off-line qubes should be actually offline, and not mostly offline. But secondly, not having spend 5 seconds researching the matter, it raises the obvious question: are my offline qubes talking to any other network qubes behind my back? What’s to stop them? I guess that’s more of a Qubes question. Maybe we need a new check box in the setup menu for qubes: [ ] Don’t connect to anything, period!". But wasn’t that supposed to be the default for a qube without a network?
You probably don’t need to do what you’re suggesting, but before getting to that, if you really don’t want sdwdate-gui to talk to sys-whonix anymore, you can do it. It’s not particularly easy since sdwdate-gui is actually there to improve security and isn’t considered a security risk on it’s own, but you can still do it.
Make sure you have a dedicated Whonix-Workstation template that all of your non-network-connected Whonix-Workstation qubes are based upon. Uninstall sdwdate-gui from that template using sudo dummy-dependency --purge --yes sdwdate-gui. Then lastly, configure dom0 to prevent any form of sdwdate-gui communication from coming from the non-networked qube. sudo nano /etc/qubes/policy.d/30-user.policy, and add the following lines:
For why you probably don’t want to disable all inter-qube communication this way:
The problem with networked qubes is not that networked services are intrinsically unsafe. It’s that networked services are used by many, many insecure or possibly insecure applications, and networking is oftentimes used by design for passing untrusted data between applications. The ability to communicate is not itself bad, it’s how people use it that’s the problem. Cutting off all ways for a qube to communicate or receive communication would probably restrict things a lot more than you’d think; qrexec (the same mechanism used by sdwdate-gui) is used for dom0 to ask qubes to launch applications, it’s used for qubes to tell dom0 what apps are available, it’s used for templates and dom0 itself to get software updates, etc. Another mechanism called vchan is used so qubes can display windows on your screen and receive mouse and keyboard input. Another mechanism called qubesdb is used for dom0 to communicate settings and properties to each qube. The Xen console is used by the “Open console in qube” feature of Qube Manager. And so on.
The main reason all these different channels aren’t considered a threat to security is because they are far, far more restrictive than the network. With the network, any application can simply open a port and let any other application on the system, on the LAN, or maybe even in the world to talk to it and try to compromise it. With qrexec, you have to be root to do something analogous to “opening a port” (i.e. by creating a UNIX socket or placing a handler executable in /etc/qubes-rpc), and all qrexec connection requests have to have dom0’s approval before that connection can be made. dom0 stores a policy database at /etc/qubes/policy.d that has rules for what services in various qubes can and cannot talk to each other. The other communications mechanisms have even more restrictions. This makes it a lot easier to implement applications in a safe manner. The fact that qrexec is unique to Qubes also helps, since reputable projects that write services that use qrexec typically do so in a security-conscious fashion (Whonix included).
Before I ramble on, may I humbly suggest, if it makes any sense at all, that sdwdate-gui detect whether the qube it’s running on has a network or not, and if not, abort? From an interface perspective, my Whonix icon is always (X) because I’ve got one of these networkless Whonix qubes running. So it’s not actually very informative, and I have to manually check if one of my networked Whonix qubes is acting up.
I’m going to use this thread to document my exploration of sdwdate-gui and qrexec.
You convinced me that it’s kind of impossible for there to be no inter-qube communications. How could dom0 control app windows running in a qubes if there was no communication? And my own scripts use commands like qvm-copy-to-vm and qvm-run, even with networkless qubes. I’m not trying to sound like an idiot, I just think it’s useful to wrap and re-wrap my head around Qubes and Whonix architecture. For people like me who are not professional security experts a lot of the trust in Qubes+Whonix runs on faith in simplistic abstract models that may not fit reality. It’s good to learn more about it.
What stood out for me (and the reason I posted my question) was the discrepancy between the politics around user notifications for qvm-copy/move-to-vm and the silence of sdwdate-gui. Apparently it is extremely important for users to be notified when a file is being copied from one vm to another, just in case a malicious script tries to send private information to a qube with network access–to the point that the target qube name isn’t the default in the GUI window, so the user has to constantly manually select instead of just pressing enter. (That issue made me aware of the qubes/policy folder a while back.)
So it’s curious that qrexec can do it for free, without notifications or interface complications. I have to think about that a bit more. The most obvious reason would be that notifying the user for every inter-qube communication would make using Qubes impossible. So a solution had to be found to streamline inter-qube communication. That’s qrexec, which is extremely locked down to specific functions compared to qvm-* which can pass anything. And sdwdate-gui is part of QubesOS officially and has its own qrexec functions:
qubes-core-admin extension for handling Whonix related settings
tag sdwdate-gui-client used for sdwdate-gui qrexec functions.
So sdwdate-gui is a well-understood component of default QubesOS, and that explains why it enjoys the privilege of silence. The behavior of sdwdate is not a design defect. It’s well designed, but the reasoning behind that design is a bit opaque and technical. This is to be expected for software intended to make something complex convenient and easy-to-use, goals that are required for interface design.
I want to learn more, so I found the source of sdwdate on my (Whonix 17) machine in
showlog, restart, and stop are kind of obvious. NewStatus+status is that thing constantly giving me error notifications.
The one I’m most curious about is SdwdateStatus.
But here I come to a dead end. I can’t figure out where whonix.SdwdateStatus lives. It’s a Python object, but it doesn’t come up in a grep of my system’s Python libraries, or in the QubesOS codebase via Github. And qrexec-client-vm, where this object probably lives, is a binary (not a Python script) so I can’t look under that hood. And qrexec-client-vm source doesn’t come up in a search on the QubesOS Github or a web search. I couldn’t find a relevant link on the QubesOS forum. Maybe I’m just bad at searching. I’m also not great at Python. (More of a Bash person).
Can you tell me where to find the source for whonix.SdwdateStatus and other related qrexec functions? Where is the qrexec-client-vm source code? Thanks.
Imo not wroth studying the Qubes-Whonix for Qubes R4.2 code base as sdwdate-gui was rewritten for Qubes R4.3.
One could say “don’t use Whonix for offline VMs” and “use Kicksecure” for that but the issues would be the same.
Indeed, an offline mode would be useful. Detecting that there is no network interface and therefore disabling bootclockrandomization, sdwdate and sdwdate-gui.