sys-whonix can reach non-torified Qubes updates proxy

[adrelanos]

Qubes OS version:

R4 RC1

Affected TemplateVMs:

whonix-gw

Steps to reproduce the behavior:

In sys-whonix.

curl.anondist-orig --proxy http://10.137.255.254:8082/ https://check.torproject.org | grep Tor

Expected behavior:

Connected to Tor.

Or Updates Proxy not reachable.

Actual behavior:

Not connected to Tor.

General notes:

If the same was to happen in anon-whonix (or whonix-gw or whonix-ws), this would be a very bad issue. This is still not great since utility_functions.sh sets PROXY_SERVER='http://10.137.255.254:8082/'.

sys-whonix does not upgrade through Qubes update proxy because fortunately file /etc/apt.conf.d/01qubes-proxy does not get created. But that seems seems like a small margin of error.

Can we somehow do better here to make sure bugs cannot easily lead to the user accidentally sys-whonix being upgraded through clearnet?

[marmarek]

Isn't it responsibility of a firewall inside sys-whonix to not allow clearnet access for anything other than tor itself and clearnet user?

[marmarek]

Isn't it responsibility of a firewall inside sys-whonix to not allow clearnet access for anything other than tor itself and clearnet user?

[adrelanos]

Right.

https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L323-L353

Any suggestions?

[adrelanos]

Right.

https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L323-L353

Any suggestions?

[marmarek]

I wonder why it is allowed there (in sys-whonix) at all - I was thinking about some Qubes 3.2 compatibility, but even there sys-whonix should not have access to clearnet updates proxy. I see there is a rule in OUTPUT chain allowing anyone to access 10.137.0.0-10.138.255.255, which potentially include anything exposed by sys-firewall or sys-net. Fortunately there are no other services there, but that's not a big consolation.
It's here: https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L150-L166
For what this section is there?
BTW There is also a rule for 127.0.0.0-127.0.0.24, which looks suspicious. Shouldn't that be 127.0.0.0/24? Or even 127.0.0.0/8?

[marmarek]

I wonder why it is allowed there (in sys-whonix) at all - I was thinking about some Qubes 3.2 compatibility, but even there sys-whonix should not have access to clearnet updates proxy. I see there is a rule in OUTPUT chain allowing anyone to access 10.137.0.0-10.138.255.255, which potentially include anything exposed by sys-firewall or sys-net. Fortunately there are no other services there, but that's not a big consolation.
It's here: https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L150-L166
For what this section is there?
BTW There is also a rule for 127.0.0.0-127.0.0.24, which looks suspicious. Shouldn't that be 127.0.0.0/24? Or even 127.0.0.0/8?

[adrelanos]

Marek Marczykowski-Górecki:

I wonder why it is allowed there (in sys-whonix) at all - I was thinking about some Qubes 3.2 compatibility, but even there sys-whonix should not have access to clearnet updates proxy. I see there is a rule in OUTPUT chain allowing anyone to access `10.137.0.0-10.138.255.255`, which potentially include anything exposed by sys-firewall or sys-net. Fortunately there are no other services there, but that's big consolation. It's here: https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L150-L166 For what this section is there?

It's a very good question and should be reconsidered. Reasons that I can remember: - [1] Whonix (back then TorBOX) was originally based on this guide: https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#LocalRedirectionandAnonymizingMiddlebox - [2] To prevent connections to the local network being redirected to Tor. Such as for diagnoses purposes, i.e. ping the workstation from the gateway, which is not so important anymore (for testing we just unload the firewall on a developer machine). - [3] The gateway on its own shouldn't be trying to connect there. - [4] History, first implementation of Whonix was using VirtualBox and I am pretty sure, without allowing local network connections, - [5] History, ssh from host -> gateway -> into workstation. - [6] VirtualBox only: Whonix/whonix-firewall@827ea83#diff-04d68591f98e791c6fa2f3e1a407c802 - [7] VirtualBox only: Whonix/whonix-firewall@d7a9103#diff-04d68591f98e791c6fa2f3e1a407c802 - [8] No connectivity possible without it if I remember right. Reasons [1] to [7] should be no longer apply / be unimportant. Reason [8] needs to be tested. Let's see if we can make it... NON_TOR_GATEWAY="127.0.0.0-127.0.0.8" ..without breaking sys-whonix, anon-whonix, whonix-gw, whonix-ws and DispVM support.

