hide-hardware-information.service running in sys-whonix breaks APT and update-torbrowser

Qubes-Whonix
1

It fails with “curl: (1) Received HTTP/0.9 when not allowed”.
Probably related to: Whonix Template upgrades broken - tinyproxy[846]: Proxying refused on filtered domain "127.0.0.1" · Issue #8606 · QubesOS/qubes-issues · GitHub

2

The cause above mentioned ticket was:

And that ticket was basically closed as wontfix.

Can you run sudo apt update without issues? Any other strange sytem issues currently?

Did you modify any files in /etc/profile.d, /etc/X11/Xsession.d or similar?

3

I cannot update with sys-whonix as the updatevm, I hadn’t noticed because I’m using sys-cacher with sys-whonix as the netvm (it currently works for Debian templates but also used to work for Fedora, it stopped after this issue).
There’s no more issues that I’m aware of, my problem seems to be one to one to those bug reports.
I did not modify any files, I reinstalled the templates to make sure.

Is there a “clean” workaround to this issue?

Sorry for the time I took to respond, I didn’t expect a fast reply.

4

There’s no known functional workaround yet. I have a hard time to suggest one because the issue isn’t understood yet by me

That bug report isn’t “really” a bug report that was experienced by users. This was a version in development that was never deployed to users. So no user had ever this issue. It was just me in a development version having accidentally caused console output by a script in /etc/profile.d (or /etc/X11/Xsession.d) which then unexpectedly caused APT to break in weird ways.

The same cause confusing APT would also lead to curl (used by updater-browser) also getting confused.

The only thing we can learn from that ticket is to make sure that scripts in these folders don’t cause console output.

Is this issue happening on Qubes R4.1 or Qubes R4.2?

If Qubes R4.1 then there is an issue which Marek mentioned in a comment here:
Announcement: Whonix 17 templates available for Qubes OS 4.1 by andrewdavidwong · Pull Request #126 · QubesOS/qubes-posts · GitHub

Can sys-cacher be used as UpdateVM? If sys-cacher (-> sys-whonix) generally works for you, then this might be a workaround?

Are you trying to use update-torbrowser from a Whonix Template that is using sys-cacher as its Qubes UpdatesProxy? In that case, you would need to bring this up with sys-cacher, as I haven’t used that yet.

For debugging purposes… Try running this in all relevant places (all involved places, Templates, dom0, sys-whonix, sys-cacher if using that):

sh /etc/profile

Expected output:

0

If there’s any other output, then this is a bug which can cause many issues.

Not sure yet how to test /etc/X11/Xsession or if that is even relevant.

5

related, created just now:

6

I’m using Qubes R.2, and if I’m not mistaken marmarek claimed that issue only affected dom0 updates.
The whonix-{gateway,workstation}-17 versions I’m running are the current latest 0:4.2.0-202312221915.

As previously mentioned by your ticket this issue seems to only affect templates however, I can still update vanilla Debian templates (tested with debian-12-minimal:0:4.2.0-202308031621) using sys-whonix directly no sys-cacher involved.

I can also update dom0 with sys-whonix.

Fedora (fedora-39-minimal:0:4.2.0-202311171650) fails with [Received HTTP/0.9 when not allowed].

Running sh /etc/profile ; echo $? returned 0 in every instance.

sys-cacher would be a great workaround but it isn’t compatible with update-torbrowser by default and I haven’t looked further into that, I used to switch to sys-whonix when a new browser update came around.

7

Contradiction.

  • A) Qubes UpdateVM is only used on context upgrading dom0.
  • B) Upgrading Templates refers to Qubes UpdatesProxy.

As per Qubes default, at time of writing:

  • UpdateVM can be changed through dom0 command line or Qubes VM Manager (QVMM).
  • UpdatesProxy can only be changed through dom0 configuration files.

Not really clear to me what is broken. No such issue reported ever in the default installation. (My unrelated development version issues don’t count.)

Can you upgrade Whonix Templates through sys-whonix UpdatesProxy? (Not Net Qube.)

Note, that Qubes is confusing here. The QVMM Net Qube setting for any (Whonix or otherwise) Templates remains none. That is handled through Qubes UpdatesProxy configuration files in dom0. Did you use any (cacher) salt commands in dom0? These might have changed UpdatesProxy away from sys-whonix to something else?

