Messing around with Qubes and I noticed that different installations create the same files in different ways. For example /etc/qubes-rpc/policy/qubes.UpdatesProxy
Most of the times it’s how I put it on here ^ but sometimes the third line will be the 1st line instead and etc. I’m guessing this doesn’t matter and everything still works the same because every line acts as its own command or am I wrong?
The order matters. These are not commands; they are RPC policy rules. The file is parsed from top to bottom. As soon as a rule is found that matches the action being evaluated, parsing stops. Therefore, changing the order of the lines could affect when parsing stops and, therefore, how the policy file as a whole is evaluated.
This would depend on how you have been “messing around”, and whether you
selected different options at install.
This rule makes all templates update via sys-whonix
This rule makes all qubes which are tagged “whonix-updatevm” update via
sys-whonix
This rule makes all qubes which are tagged “whonix-updatevm” unable to
update.
The order clearly matters.
In the order given, all templates are updated via sys-whonix - you would
have selected this option at install.
If third and first lines are transposed, then templates tagged with
“whonix-updatevm” will not be able to update.
I don’t use Whonix and don’t know when the whonix-updatevm tag is set.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Interesting, I selected the option to update over Tor in every installation and did nothing else differently. The file just sometimes gets created in a different order I guess, I have no idea why. Do you think I should comment out the “$tag:whonix-updatevm $anyvm deny” if I want updates only over Tor. Or should I just keep it as last? Thanks for the feedback!
As @unman explained, in the line order you posted, the third line isn’t doing anything, so commenting it out won’t make any difference. [See below.]
Maybe, but it turns out that no user action was required in this case. If the user wants to tinker with something, but it turns out that there is no reason to do so, it does not follow that such tinkering ought to be made easier.
The purpose of the third/last line is to ensure that there is no attempt to update Whonix VMs via anything other than sys-whonix. For example, it could be bad for your privacy if something went wrong and the Whonix VMs tried to update via your clearnet connection. So, it’s a fail-safe. Normally, that third/last rule won’t do anything, but it’s possible that if something weird happens or something breaks, it could act as a safety net. So, I was incorrect to say that commenting it out won’t make any difference. In most cases it won’t, but it could, so you shouldn’t comment it out.
Taken together, the second and third lines are intended to ensure that all Whonix VMs are updated via sys-whonix, and that they are updated only via sys-whonix.
(Also, if you have other lines in your policy file that you didn’t include here, they could also affect the implications of transposing or commenting out any of the three lines we’ve been discussing. For example, if your fourth line were $anyvm $anyvm deny, then commenting out the third line actually wouldn’t change anything.)
In the installations where the third line ($tag:whonix-updatevm $anyvm deny) was first, did you notice that you weren’t able to update any Whonix VMs? (If you were still able to update your Whonix VMs, then that line couldn’t have been first.)
Unfortunately I can’t remember that because I didn’t use those installations for long.
Those 3 lines were the only lines in that file and always have been in every installation. I assume that’s how it’s supposed to be.
So am I correct in assuming that this is the right order that it’s supposed to be in and these are the only lines needed? Thank you for all the feedback!
I don’t claim to know the “right” order, but that’s the order mine are in, FWIW.
Well, whether other lines are “needed” depends on what you need your system to do. In my 4.0 installation, there’s another rule (after your three) for allowing clearnet updates (and I’ve also seen others post policy files containing this rule):
$type:TemplateVM @default allow,target=sys-net
However, if you never want to do clearnet updates, then I suppose you probably don’t need (or want) this rule.