BTW There is also a rule for `127.0.0.0-127.0.0.24`, which looks suspicious. Shouldn't that be `127.0.0.0/24`?

Iptables complains "Bad value for --dest.".

Or even `127.0.0.0/8`?

`127.0.0.0-127.0.0.8` could do.

[adrelanos]

Marek Marczykowski-Górecki:

I wonder why it is allowed there (in sys-whonix) at all - I was thinking about some Qubes 3.2 compatibility, but even there sys-whonix should not have access to clearnet updates proxy. I see there is a rule in OUTPUT chain allowing anyone to access `10.137.0.0-10.138.255.255`, which potentially include anything exposed by sys-firewall or sys-net. Fortunately there are no other services there, but that's big consolation. It's here: https://github.com/Whonix/whonix-gw-firewall/blob/dc7e553f637ebfc4e0735438b830fea22663075b/usr/bin/whonix_firewall#L150-L166 For what this section is there?

It's a very good question and should be reconsidered. Reasons that I can remember: - [1] Whonix (back then TorBOX) was originally based on this guide: https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#LocalRedirectionandAnonymizingMiddlebox - [2] To prevent connections to the local network being redirected to Tor. Such as for diagnoses purposes, i.e. ping the workstation from the gateway, which is not so important anymore (for testing we just unload the firewall on a developer machine). - [3] The gateway on its own shouldn't be trying to connect there. - [4] History, first implementation of Whonix was using VirtualBox and I am pretty sure, without allowing local network connections, - [5] History, ssh from host -> gateway -> into workstation. - [6] VirtualBox only: Whonix/whonix-firewall@827ea83#diff-04d68591f98e791c6fa2f3e1a407c802 - [7] VirtualBox only: Whonix/whonix-firewall@d7a9103#diff-04d68591f98e791c6fa2f3e1a407c802 - [8] No connectivity possible without it if I remember right. Reasons [1] to [7] should be no longer apply / be unimportant. Reason [8] needs to be tested. Let's see if we can make it... NON_TOR_GATEWAY="127.0.0.0-127.0.0.8" ..without breaking sys-whonix, anon-whonix, whonix-gw, whonix-ws and DispVM support.

BTW There is also a rule for `127.0.0.0-127.0.0.24`, which looks suspicious. Shouldn't that be `127.0.0.0/24`?

Iptables complains "Bad value for --dest.".

Or even `127.0.0.0/8`?

`127.0.0.0-127.0.0.8` could do.

[adrelanos]

And of course neither breaking R3.2 nor R4.

[adrelanos]

And of course neither breaking R3.2 nor R4.

[marmarek]

Or even 127.0.0.0/8?
127.0.0.0-127.0.0.8 could do.

127.0.0.0-127.0.0.8 is not the same as 127.0.0.0/8. The later means 127.0.0.0-127.255.255.255. I.e. the whole loopback address space.

[marmarek]

Or even 127.0.0.0/8?
127.0.0.0-127.0.0.8 could do.

127.0.0.0-127.0.0.8 is not the same as 127.0.0.0/8. The later means 127.0.0.0-127.255.255.255. I.e. the whole loopback address space.

[marmarek]

• [2] To prevent connections to the local network being redirected to Tor. Such as for diagnoses purposes, i.e. ping the workstation from the gateway, which is not so important anymore (for testing we just unload the firewall on a developer machine).

It's strange to put "ACCEPT" rules to prevent something...

I think those rules might be in some cases useful for network level configuration between gateway and "the internet" (whether it is host system, separate physical router or anything else). For example DHCP. But IMO it should be carefully chosen, instead of allowing the whole range. Also, I think it shouldn't be needed on Qubes at all - probably was migrated from VirtualBox or physical isolation case.

[marmarek]

• [2] To prevent connections to the local network being redirected to Tor. Such as for diagnoses purposes, i.e. ping the workstation from the gateway, which is not so important anymore (for testing we just unload the firewall on a developer machine).

It's strange to put "ACCEPT" rules to prevent something...

I think those rules might be in some cases useful for network level configuration between gateway and "the internet" (whether it is host system, separate physical router or anything else). For example DHCP. But IMO it should be carefully chosen, instead of allowing the whole range. Also, I think it shouldn't be needed on Qubes at all - probably was migrated from VirtualBox or physical isolation case.

[adrelanos]

Yes, a migration legacy issue.

Do we need the whole loopback address space or is 127.0.0.0-127.0.0.8 sufficient?

