Update via SaltStack: What Happens on Interactive Updates?

User Support
1

I used the normal command line terminal to update like
apt update && apt upgrade for Debian, dnf update for Fedora and qubes-dom0-update for dom0.
However, I found out about this command:

sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm

Basically what it does is update any TemplateVM, right?
My question is:
What happens (where is the error output displayed) when an error occurs during the update. For example, a change in the source.list files.
Normally the terminal would show an option for overwrite, show differences or keep the old version.

2

I asked a similar question here:

on Debian non-interactive updates will not be able to prompt users for configuration choices via debconf.

So what currently happens when updating Debian templates via Salt when there is such a choice?

Perhaps @Demi might know the answer.

3

Thanks for your provided GitHub issue link.

Personally, it would be enough for me if an error is displayed and nothing happens. Then I can go to TemplateVM and fix it myself.
I want to have full control over my updates. As far as I know, this is not possible with non-interactive updates.

I don’t know if it is possible to make non-interactive more robust. If you change many source.list files of the repository, it depends on the specific change each time.

Where can I learn about the security risks of doing updates with my described “normal” Linux update method? Can you please provide me a link?

Additionally, I would like to point out that using VMs becomes more fingerprintable if you do all updates at the same time (or at least 4 is the default). It should be a better option to create a script that updates one VM at a time with random (long) pauses between the next.

4

Thanks for your provided GitHub issue link.

Personally, it would be enough for me if an error is displayed and nothing happens. Then I can go to TemplateVM and fix it myself.
I want to have full control over my updates. As far as I know, this is not possible with non-interactive updates.

I don’t know if it is possible to make non-interactive more robust. If you change many source.list files of the repository, it depends on the specific change each time.

Where can I learn about the security risks of doing updates with my described “normal” Linux update method? Can you please provide me a link?

You can find an extensive discussion of this in the Forum - for example
in the thread Recommendation against "qubes-dom0-update" - biut it
has been mentioned many times.
In brief, the salt mechanism is used to push out system configurations,
fixes etc relating to updating. If you manually update the templates you
will not have these automatically.
If you pay attention to the QSB then you can make the necessary changes
for yourself before manually updating.

Additionally, I would like to point out that using VMs becomes more fingerprintable if you do all updates at the same time (or at least 4 is the default). It should be a better option to create a script that updates one VM at a time with random (long) pauses between the next.

I don’t understand.
Are you concerned about “fingerprinting” the fact that you are using
VMs?
Qubes leaks that information all the time in default configuration, in
time checks, update checks, and (most likely) usage. You can take steps
to mitigate this but this is intermediate to advanced Qubes use.
The same goes for changing the number and frequency of updates.
You can roll your own script to do this, iterating over the templates
with random sleeps between calls to
qubesctl --skip-dom0 --targets=<target_qube> ..

1 Like
5

(made the title more specific about the issue discussed)

6

Thanks.
My point about fingerprinting: if the repo server gets update hits in a certain pattern, that information can potentially be correlated with how many VMs a user has in use.

7

Anyone monitoring your internet activity would be able to get this
information even if you use random sleeps between updates.
The only way to avoid leaking that information would be to use a caching
proxy and Tor.

8

What do you mean by a caching proxy?
I am a big fan of Whonix. I do all my updates with Whonix (Tor).

9

A caching proxy is a proxy that stores the packages, so that other calls
for the same package are serviced from the proxy instead of from the
internet.
tinyproxy, used by Qubes, does not cache.
If you have many templates using the same repositories, (many cloned
Debian templates, for example), a caching proxy will reduce network
usage, and speed updates.
I discuss one solution, apt-cacher-ng, at GitHub - unman/notes

A caching proxy can hide the number of templates you have, because a
monitor could only see one one call to the repositories - could
because you will need to ensure that calls to get the list of available
packages are also cached, and this is not the default. (If you have
repositories that change rapidly this may be an issue.)

I too use Tor extensively, but not Whonix.

10

2 posts were merged into an existing topic: Use-cases for Non-Whonix Tor in Qubes