block tinyproxy requests to 127.0.0.1, 10.137.255.254

[3nprob]

Changes

Migrates existing qubes-whonix-specific tinyproxy filter from qubes-core-agent-linux to qubes-whonix. It seems that this belongs better here.

Note that this is not a security measure as requests to other loopback addresses are still allowed. this filter is an accommodation for whonix torification detection.

The filter file is renamed from /etc/tinyproxy/updates-blacklist to /etc/tinyproxy/updates-blocklist in order to ensure conflict-free upgrades with regards to package ownership of those files.

• tinyproxy may return empty output (instead of error page) when asked for invalid address QubesOS/qubes-issues#1482
• chore: remove whonix-specific updates-proxy filter from non-whonix templates QubesOS/qubes-core-agent-linux#565

Mandatory Checklist

• Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

Optional Checklist

The following items are optional but might be requested in certain cases.

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[marmarek]

I'm not sure how append-once works, but looking at its usage it may not work for updating the added block, or will add it out of order.

Generally, IMO this cleanup has more risk of breaking all whonix updates (for example depending on order of those updates landing in repo or being installed) than it's worth it.

[3nprob]

I'm not sure how append-once works, but looking at its usage it may not work for updating the added block, or will add it out of order.

Generally, IMO this cleanup has more risk of breaking all whonix updates (for example depending on order of those updates landing in repo or being installed) than it's worth it.

So the idea is that it doesn't matter (the files are identical but at different paths). I do think it makes a lot more sense for the qubes-whonix-specific config to not be part of the base config of every dist by qubes-core-agent-linux...

Ideally the tinyproxy configs would be modularized (though tinyproxy doesn't support either config dirs or imports so that seems like a no-go) or split and the appropriate one used depending on runtime (and here's where I also doubt if it's worth the squeeze)

[3nprob]

If this seems like it could be breaking in any way (users who have manually changed the filter file), maybe it could be considered for whonix 18 (trixie)?

[marmarek]

The problem is, if qubes update lands first, then updates-blacklist file is gone -> whonix updates broken. If whonix update lands first, then you end up with two Filter directives, not sure which one will get used (or maybe even it's a config error?).
And add dpkg's config handling to the mix, which may cause the old Filter directive not being removed on update if the file got modified (and it did - in this very package).
I'm sure I missed some failure modes.
Breaking updates is quite serious issue, as you cannot deliver a fix via an update...

maybe it could be considered for whonix 18 (trixie)?

That's a question to @adrelanos , but upgrade needs to work anyway - distribution upgrades are a thing.

[3nprob]

So the redundant Filter directives in the case of this PR shouldn't be an issue AFAICT - I did some local testing with various permutations without issue. So I believe it should be OK in that order, and keep working even if core-agent stays as-is.

Agreed the core-agent update might need some more thought. (Hence putting it in draft and marking it as blocked by the change here)

[adrelanos]

I'm not sure how append-once works,

Documented just now:
https://www.kicksecure.com/wiki/Append-once

[3nprob]

@adrelanos did you have a chance to look at this? :)

[adrelanos]

Due to...

Generally, IMO this cleanup has more risk of breaking all whonix updates (for example depending on order of those updates landing in repo or being installed) than it's worth it.

and because I don't see the benefit, didn't consider.

I don't see any bug that needs fixing.

The best you could do is probably help Qubes to obsolete tinyproxy.

[3nprob]

Due to...

Generally, IMO this cleanup has more risk of breaking all whonix updates (for example depending on order of those updates landing in repo or being installed) than it's worth it.

and because I don't see the benefit, didn't consider.

I don't see any bug that needs fixing.

Thanks for the feedback. I guess to me, it is a bug that with default configuration, attempting to use a localhost repo (locally hosted or via a separate proxy) will be intercepted by the proxy and blocked.

The best you could do is probably help Qubes to obsolete tinyproxy.

Oh, was not aware this was the intention but sounds promising.

Any pointers to what should be done appreciated, or maybe I figure something out.

[adrelanos]

I cannot find these discussions anymore. Created

• replace tinyproxy with something more secure for better security QubesOS/qubes-issues#10022

for it.

[3nprob]

Without having looked deep enough yet, I think tinyproxy currently serves two purposes?
Below is maybe not fully correct.

1. Local proxy running in qubes to access their updatevm
   • This is AIUI corresponding to non-Whonix qubes use of socat which was being replaced with qubes.ConnectTCP qrexec proxy in https://github.com/QubesOS/qubes-core-agent-linux/pull/495/files
     • This seems straightforward to replace the same way
     • Support TCP socket qrexec services QubesOS/qubes-issues#9037
2. The proxy running inside the UpdateVM (which sys-whonix acts as)
   • Less clear about if there is an intended replacement here
     • consolidated caching in the updatevm would be nice. getting a cache by running apt-cacher-ng or squid could do that but may be error-prone and demanding for general use in default setup
     • currently, all outbound networking is allowed from the proxy. would also be nice to restrict it to known repos (though i guess that would be breaking). apt-cacher-ng also relevant there.
     • on the other hand, also possible to forego http features and simplify things by making it a "stupid" tcp proxy or even handle it on L3/4 with nftables
     • or is it fine to keep tinyproxy on this side while replacing the other?