I was wondering, how qubes checks for updates.
I update packages via sys-whonix, which works fine, but the system seems to check for updates without sys-whonix. Whenever i update packages (using gui or console) it fires up sys-whonix automatically, but only on downloading the packages, not for checking for updates.
This seems to be by design. Why?
Unless you have disabled the qubes-update-check service, every qube will
check for updates, and then feed results back to relate to the appropriate
template.
If you have qubes connected to clearnet then you are presumably not
concerned whether you use Tor or not. If you do only want to use Tor
then only use Qubes connected to a Tor netvm, Whonix-gw.
Yes, i mainly use the clearnet. I just activated updates using tor to see what’s what.
Been just curious to see the update check using clearnet instead of tor. Thought this was a bug.
Downloading dom0 and template updates over Tor can provide specific security benefits by making it more difficult for you to be subject to targeted attacks involving malicious or withheld packages. For example:
-
An attacker may have gained access to an authentic upstream package signing key. He can use this key to sign a malicious package that is intended only for you. If you download updates using Tor, you force him to distribute the malicious package to everyone instead of only to you, which increases his risk.
-
An attacker may wish to withhold a specific package update from you so that your older version of the package retains a vulnerability known to the attacker. By using Tor, you prevent the attacker from knowing whether it is you trying to download a specific update as opposed to someone else.
In these scenarios, you may not care whether the update check goes over your clearnet connection, so long as the update is actually downloaded over Tor, since the latter is what matters for protecting you against these attacks.
1 Like
The question that asks dom0 updates over Tor only applies to dom0.
If you wanted all dom0 and template updates to happen via Tor, you would need to do the following:
In Qubes Global Prefs:
-
Set Dom0 UpdateVM to sys-whonix
-
Uncheck: Check for qube updates by default
-
Click: Disable checking for updates for all qubes
-
Edit /etc/qubes-rpc/policy/qubes.UpdatesProxy, change the second-to-last line containing
sys-nettosys-whonix:# Default rule for all TemplateVMs - direct the connection to sys-whonix $type:TemplateVM $default allow,target=sys-whonix(This is what Global Prefs tells you to do when you hover over Dom0 UpdateVM)
This will disable AppVMs from performing any checks for updates, which have a purpose of informing dom0’s updater GUI.
This means no notifications when updates are available, and you must now perform template updates manually by starting the template and doing the appropriate update command (dnf, apt, pacman, etc), or by using qubesctl.
A workaround to get notifications and still use Tor:
- Do all the steps above
- Create a new AppVM with a template you want notifications for
- Set the AppVM network to sys-whonix
- (Option 1) Enable the qubes-update-check in Services, and just run this qube every now and then for at least 10 minutes
- (Option 2) Or execute
qvm-run appvm_template_update_checker /usr/lib/qubes-upgrades-status-notify; qvm-shutdown appvm_template_update_checker
Now that I’ve described how to do it, I’d recommend against this (for most people) as it requires you to take on more responsibility in keeping your system up to date.
2 Likes
To follow up on what icequbes1 said, you can also update StandaloneVM via sys-whonix with Networking as none by adding these two lines in /etc/qubes-rpc/polic/qubes.UpdatesProxy:
$type:StandaloneVM $default allow,target=sys-whonix
$type:StandaloneVM $anyvm deny
And then in the service tap of the StandaloneVM add updates-proxy-setup
1 Like
I also have an additional question relating to this.
It says, in RPC policies | Qubes OS
(Note: the $ character is deprecated in qrexec keywords – please use @ instead (e.g. @anyvm). For more information, see the bulletin here.)
Should I be changing every files that contain $ to @ in /etc/qubes-rpc/polic/ folder?
cause there are a lot of files in there
Answer:
If one were to change all the dollar signs to at signs in the current official version of Qubes,
what would be the best way to go about it?
I mean, probably sed would do the job but I don’t feel so confident as my recall on sed is bit rusty.
Has anyone here done it? If so, please share the trick with us!
ahh actually I just done it myself. If anyone needs to know, here is the way.
[@dom0 ~]$ cd /etc/qubes-rpc/policy
[@dom0 policy]$ for i in admin* qubes* whonix*; do
> sed -i 's/\$/\@/g' $i
> done
I see that sys-whonix and qube-anon-whonix have the qubes-update-check service, but if sys-whonix is not started, for example, sys-whonix, the update will not be displayed, but the deployment may be updated.
I use Clearnet, but I also use a tor network. qubes-update-check If done using Clearnet, won’t privacy disappear completely?
@adw Aren’t they more likely to make package changes than clearnet when we update over the Tor network? If you can say that updating with the tor network is safer than clearnet, I can update with the tor network with peace of mind. Consider bank and shopping -clearnet- qubes.
/etc/qubes-rpc/policy/qubes.UpdatesProxy
Fixed the filename
Sorry, I’m having trouble parsing this sentence. Could you try rephrasing?
As you have said and know, they can hack us by changing the updated dom0 packages while we make the update. Isn’t it more insecure to update with the Tor network than to update it with clearnet? I mean, there may be those who take that risk for privacy, but is it worth taking that risk for safety?
For those who use Qubes-os for clearnet, bank accounts, etc., a update with clearnet can be a problem for privacy, but doesn’t it provide more security? The Tor network, as it is known, we go through a rift and cannot encrypt our latest server traffic like a VPN. I think if we’re targeted by some people, they’ll find us easier than clearnet.
No, because:
- Authentic updates are signed, and packages without valid signatures are rejected. The network is always untrusted, so it doesn’t matter if the connection is more or less secure.
- It’s debatable whether a Tor connection is less secure than a clearnet connection. That depends on whether you trust your circuit of Tor nodes more or less than the clearnet servers (including those of your ISP) between you and your destination.
- When updating over clearnet, it’s more feasible for an attacker to target you with a tailored attack. Updating over Tor generally forces the attacker to choose between serving a malicious package to everyone or no one, since it should be difficult for him to tell which Tor connection is coming from you. Serving a malicious package to everyone drastically increases the risk that the attacker will be discovered, which can be a deterrent. While not a foolproof solution, anything that forces your attacker to bear greater risks and costs is generally desirable.
See above.
This sounds like a misunderstanding about how Tor and/or VPNs work. The situation is basically the same: You also can’t encrypt the last hop between your VPN and the destination server, unless the destination supports it (e.g., HTTPS).
It should be the opposite, since Tor is specifically designed to provide anonymity or pseudonymity, whereas a normal clearnet connection is not.
Thank you so much for your answer.
I started to think that updating with the Tor network would be safer than clearnet, but since the tor network always remains on, I can keep it up to date and keep it up to date, etc. I can devote this time to my security, but can I set up the update to manually check only at certain times, as there may be many vulnerabilities that can occur from both the tor network and clearnet usage at the same time?
I also think I may have been spotted by people following me, such as the ISS, because so far I’ve done it through clearnet. So do I need to clean-install qubes-os? Or is it enough just to change the tor-network update?
You could probably accomplish this with a cron job, but that’s not Qubes-specific. Try seeking out some general Linux guides on this.
I don’t think anyone can answer this question for you, because no one really knows whether your system is compromised or not.
1 Like
Why is it necessary to disable automatic update checks for dom0 and qubes in the global settings manager if we want to solely update over Tor? If we make the Dom0 update qube “sys-whonix” in the Global Settings, and edit the etc/qubes-rpc/policy/qubes.UpdatesProxy file to force Template updates over Tor, won’t all template and dom0 updates go over Tor? What’s the point of disabling the update checker for dom0 and other qubes in the Global Settings if all updates are already going over Tor?
The only reason I can see this being the case is if the update checks for Templates are performed by the qubes themselves over clearnet/sys-net when they get started, while the actual update itself is transmitted over Tor. Is that right? In this case, would update checks for individual qubes that have sys-net/firewall access be over the clearnet? Will qubes with networking access only to sys-whonix check for updates over Tor then?
Yes, by default, template-based qubes check whether updates are available for their parent templates. If the qube doing the checking happens to connect over clearnet, then that check will not be done over Tor.
If they check for updates at all (I don’t know if Whonix qubes do), yes.