What is in your 90-default policy?
Sorry, what do you mean by that?
What rules for updating are there, if you are using 4.1?
You mean in the file?
$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
I switched the last line to the first, it should have stopped all updates to my understanding. But the Fedora and Debian ones still went through. I am on 4.1 and those are the only lines
/etc/qubes/policy.d/90-default.policy
You may want to check and experimenting with it by giving it lower number, since qubes.UpdatesProxy is deprecated in 4.1 but it has legacy support. Also, you can try to switch from $ to @ which is also introduced in 4.1.
2 Likes
Appreciate it, but I don’t think I should be messing around with the files like that on my main Qubes setup. I don’t really know what all that does. It really doesn’t even matter to me how the Fedora and Debian updates work. I only use Qubes for whonix so I’d just like to make sure that the updates for those templates go through Tor. And dom0 should be fine as long as the update qube for it is set as sys-whonix in global settings.
Only reason I’m enquiring about this is because like I said someone on here already told me that all template and system updates go through Tor if you check it during installation. But now when I mess the file up, the updates for Fedora and Debian are still working. Someone on Reddit just told me that the 2 other lines in that file (the first two in my previous reply) only apply to Whonix VMs. So I guess there aren’t even any rules to begin with that would update the Fedora, Debian templates through Tor? I hope I’m getting this right. Anyways, as long as the file in its original state still makes updates for Whonix WS/GW go through Tor, I’ll be happy.
You can check this by shutting down sys-whonix then try to update whonix-xxx. If starting of sys-whonix is invoked then everything is OK. It’s done via tor.
1 Like
That’s what I did with Fedora and Debian too. I shut down sys-whonix and tried to update the Deb and Fed templates. It did start up sys-whonix again and updated Deb/Fed, but how would it even be going through Tor if the qubes.UpdatesProxy file doesn’t have any rules regarding those templates? That’s why I was feeling like maybe it starts up sys-whonix because it’s supposed to go through that, but it doesn’t actually go through that.
This one has, and that is why I told you to check it?
1 Like
Okay, I see now. The command for “Upgrade all TemplateVMs through sys-whonix” is commented out. That’s why the updates for Fed/Deb were still going through. This whole time I was under the assumption that those Templates also go through Tor for updates. So for example if I want to also make Deb/Fed updates go through whonix, then I would need to uncomment the line from this file, but also add the line to qubes.UpdatesProxy? Are these two files somehow connected to eachother or something? And why does one use @ instead of $
1 Like
If any post resolved it for you please consider to flag it as a solution so it could help other users too.
My only real goal is to be certain that the whonix templates go through Tor for updates. So just for clarification: As long as the “/etc/qubes/policy.d/90-default.policy” file has the “Upgrade Whonix TemplateVMs through sys-whonix” and “Deny Whonix TemplateVMs using UpdatesProxy of any other VM” commands uncommented, and also has those same commands in “qubes.UpdatesProxy”, it should always go through Tor for whonix template updates right? And does it matter if I keep it $ on there or change it to @ like on the first file?
I understand that “/etc/qubes-rpc/policy/” is now the older version of “/etc/qubes/policy.d/” but it’s still in the filesystem and has an effect on updates, so making sure everything is right in “/etc/qubes-rpc/policy/” is recommended as well right?
Thank you for all the help!
It should.
It won’t matter until Qubes 5.0, as written there, but you have to keep an eye of 35-compat.policy which provides compatibility.
1 Like
I never said that. 
I said that rule won’t allow Whonix VMs to be updated.
Specifically, I wrote:
1 Like
You seem to know more about the policy files than anyone here so could you verify if I was correct on everything I said in my last reply on this post ^^
Thanks for always helping me
Since you still aren’t sure, please unmark my post as solution.
Your post solved it but I’m just trying to verify with ADW since he’s a part of the Qubes team.
My advise would be:
- you have to assure yourself, not by others, otherwise there always be a shadow of doubt which is not good by any means.
- if something is stated wrong here, “seniors” would most probably react, especially if wrongs are stated by “juniors” (like I am). I’m finding the proof in that @adw reacted on your wrong comprehension of his words, and on nothing else in this topic.
Conclusion: dare and believe in yourself. I hope you’ll find only positives in my post.
1 Like
I appreciate the vote of confidence, guys, but I’m not a technical authority. I’m basically just a user/enthusiast who has been using Qubes for a decently long time and who happens to work on the project as community manager and volunteer website and doc maintainer. There are many folks here who are far more knowledgeable than I am about technical matters. Also, when I don’t comment on something, that shouldn’t be taken as an indication of anything. It probably just means I don’t know about it, didn’t see it, or have no opinion on it.
I don’t know the details of the new system in Qubes 4.1, but my understanding is that these three rules, in this order, in /etc/qubes-rpc/policy/qubes.UpdatesProxy, in Qubes 4.0, are sufficient to ensure that all Whonix VMs are updated through sys-whonix and only through sys-whonix:
@type:TemplateVM @default allow,target=sys-whonix
@tag:whonix-updatevm @default allow,target=sys-whonix
@tag:whonix-updatevm @anyvm deny
I don’t see why the same wouldn’t hold in Qubes 4.1 in the new unified policy file, but I can’t say with certainty that it does.
As already explained above, both types of syntax are supposed to be compatible in Qubes 4.1. As stated here:
In all client tools,
$will still be automatically translated into@, so you don’t have to change any existing scripts. However, we highly recommend using only@. Legacy support for$will continue throughout the Qubes 4.x series and end in Qubes 5.0.
All I know is what’s stated here:
One of the new policy files is
35-compat.policy. It loads the old policy files and parses them in a way compatible with the new policy format.
I interpret this as meaning that the answer to your question is “yes.” At any rate, I can’t see how it would hurt to ensure that the rules in the new and old policy files match.
1 Like