Previously 127.0.0.0-127.0.0.24 was my failed attempt on whole loopback address space for the sake of making this right and not having issues in corner cases.

If you recommend 127.0.0.0/8 (I am all of whole loopback space and doing things right)... How do I make the following work?

sudo iptables -t nat -A OUTPUT -m iprange --dst-range "127.0.0.0/8" -j RETURN

iptables v1.6.0: iprange: Bad value for "--dst-range" option: "127.0.0.0/8"

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

[adrelanos]

Yes, a migration legacy issue.

Do we need the whole loopback address space or is 127.0.0.0-127.0.0.8 sufficient?

Previously 127.0.0.0-127.0.0.24 was my failed attempt on whole loopback address space for the sake of making this right and not having issues in corner cases.

If you recommend 127.0.0.0/8 (I am all of whole loopback space and doing things right)... How do I make the following work?

sudo iptables -t nat -A OUTPUT -m iprange --dst-range "127.0.0.0/8" -j RETURN

iptables v1.6.0: iprange: Bad value for "--dst-range" option: "127.0.0.0/8"

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

[marmarek]

sudo iptables -t nat -A OUTPUT -m iprange --dst-range "127.0.0.0/8" -j RETURN

Just use -d instead of -m iprange --dst-range

Do we need the whole loopback address space or is 127.0.0.0-127.0.0.8 sufficient?

Depending on what exactly needs communicating there. In most cases just 127.0.0.1 is enough...

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

Right, so IP-based rules for loopback should not be needed at all.

[marmarek]

sudo iptables -t nat -A OUTPUT -m iprange --dst-range "127.0.0.0/8" -j RETURN

Just use -d instead of -m iprange --dst-range

Do we need the whole loopback address space or is 127.0.0.0-127.0.0.8 sufficient?

Depending on what exactly needs communicating there. In most cases just 127.0.0.1 is enough...

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

Right, so IP-based rules for loopback should not be needed at all.

[marmarek]

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

Right, so IP-based rules for loopback should not be needed at all.

Wait, I don't see those rules applied in my sys-whonix.

[marmarek]

I wonder if it is required anyhow since we have the following already?

$iptables_cmd -A INPUT -i lo -j ACCEPT
$iptables_cmd -A OUTPUT -o lo -j ACCEPT

Right, so IP-based rules for loopback should not be needed at all.

Wait, I don't see those rules applied in my sys-whonix.

[entr0py]

I wonder why it is allowed there (in sys-whonix) at all

Perhaps it was originally designed for Whonix Workstation's Firewall to allow communication with local machines other than Whonix Gateway. Then maybe ported to Whonix Gateway with the intent of allowing Gateway to serve as a LAN router? But if that were the case, that functionality would have to be implemented in nat/PREROUTING and not in OUTPUT. Private IP ranges were never needed for VPN on Whonix Gateway, since that was covered with VPN_SERVERS first and now, VPN_INTERFACE and user tunnel.

Just use -d instead of -m iprange --dst-range

I knew I ran into this... sigh. http://forums.whonix.org/t/me-vpn-tor/1883/3

Wait, I don't see those rules applied in my sys-whonix.

Loopback is enabled on INPUT,
but missing from OUTPUT.

[entr0py]

I wonder why it is allowed there (in sys-whonix) at all

Perhaps it was originally designed for Whonix Workstation's Firewall to allow communication with local machines other than Whonix Gateway. Then maybe ported to Whonix Gateway with the intent of allowing Gateway to serve as a LAN router? But if that were the case, that functionality would have to be implemented in nat/PREROUTING and not in OUTPUT. Private IP ranges were never needed for VPN on Whonix Gateway, since that was covered with VPN_SERVERS first and now, VPN_INTERFACE and user tunnel.

Just use -d instead of -m iprange --dst-range

I knew I ran into this... sigh. http://forums.whonix.org/t/me-vpn-tor/1883/3

Wait, I don't see those rules applied in my sys-whonix.

Loopback is enabled on INPUT,
but missing from OUTPUT.

[entr0py]

Tested with:

1. loopback interface added to OUTPUT
2. NON_TOR_GATEWAY = ""

One issue:
user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

FILTER OUTPUT
 8413   30M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
  492 32018 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 999

Is it not enough to add loopback?
Is $iptables_cmd -A OUTPUT -m owner --uid-owner tinyproxy -j ACCEPT also required?

