Is qubes updater fixed?

qubesmous · September 11, 2022, 3:01pm

No need for long commands in the terminal anymore?

npb · September 11, 2022, 3:13pm

Assuming you are referring to this issue:

github.com/QubesOS/qubes-issues

Updating via Salt falsely claims to succeed when it actually fails

opened 01:33PM - 07 May 21 UTC

closed 01:37AM - 10 Jul 22 UTC

andrewdavidwong

T: bug P: critical C: mgmt security r4.1-dom0-stable diagnosed C: updates

**Qubes OS version** `R4.0` **Affected component(s) or functionality** … Updating via Salt (Qubes Update tool / `qubesctl`) **Brief summary** When updating via Salt (Qubes Update tool / `qubesctl`) fails, it falsely reports that it was successful. A user could go months or longer without receiving any security updates, while Qubes claims that every update is completing successfully. This can lull users into a false sense of security and constitutes a potential attack vector. **How Reproducible** 100% **To Reproduce** Steps to reproduce the behavior: **Note:** I'll use dom0 in these examples, but the same things happens with templates. 1. Unplug your ethernet cable, disconnect from Wi-Fi, or intentionally set up your system so that the update process will encounter an error. One way to do the latter is by adding `repo_gpgcheck=1` to all enabled repos in `/etc/yum.repos.d/qubes-dom0.repo`, which will currently cause cause a curl error when trying to update, unless you have implemented a specific workaround (see https://github.com/QubesOS/qubes-issues/issues/6275). 2. Try updating via Salt. Since we know (from Step 1) that the update cannot possibly succeed, we should expect some indication that the update encountered a problem. At the very least, the update should not claim to have succeeded, since it couldn't have done so. ``` $ sudo qubesctl --show-output state.sls update.qubes-dom0 local: ---------- ID: /etc/yum.repos.d/qubes-dom0.repo Function: file.replace Result: True Comment: No changes needed to be made Started: 05:21:34.989474 Duration: 5.357 ms Changes: ---------- ID: /etc/yum.repos.d/qubes-templates.repo Function: file.replace Result: True Comment: No changes needed to be made Started: 05:21:34.994933 Duration: 1.083 ms Changes: ---------- ID: update Function: pkg.uptodate Result: True Comment: System is already up-to-date Started: 05:21:35.509286 Duration: 245241.606 ms Changes: Summary for local ------------ Succeeded: 3 Failed: 0 ------------ Total states run: 3 Total run time: 245.248 s ``` The update falsely claims to have succeeded (`System is already up-to-date`, `Succeeded: 3`), even though we know that's impossible. 3. Now, let's see whether `qubes-dom0-update` fares any better: ``` $ sudo qubes-dom0-update Using sys-update as UpdateVM to download updates for Dom0; this may take some time... Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message) Fedora 25 - x86_64 - Updates 0.0 B/s | 0 B 04:00 Errors during downloading metadata for repository 'updates': - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f25&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] [Errno 2] No such file or directory: '/var/lib/qubes/dom0-updates/var/cache/yum/x86_64/4.0/metadata_lock.pid' ``` `qubes-dom0-update` accurately reports that it encountered an error -- exactly the sort of error we would expect from lack of internet access. **Expected behavior** When updating dom0 via Salt (Qubes Update tool / `qubesctl`), any underlying errors should be reported to the user so that the user is alerted that the update was not successful. This could prompt the user to re-attempt the update and try to fix the problem. This is important, because missing out on security updates can be fatal to the security of any operating system, including Qubes. **Actual behavior** Updating via Salt reports success regardless of whether it actually did anything. Even when we physically cut off internet access, the update blithely reports `System is already up-to-date`. It has no way to know this, since it can't even reach the update servers. It's no exaggeration to call this a bald-faced lie. Users could go for months without getting any security updates while Qubes lies that updates are completing successfully the whole time. An attacker who manages to block the user's updates (e.g., connection to update servers) needn't bother to do anything else, since the user will notice no difference in the system, because there is no change to notice. **Additional context** Unfortunately, the answer is not as simple as just exclusively using direct commands like `qubes-dom0-update`, `dnf update`, `apt update`, and their variants. As explained in https://github.com/QubesOS/qubes-posts/pull/79, there are strong reasons to shift the status quo away from using those direct commands and instead to recommend updating via Salt. I wrote that post before discovering this bug. This certainly changes things. Our one saving grace is that we've established a system for reporting QSBs and made it clear to the userbase that it's important to keep up with them. In practice, however, it's likely that some not insignificant portion of the userbase fails to heed QSBs (either at all or in a timely fashion). Moreover, this doesn't help with any upstream security updates for TemplateVMs and StandaloneVMs for which we don't issue QSBs. In addition, we don't want to remain reliant on external messaging like QSBs forever. Qubes OS should be self-sufficient, and our ultimate goal is not to require the user to monitor any external channels (see https://github.com/QubesOS/qubes-issues/issues/3430). **Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted** https://www.qubes-os.org/doc/salt/ **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** #6275 -- I stumbled upon this while testing the `repo_gpgcheck=1` thing mentioned in Step 1 above. When I noticed that updating via Salt was unchanged by the curl error (https://github.com/QubesOS/qubes-issues/issues/6275#issuecomment-834315348), I investigated further, which led me to discover and report this bug. #5186 -- This issue appears quite similar, but it was actually reporting something much narrower: It was reporting the case in which the `qubesctl` output actually prints an error message (`stderr: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.`) but went on to add that case to the "succeeded" counter. That case was less worrisome, since the user was alerted to the fact that there was a cache synchronization error (but still a bit worrisome, since it was counted as a success). By contrast, this case is extremely worrisome, since there is *no indication whatsoever* that we were not even able to contact the update server, much less actually confirm that we have all updates, yet the output explicitly reports `System is already up-to-date`.

The instructions for the workaround were reverted in this commit:

You can see the before and after comparison of the documentation in the commit.

At the current time, I am only using the Qubes Update tool to update Qubes OS and the templates.

For some additional discussion, see this thread.

qubesmous · September 11, 2022, 3:23pm

Thank you

tanky0u · September 12, 2022, 12:22pm

Why only the “update tool”? I am using the CLI equivalent commands of this. Is this wrong to do?

npb · September 12, 2022, 2:57pm

To clarify, I intended to convey that I feel my system is up to date after a single step: running the Qubes Update tool. At the current time, I no longer feel the need to perform the actions that were removed from the documentation in addition to the Qubes Update tool.

The documentation suggests you can use the command line. Within the linked section you can click on update.qubes-dom0 and update.qubes-vm despite them not appearing as links.

However, I have no knowledge if this produces the same effect as the Qubes Update tool.