Does order of rules in qubes.UpdatesProxy matter?

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

$type:TemplateVM $default allow,target=sys-whonix

$tag:whonix-updatevm $default allow,target=sys-whonix

$tag:whonix-updatevm $anyvm deny

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.

2 Likes

So this is a bug that needs to be fixed?

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.
3 Likes

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!

Updated the title to help new users find it easier

1 Like

Update proxy should be much easier to change if user friendliness is the goal.

1 Like

True, updates over Tor are one of the more important things for me. Esp because I only use Qubes for Whonix

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.

Nonetheless:

1 Like

Actually, let me correct my statement here.

In the order you posted:

$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

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.)

1 Like

Going back to the original question:

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.)

1 Like

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.

1 Like