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