How to identify which template requested to use the update proxy?

Problem: every client has the same ip, localhost

First, templates are network isolated by default and only can use the update proxy 127.0.0.1:8082 done with permanent port binding - QubesOS Firewall Docs
Some important files:

  • /etc/qubes-rpc/policy/qubes.UpdatesProxy
  • /lib/systemd/system/qubes-updates-proxy-forwarder@.service
  • /lib/systemd/system/qubes-updates-proxy-forwarder.socket
  • /lib/systemd/system/qubes-updates-proxy.service
  • /etc/tinyproxy/tinyproxy-updates.conf
  • /etc/tinyproxy/updates-blacklist

The problem is that as it is reaching directly to localhost, different templates requests will have the same client ip (127.0.0.1).

CONNECT   Jul redacted [495424]: Connect (file descriptor 10): localhost [127.0.0.1]
CONNECT   Jul redacted [495424]: Request (file descriptor 10): GET http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/vm/dists/bullseye/InRelease HTTP/1.1
INFO      Jul redacted [495424]: No upstream proxy for deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion
INFO      Jul redacted [495424]: opensock: opening connection to deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
INFO      Jul redacted [495424]: opensock: getaddrinfo returned for deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
CONNECT   Jul redacted [495424]: Established connection to host "deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion" using file descriptor 11.
INFO      Jul redacted [494774]: Closed connection between local client (fd:10) and remote client (fd:11)

So every client gets the same ip.

Maybe solution? IDK

I am thinking of using virtual interfaces to connect templates to the update proxy vm, but don’t know if it is recommended as templates are non networked by default and this needs to be done by someone more experienced with networking than me.

Use case: identify misuse of the proxy

This can help if monitor tinyproxy logs to identify which qube made the request to the tinyproxy proxy, so it can identify templates that are reaching unwanted domains, maybe leaks, maybe compromised…
So when this is identified, it can be corrected on the cliend_addr qube, but for know it is unkown as every client is 127.0.0.1.

Use case: is stream isolation:

Whonix apt-get stream isolation thread, this is not a whonix issue, as the problem is in tinyproxy not getting the correct client addr as everything is coming from localhost. That is why SocksPort IsolateClientAddr doesn’t matter as of know as.

DNS requests use first the clien addr as 127.0.0.1
Establishing connections uses the update proxy qubesdb ip (sys-whonix qube ip)

Note the Client port and Target:
Circuit reuse:

    ID Purpose              Client                CircID CircPurpose          Target                                                        
------------------------------------------------------------------------------------------------------              
  2161 USER                 10.137.0.8:50356        2137 HS_CLIENT_REND       10.196.7.103~(deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80)                  
  2165 USER                 10.137.0.8:50362        2137 HS_CLIENT_REND       10.196.7.103~(deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80)
    ID Purpose              Client                CircID CircPurpose          Target                                                        
------------------------------------------------------------------------------------------------------
  2157 DNS_REQUEST          127.0.0.1:60375         2122 GENERAL              deb.debian.org~(199.232.150.132:0)                            
  2158 DNS_REQUEST          127.0.0.1:60375         2122 GENERAL              deb.debian.org:0                                              
  2161 USER                 10.137.0.8:50356        2137 HS_CLIENT_REND       10.196.7.103~(deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80)
  2162 USER                 10.137.0.8:41466        2032 GENERAL              deb.debian.org~(199.232.150.132:443)                          
  2165 USER                 10.137.0.8:50362        2137 HS_CLIENT_REND       10.196.7.103~(deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80)

I am expecting qubes update to show the tinyproxy client addr so stream can get isolated. For example, this is how 2 anon-whonix appvms (not templates) are identified with different client_addr by the same gateway (no circuit reuse because of SocksPort IsolateClientAddr):
The client addr are the ws qube ips.

    ID Purpose              Client                CircID CircPurpose          Target                                                        
------------------------------------------------------------------------------------------------------
  2235 USER                 10.137.0.10:40636       2146 HS_CLIENT_REND       5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion:80
  2236 USER                 10.137.0.10:40640       2151 HS_CLIENT_REND       qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
  2237 USER                 10.137.0.10:40644       2166 HS_CLIENT_REND       dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion:80
  2238 USER                 10.137.0.10:40648       2153 HS_CLIENT_REND       2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion:80
  2239 USER                 10.138.33.110:49262     2156 HS_CLIENT_REND       qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
  2240 USER                 10.138.33.110:49266     2175 HS_CLIENT_REND       dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion:80
  2241 USER                 10.138.33.110:49272     2165 HS_CLIENT_REND       2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion:80
  2242 USER                 10.138.33.110:49274     2174 HS_CLIENT_REND       5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion:80
2 Likes