(For Virtualbox-Whonix): Can't find if 10.0.2.0/24 is required to enable DHCP Client or if the built-in DHCP server uses another communications channel (ie loopback). Will need to test.

[entr0py]

Tested with:

1. loopback interface added to OUTPUT
2. NON_TOR_GATEWAY = ""

One issue:
user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

FILTER OUTPUT
 8413   30M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
  492 32018 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 999

Is it not enough to add loopback?
Is $iptables_cmd -A OUTPUT -m owner --uid-owner tinyproxy -j ACCEPT also required?

(For Virtualbox-Whonix): Can't find if 10.0.2.0/24 is required to enable DHCP Client or if the built-in DHCP server uses another communications channel (ie loopback). Will need to test.

[marmarek]

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

[marmarek]

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

[marmarek]

Maybe it is traffic back to the template?

[marmarek]

Maybe it is traffic back to the template?

[entr0py]

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

For non-Whonix templateVMs running dnf update:

IN= OUT=eth0 SRC=<sys-whonix IP> DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42631 DF PROTO=TCP SPT=33254 DPT=9041 WINDOW=3971 RES=0x00 ACK URGP=0

Why is 127.0.0.1 routed to eth0?
Anything to do with this nat/OUTPUT rule?:
$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"

[entr0py]

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

For non-Whonix templateVMs running dnf update:

IN= OUT=eth0 SRC=<sys-whonix IP> DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42631 DF PROTO=TCP SPT=33254 DPT=9041 WINDOW=3971 RES=0x00 ACK URGP=0

Why is 127.0.0.1 routed to eth0?
Anything to do with this nat/OUTPUT rule?:
$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"

[adrelanos]

3n7r0p1:

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

For non-Whonix templateVMs running dnf update:

IN= OUT=eth0 SRC=<sys-whonix IP> DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42631 DF PROTO=TCP SPT=33254 DPT=9041 WINDOW=3971 RES=0x00 ACK URGP=0

Why is 127.0.0.1 routed to eth0?

That's where Tor is listening.

Anything to do with this nat/OUTPUT rule?:
$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"
TRANS_PORT_GATEWAY by default is set to port 9041, so yes.

For our purposes -A OUTPUT -o lo -j ACCEPT cannot replace -A OUTPUT -m iprange --dst-range 127.0.0.0-127.0.0.8 -j RETURN.

(tinyproxy is accepting traffic as a proxy on port 8082.) When tinyproxy tries to connect to the internet, it uses the default route, which is eth0. tinyproxy does not have any options to connect to proxy (to Tor) or to use eth1. So iptables redirection is best we got.

The more I am thinking about it... I never liked tinyproxy running in sys-whonix.

Could we reasonably make a Whonix-Workstation be a ProxyVM (provides_network)? Running tinyproxy / Qubes updates proxy in a whonix-ws based UpdateVM would have some advantages:

• Whonix-Gateway firewall rules simplification
• Qubes torified updates proxy runs in Whonix-Gateway, a VM that has a "wire" to:
  • access Tor: yes
  • access clearnet: yes
    * --> not great
• Qubes torified updates proxy runs in Whonix-Workstation, a VM that has a "wire" to:
  • access Tor: yes
  • access clearnet: no
    * --> better
• a compromised tinyproxy is less likely of compromising Whonix-Gateway and sending clearnet traffic
• (low priority) Whonix-Workstation could be assigned a WiFi device and being developed to provide a torified WiFi hotspot (useful for circumvention only, not so much for anonymity)

EDIT:
Created https://phabricator.whonix.org/T725 for it.

[adrelanos]

3n7r0p1:

user: tinyproxy is generating outbound traffic on Whonix-Gateway that is not on loopback interface. ie,

I wonder what is that. Try adding -j LOG

For non-Whonix templateVMs running dnf update:

IN= OUT=eth0 SRC=<sys-whonix IP> DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42631 DF PROTO=TCP SPT=33254 DPT=9041 WINDOW=3971 RES=0x00 ACK URGP=0

Why is 127.0.0.1 routed to eth0?

That's where Tor is listening.

Anything to do with this nat/OUTPUT rule?:
$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"
TRANS_PORT_GATEWAY by default is set to port 9041, so yes.

For our purposes -A OUTPUT -o lo -j ACCEPT cannot replace -A OUTPUT -m iprange --dst-range 127.0.0.0-127.0.0.8 -j RETURN.

