Update check without sys-whonix

[SteveC]

@adw

Yes, by default, template-based qubes check whether updates are available for their parent templates

By what mechanism do they do this? I literally have to run the template to get it to check (leading to me either cloning a template so I can run the clone, or just pre-emptively trying to update templates to see if they will find updates). So clearly in constructing my minimal-based templates, I left something out.

[adw]

I think that’s discussed in this thread:

Updates check over clearnet instead of sys-whonix and other strange decisions

So I just installed Qubes 4.2.2. Before setting up everything I wanted to disable updates completely, because I didn’t want to advertise using QubesOS to my ISP. First of all, it was impossible to actually choose “none” at the “Default update proxy” field at “Qubes OS Global Config”. The option is there, you can choose it, but it just not being saved, when you reopen Global Config you can see some other option chosen already. I had to choose sys-whonix, at least I expected that nothing will t…

[SteveC]

That thread seems mostly to be a gigantic wrangle over whether to check over tor or regularly.

In my particular case, if I run an appvm based on some minimal template that needs an update, no update check occurs. I have to actually run the template. There seems to be something missing from my minimal template that would cause the check to happen when the appvm is run, as opposed to the template.

(And yes, I know it wouldn’t work if the appvm has no network access.)

[magazine]

since the latter is what matters for protecting you against these attacks

You could argue that if an adversary is capable of identifying you based on your clearnet update checks, you would have a higher chance of updating after one. Subsequently, the adversary could distribute a malicious package or withhold a specific package during a short period after you’ve run an update check, thus minimizing exposure while maximizing the attack surface.

[solene]

@magazine

Subsequently, the adversary could distribute a malicious package

Packages are signed, so they can’t unless they have access to the private keys used by Debian / Fedora / Whonix. But they can prevent you from download updates indeed.

[adw]

@magazine

You could argue that if an adversary is capable of identifying you based on your clearnet update checks, you would have a higher chance of updating after one.

I’m not sure if we can assume that most update downloads occur shortly after update checks. By default, update checks happen automatically in the background from network-connected qubes, whereas update downloads must be manually started by the user. I suppose it depends on how quickly users proceed to download updates after being notified that they’re available.

@magazine

Subsequently, the adversary could distribute a malicious package or withhold a specific package during a short period after you’ve run an update check thus minimizing exposure while maximizing the attack surface.

The adversary would still not be able to definitively link the update check and the update download, since the update check is over clearnet and the subsequent update download is over Tor. He won’t know which Tor users he should target with his malicious package X update or block from getting package X updates. While he could assume that his target is in the set of all Tor users who try to get a package X update shortly (however he chooses to define “shortly”) after his target’s clearnet update check, there’s a fairly high risk that he’ll attack non-targets (thereby increasing the chance of the attack being discovered) and fail to attack his actual target.

Nonetheless, you’re right that there’s a potential correlation attack between clearnet update checks and Torified update downloads (depending on user habits) and that decorrelating these activities would be an improvement, as it would tend to make such attacks more difficult.