Please report a bug as per Reporting Guidelines. Exact steps for reproduction needed as in what commands run in which VM (or dom0) because this very most likely only happens after custom changes.

Would be good to have summary, list of what works and what’s broken.

  • dom0 with sys-whonix as UpdateVM: qubes-dom0-upgrade functional
  • whonix-gateway-17 Template with sys-whonix UpdatesProxy: APT upgrades functional
  • whonix-workstation-17 Template with sys-whonix UpdatesProxy: APT upgrades functional
  • whonix-workstation-17 Template: update-torbrowser broken with error message […]
  • anon-whonix App Qube: update-torbrowser functional
  • etc. whatever else seems relevant
8

You’re spot on I’m sorry for wasting your time, hopefully this interaction is helpful to someone.

My problem was caused by hide-hardware-info.service being enabled in sys-whonix, it isn’t enabled by default (but I had it enabled due to a custom saltstack formula).

As a side note sys-whonix used to work out of the box (in the context of qubes.UpdatesProxy) with hide-hardware-info.service enabled without needing to apply custom whitelists.

Not sure of how this issue relates to the other but I somehow managed to get things mixed.

I’ll make sure to learn how to properly report issues, until then I won’t waste peoples time.

9

Confirmed. There is no solution yet. If there ever is one, an update will be posted here.

This will not be forgotten, because this has been added to Reduce Kernel Information Leaks - Known Issues.

As weird as that is, I can confirm that,

  1. enabling Reduce Kernel Information Leaks, i.e.

running in in whonix-gateway-17 Template

sudo systemctl enable hide-hardware-info.service

  1. shutdown whonix-gateway-17 Template

  2. restart sys-whonix

  3. results in hide-hardware-info.service running in sys-whonix

  4. breaks APT (and also update-torbrowser) running from whonix-gateway-17 or even whonix-workstation-17 Template, which does not even use hide-hardware-info.service

systemcheck running in whonix-workstation-17 Template also detects the issue.

systemcheck

[ERROR] [systemcheck] Qubes UpdatesProxy Status Files Check: Failed!

Debugging information:
File /run/updatesproxycheck/whonix-secure-proxy-check-done exists but file /run/updatesproxycheck/whonix-secure-proxy does not exist. Check:
sudo journalctl --boot --output cat -u qubes-whonix-torified-updates-proxy-check.service
   
[INFO] [systemcheck] Qubes UpdatesProxy Reachability Test: Trying to reach local Qubes UpdatesProxy... PROXY_SERVER: http://127.0.0.1:8082/
[ERROR] [systemcheck] Qubes UpdatesProxy Reachability Result: Failed. (UpdatesProxy not reachable.)    (curl exit code: 7 | curl status message: [7] - [Failed to connect to host.])

Debugging information:

In Template:

sudo systemctl status qubes-updates-proxy-forwarder.socket  

● qubes-updates-proxy-forwarder.socket - Forward connection to updates proxy over Qubes RPC
     Loaded: loaded (/lib/systemd/system/qubes-updates-proxy-forwarder.socket; enabled; preset: enabled)
     Active: active (listening) since Fri 2024-02-02 12:51:27 UTC; 20min ago
     Listen: 127.0.0.1:8082 (Stream)
   Accepted: 111; Connected: 0;

This means that qubes-updates-proxy-forwarder.socket is running in Template but never reaches sys-whonix.

qubes-updates-proxy.service in sys-whonix is running and does not show anything out of the ordinary.

A much simpler way to reproduce is to,

  1. not use hide-hardware-information.service, and

  2. Manually, temporarily until reboot enable hide-hardware-info.

Simply run inside sys-whonix:

sudo /usr/libexec/security-misc/hide-hardware-info

Or.

sudo bash -x /usr/libexec/security-misc/hide-hardware-info

This will break APT. This results in the following error message inside the Template (which was previously functional)…

sudo apt update

Invalid response from proxy: Failed to check for virtualization: Permission denied HTTP/1.0 200 Connection established Proxy-agent: tinyproxy/1.11.1 [IP: 127.0.0.1 8082]

The following tool generates a similar error message. As user, in sys-whonix:

systemd-detect-virt

Failed to check for virtualization: Permission denied

This error message might be generated by a script in /etc/profile.d folder. This has a good chance of me being able to fix this.

10
11

This fix is now in the testers repository.