(tinyproxy is accepting traffic as a proxy on port 8082.) When tinyproxy tries to connect to the internet, it uses the default route, which is eth0. tinyproxy does not have any options to connect to proxy (to Tor) or to use eth1. So iptables redirection is best we got.

The more I am thinking about it... I never liked tinyproxy running in sys-whonix.

Could we reasonably make a Whonix-Workstation be a ProxyVM (provides_network)? Running tinyproxy / Qubes updates proxy in a whonix-ws based UpdateVM would have some advantages:

• Whonix-Gateway firewall rules simplification
• Qubes torified updates proxy runs in Whonix-Gateway, a VM that has a "wire" to:
  • access Tor: yes
  • access clearnet: yes
    * --> not great
• Qubes torified updates proxy runs in Whonix-Workstation, a VM that has a "wire" to:
  • access Tor: yes
  • access clearnet: no
    * --> better
• a compromised tinyproxy is less likely of compromising Whonix-Gateway and sending clearnet traffic
• (low priority) Whonix-Workstation could be assigned a WiFi device and being developed to provide a torified WiFi hotspot (useful for circumvention only, not so much for anonymity)

EDIT:
Created https://phabricator.whonix.org/T725 for it.

[adrelanos]

What do you think about Whonix/whonix-firewall@4194788? Testing that now.

• Whonix13 branch: https://github.com/Whonix/whonix-gw-firewall/blob/Whonix13/usr/bin/whonix_firewall
• master branch: https://github.com/Whonix/whonix-gw-firewall/blob/master/usr/bin/whonix_firewall (will forward port later if that works)

[adrelanos]

What do you think about Whonix/whonix-firewall@4194788? Testing that now.

• Whonix13 branch: https://github.com/Whonix/whonix-gw-firewall/blob/Whonix13/usr/bin/whonix_firewall
• master branch: https://github.com/Whonix/whonix-gw-firewall/blob/master/usr/bin/whonix_firewall (will forward port later if that works)

[adrelanos]

That Whonix 13 fix works in Qubes R3.2 and Qubes R4.

Now also forward ported to Whonix 14 / master (untested, will be tested at a later point):
Whonix/whonix-firewall@7930706

In Whonix13... The following no longer shows user's clearnet IP.

curl.anondist-orig --proxy http://10.137.255.254:8082/ https://check.torproject.org | grep Tor

That issue described in the original post in this issues was worth and and is now has been fixed from the Whonix side. If you don't see major problems with that, I'd upload an upgraded whonix-gw-firewall package to the Whonix13 jessie-proposed-updates repository so this fix can flow into Qubes R4 RC3.

The remaining issue is, that the following command is still working.

sudo -u debian-tor curl.anondist-orig --proxy http://10.137.255.254:8082/ https://check.torproject.org | grep Tor

Do you think that for compartmentalization reasons, it's still wrong, that sys-whonix can connect to a Qubes updates proxy? In dom0 sys-whonix qubes-vm-settings the box "allow connections to Updates Proxy" is disabled. Why is it working anyhow?

[adrelanos]

That Whonix 13 fix works in Qubes R3.2 and Qubes R4.

Now also forward ported to Whonix 14 / master (untested, will be tested at a later point):
Whonix/whonix-firewall@7930706

In Whonix13... The following no longer shows user's clearnet IP.

curl.anondist-orig --proxy http://10.137.255.254:8082/ https://check.torproject.org | grep Tor

That issue described in the original post in this issues was worth and and is now has been fixed from the Whonix side. If you don't see major problems with that, I'd upload an upgraded whonix-gw-firewall package to the Whonix13 jessie-proposed-updates repository so this fix can flow into Qubes R4 RC3.

The remaining issue is, that the following command is still working.

sudo -u debian-tor curl.anondist-orig --proxy http://10.137.255.254:8082/ https://check.torproject.org | grep Tor

Do you think that for compartmentalization reasons, it's still wrong, that sys-whonix can connect to a Qubes updates proxy? In dom0 sys-whonix qubes-vm-settings the box "allow connections to Updates Proxy" is disabled. Why is it working anyhow?

[marmarek]

In dom0 sys-whonix qubes-vm-settings the box "allow connections to Updates Proxy" is disabled. Why is it working anyhow?

That setting isn't working at all - firewall tab was broken in 4.0rc1. Fixed in rc2 (and current-testing repository). In new (simplified) firewall tab, this setting is gone.

Do you think that for compartmentalization reasons, it's still wrong, that sys-whonix can connect to a Qubes updates proxy?

Well, any process running as qubes-tor can access clearnet, directly. Not necessarily through updates proxy. So, I think it doesn't matter.

[marmarek]

In dom0 sys-whonix qubes-vm-settings the box "allow connections to Updates Proxy" is disabled. Why is it working anyhow?

That setting isn't working at all - firewall tab was broken in 4.0rc1. Fixed in rc2 (and current-testing repository). In new (simplified) firewall tab, this setting is gone.

Do you think that for compartmentalization reasons, it's still wrong, that sys-whonix can connect to a Qubes updates proxy?

Well, any process running as qubes-tor can access clearnet, directly. Not necessarily through updates proxy. So, I think it doesn't matter.

[adrelanos]

Can connect to clearnet, yes. But not only that, it opens a hole.

• access to another tinyproxy (attack surface) and if exploited
• access to the other UpdateVM

Still worth preventing this?

[adrelanos]

Can connect to clearnet, yes. But not only that, it opens a hole.

• access to another tinyproxy (attack surface) and if exploited
• access to the other UpdateVM

Still worth preventing this?

[marmarek]

Slightly offtopic: does apt support socks proxy (instead of http proxy)? Tinyproxy is used only because some package managers (yum/dnf for example) do not support socks.

As for allowing access to tinyproxy - in new setup, it could be accessible only from 127.0.0.1, over qrexec. But it is available over the network to support templates imported from 3.2. Maybe we should disable this legacy feature by default and have users explicitly enable it when needed?

[marmarek]

Slightly offtopic: does apt support socks proxy (instead of http proxy)? Tinyproxy is used only because some package managers (yum/dnf for example) do not support socks.

As for allowing access to tinyproxy - in new setup, it could be accessible only from 127.0.0.1, over qrexec. But it is available over the network to support templates imported from 3.2. Maybe we should disable this legacy feature by default and have users explicitly enable it when needed?

[adrelanos]

apt-get doesn't support socks unfortunately. That would solve some issues. Search engine results may claim differently, but grep -ied apt-get's source code for socks and it's not there.

I suggest to disable Qubes updates proxy over network by default once Qubes R3.2 gets deprecated, i.e. when everyone moved to R4?

Meanwhile, how can users manually disable it (if possible)? Asking, because we'd certainly add this to Whonix security guide.

---

Updated whonix-gw-firewall package uploaded to jessie-proposed-updates.

[adrelanos]

apt-get doesn't support socks unfortunately. That would solve some issues. Search engine results may claim differently, but grep -ied apt-get's source code for socks and it's not there.

I suggest to disable Qubes updates proxy over network by default once Qubes R3.2 gets deprecated, i.e. when everyone moved to R4?

Meanwhile, how can users manually disable it (if possible)? Asking, because we'd certainly add this to Whonix security guide.

---

Updated whonix-gw-firewall package uploaded to jessie-proposed-updates.

[andrewdavidwong]

I suggest to disable Qubes updates proxy over network by default once Qubes R3.2 gets deprecated, i.e. when everyone moved to R4?

According to our support schedule, this will be one year (due to extended support specifically for R3.2) after the release of R4.0 stable.

[andrewdavidwong]

I suggest to disable Qubes updates proxy over network by default once Qubes R3.2 gets deprecated, i.e. when everyone moved to R4?

According to our support schedule, this will be one year (due to extended support specifically for R3.2) after the release of R4.0 stable.

[marmarek]

I don't think support period for Qubes 3.2 should affect this decision. It is about default configuration of Qubes 4.0, and how to support VMs (to be precise: TemplateVMs) imported from Qubes 3.2.
I'm leaning to disable updates proxy over the network by default, then adjust qvm-backup-restore to enable it for templates imported from 3.2. Or issue a warning that it should be changed by the user (for example just for upgrading the template).

[marmarek]

I don't think support period for Qubes 3.2 should affect this decision. It is about default configuration of Qubes 4.0, and how to support VMs (to be precise: TemplateVMs) imported from Qubes 3.2.
I'm leaning to disable updates proxy over the network by default, then adjust qvm-backup-restore to enable it for templates imported from 3.2. Or issue a warning that it should be changed by the user (for example just for upgrading the template).

[adrelanos]

Sounds perfect!

[adrelanos]

Sounds perfect!

[adrelanos]

Nothing more to do here. Follow up tasks created.

• #3285
• #3286

[adrelanos]

Nothing more to do here. Follow up tasks created.

• #3285
• #3286