remove tinyproxy from Whonix-Gateway (sys-whonix) and make Whonix Templates networked by default with Net qube set to sys-whonix

[adrelanos]

I am suggesting to remove tinyproxy from Whonix-Gateway (sys-whonix) and make Whonix Templates networked by default with Net qube set to sys-whonix.

motivation for this change suggestion:

• The current implementation is still basically mostly as implemented by nrgaway many years ago. nrgaway is no longer active. No co-maintenance / help / resources / hyper-vigilant auditing eyes available to keep maintaining it.
• I don't like the extra complexity of having Qubes UpdatesProxy specific firewall rules in Whonix-Gateway firewall. (here) (Was fixed in sys-whonix should use tinyproxy using socks instead of transparent proxying #8398.)
• It makes leak testing more complicated.
• Requires complex torified UpdatesProxy check.
• Primarily goal of Whonix is to route all traffic over Tor, leakproofness. Therefore any complexity / exceptions in its networking configuration is to be avoided.
• Now a more complex solution is suggested on top of the current complexity. (WiP cacher-whonix tlaurion/shaker#1)
• Non-ideal stream isolation, see: Qubes UpdatesProxy Stream Isolation

advantages of this change would be:

• Better leakproofness.
• Simplifies Whonix-Gateway firewall.
• Improves Qubes-Whonix Templates stream isolation.
• Makes Qubes-Whonix more similar to Non-Qubes-Whonix and hence easier to audit and maintain.

disadvantages if this change is implemented:

• Qubes-Whonix Templates being networked by default.

Why do I as maintainer of Qubes-Whonix make this ticket?

• I am not sure I'd have the authority to decide to make this change. Making a Qubes Template networked by default might be perceived as quite a conceptual level change. And orchestrating this change should be discussed beforehand for sure anyhow.

Other alternatives?

• Getting tinyproxy out of sys-whonix somehow... But how would that be implemented? Maybe a third VM but the effort to maintain that would be too high on my side. Perhaps Qubes would like to maintain a standalone tinyproxy / UpdatesProxy / cacher VM? Created,

• Create sys-ops-whonix VM for Enhanced Security and Isolation in Qubes-Whonix #9294

for it.

[nyxnor]

https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy

Updates proxy is a service which allows access only from package managers. This is meant to mitigate user errors (like using browser in the template)

I would like to add that the most justifiable argument about running browser in the template does not apply to Whonix

• Workstation templates blocks the Tor Browser from Starting
• Gateway does not have user applications

[Minimalist73]

I have a bunch of StandaloneVM with no netvm that I update using the whonix-updatevm tag. If sys-whonix remove tinyproxy what are my options to update those? Will cacher-whonix do the work or do I have to switch the netvm to sys-whonix (making them network accessible again without firewall rules)?

[marmarek]

The updates proxy has one additional advantage not listed above: it isolates template's TCP/IP stack. With updates proxy instead of normal networking, even compromised sys-whonix cannot send crafted IP packets to any template. It can only interact with package manager that uses updates proxy explicitly, and only at HTTP proxy protocol level (which in most cases will be just CONNECT request + TLS session anyway).
Given firewall in Whonix forbids incoming packets anyway (similar to default Qubes firewall too), and that Whonix VMs make less sense for offline VMs (if you're connecting your TemplateBasedVM to the network anyway, keeping template isolated has less benefits), I don't think that's critical property. But I'd like to spell this out explicitly, so you are aware that such change will make Whonix templates a bit less isolated than other templates.

As for @Minimalist73 comment - that's a valid question. Dropping tinyproxy (being target of qubes.UpdatesProxy service) at all, will make it unable to function as updates proxy for any VM (be them templates or not), not just Whonix templates. This will also force us to drop option to route all updates (not only Whonix ones) over sys-whonix.
If I understand correctly, the most problematic part is actually the template side (torified updates check, firewall, apt configuration etc), not just running tinyproxy, right? If you are determined to switch Qubes-Whonix templates to update using normal network connection to sys-whonix, would it be okay to keep tinyproxy running anyway?

[tlaurion]

For clarity, my motivations into creating tlaurion/shaker#1 (totally imperfect as of now, needs guidance) were:

• replace tinyproxy with apt-cacher-ng on sys-whonix so that all templates can benefit of packages and repository cache being downloaded once for all templates/reducing bandwidth requirement for cloned templates, templates and standalones, including whonix's
• mitigate current whonix templates update proxy check refusing to talk over apt-cacher-ng (which was the main issue not being able to use @unman's cacher out of the box), which would require whonix-gw tinyproxy' modification to disclose that for apt-cacher-ng to mimic tinyproxy's HTML disclosure that it enforces tor. It is currently impossible to use @unman' cacher with whonix templates as per those checks today, which are tied to sys-whonix's customized tinyproxy disclosed HTML page when accessed directly through 127.0.0.1:8082
• enforcing better policies on what can be accessed through update proxy. As of today, tinyproxy permits to access the whole internet when accessed through 127.0.0.1, not only repositories. Anything can talk through the whole internet if the proxy address is known. atp-cacher-ng can enforce those policies and does so pretty well.

The idea behind this is that debian-12 and whonix are targeting some of the same updates packages (same debian repositories) as of today, and ideally they should all be downloaded once and the cached packages used per templates when requesting their updates. Therefore:

• sys-whonix seemed the right place to have apt-cacher-ng deployed as drop in replacement for tinyproxy so all templates can download once and reuse repository definitions and packages (fedora repositories refresh are a couple of hundred megabytes, not fit for multiple template clones. Less for Debian, but still not good for users having constraints on internet bandwidth. Saying to users to specialize their templates while not enforcing caching is a real problem, leading to non-updated templates and those users not applying updates when available, some of which will not even know they have updates available since available updates are only showing when repositories package lists are downloaded which requires a lot of bandwidth if no cacher is deployed...)
• whonix templates update proxy checks denying proxy usage if tor isn't forced seemed logic and not needed to be changed, but apt-cacher-ng replacing tinyproxy as a package proxy seemed the way to go limiting changes.

I am not convinced that removing whonix update proxy is a good idea, most of the Qubes users I'm aware of are actually ticking sys-whonix to be used as the update proxy when deploying whonix at qubes installation.

I am not currently confortable pushing users to have templates accessing directly the internet is a good idea either, and questioned that recommendation in the past, which made its way in official documentation, but with proper warnings.

To me the ideal would be:

• having an update proxy that only permits to download updates for defined repository definitions (and cache them) and have users carefully choose direct internet access in templates only as last resort and or in standalones.
• have some back porting of extrepo and extrepo-offline package in all templates so that users can install package repositories and keys easily, for what they intend to use, not blocking their use cases, and not have to follow random guides on the internet; reusing the work done by extrepo project to do exactly that: add curated package repositories to be used instantly (@marmarek, please check that project).
• have qubes apply a post deployment script if cacher is deployed to transform repository URLs to be compliant with apt-cacher-ng format so that all URLs communicate into http to the proxy, and then the proxy communicating through tor or https from the proxy to the internet, caching packages and repositories package lists etc only.

Those are suggestions. I was able to bypass whonix templates limitation without modifying the templates directly (respecting whonix for update proxy check) but having unman's cacher modified so that apt-cacher-ng fakes its tor compliance by crafting a userinfo.html file so that whonix update proxy checks are happy seeing a tor enabled cache proxy even if it could be a lie. This was refused by both @adrelanos and @unman as a proper implementation, which I agree is not ideal. Whonix templates would think that cacher is tor enforcing in all cases, even it cacher was not using sys-whonix to torrify the updates; that is a dirty hack and not ideal. Therefore the only foreseen good implementation woukd be to have sys-whonix implement cacher, modified to fit whonix. Therefore: a cacher-whonix salt shaker recipe. This is a search for a better implementation, not a request to drop what is already working for most users using sys-whonix as an update proxy, guaranteeing torrified updates.

Let's be clear here, tlaurion/shaker#1 is absolutely not ready for produxtion, but shows how that could work as salt recipes to enforce apt-cacher-ng under sys-whonix (whonix-gw) as a tinyproxy replacement.

In short:

• sys-whonix could be used as global update proxy as today, but caching packages once and be reused by all templates. An update proxy is desired for a really long time
• extrepo could be used to deploy new repositories and have qubes apply post-script to modify repository URLs to comply with apt-cacher-ng after their deployments. That is a separate issue

Linked to:

• [Contribution] qubes-updates-cache #1957 long term desired implementation, ideally by default at install.
• impossibility to use cacher for whonix templates at Cacher incompatible with sys-whonix (updates fail for whonix-ws and whonix-gw) unman/shaker#10
• Discussions about apt-cacher-ng neglecting whonix today because of actual design of whonix templates, current and future cacher goals and implementation: https://forum.qubes-os.org/t/issues-with-apt-cacher-ng/13515

[unman]

Discussion of tlaurion/shaker#1 is being spread over a number of places. For the record here, I think this proposal is not a good one. If user has been using a clear cache and then decides to switch all updates to Tor, then they lose all benefit of already cached packages. Similarly for the reverse. If they have a single cache, then changing to/from update over Tor would be as simple as changing the netvm of the caching proxy. I know users who have wanted to update *some* templates over Tor and some not. They clone the caching proxy (thus retaining already cached packages) and change the netvm. Afterwards the caches diverge. The issue with Whonix checks is this - Whonix uses a check based on a parameter that is set within Whonix. That makes sense. It doesn't make sense to use that same parameter in a distinct caching proxy *if the parameter is set by the user*. I have already indicated that it is possible to automatically set a parameter based on an onion check. with the downside that if the proxy is in clear, there is leakage of DNS for an onion address. I think this is of little importance given the fact that Tor/Whonix are easily fingerprinted in any case. As to the current proposal, I appreciate the desire to avoid complexity, but would not want to see some templates online by default.

[adrelanos]

Thank you for your replies! Lots of good arguments!
Lots of things to consider. Will take a while for me to parse this and get back to this.
Meanwhile, this is for sure a change to take slow. Actually, the probability that this will be done is now a lot lower than I originally thought when creating this ticket.

@unman:

I think this is of little importance given the fact that Tor/Whonix are easily fingerprinted in any case.

Which fingerprinting vector are you referring to?

[tlaurion]

I think this is of little importance given the fact that Tor/Whonix are easily fingerprinted in any case.

Which fingerprinting vector are you referring to?

I guess @unman was talking about tor being "fingerprint-able" since using tor (observable by ISP) or poking a .onion DNS address shows the same "I'm trying to access a .onion over tor / i'm using tor" network observable behavior (fingerprinting) on the wire. This is an accepted risk of using tor, after all, on which I agree with @unman that:

The issue with Whonix checks is this - Whonix uses a check based on a
parameter that is set within Whonix. That makes sense.
It doesn't make sense to use that same parameter in a distinct caching
proxy if the parameter is set by the user. I have already indicated
that it is possible to automatically set a parameter based on an onion
check. with the downside that if the proxy is in clear, there is leakage
of DNS for an onion address. I think this is of little importance given
the fact that Tor/Whonix are easily fingerprinted in any case.

I think I already explained the motivations of having apt-cacher-ng. Also why it would be "normal" to have it under sys-whonix if whonix is deployed. And even more if sys-whonix is the update proxy defined at install.

I also expressed why I think removing tinyproxy in whonix-gw (sys-whonix) without replacing it by something better doesn't seem like a good idea. Forcing users to give whole internet access to Templates should be a no go but as last resort. Actually, I went in the opposite direction testing @unman's cacher, adding update proxy policy rule so that any vm is enforced in using apt-cacher-ng with templates modified repo URLs, which permits to download packages once (and test in dispvm or app qubes) prior of choosing to actually reuse cached packages to be installed in template if they fitted the bill (having users understand that installing packages in app qube is another "problem" that is already documented upstream and should not be mixed. It is not a bug, but a feature).

What would still be needed on top of cacher is a wrapper of some sorts to change repo definitions URLs as soon as they are added (probably per cacher deployment) to be apt-cacher-ng compliant prior to the users trying to use those repo definitions not being transformed to be apt-cacher-ng compliant and failing. More thinking is needed to fix that. It could be a directory watching deamon (inotifywait), triggered when the repo directory files are modified and applying a sed to transform all current https URLs to use apt-cacher-ng as part of the cacher (or sys-whonix, or both). @unman, please check inotifywait. If that wrapper was deployed in templates per cacher, the whole problem of users adding repos after cacher deployment would be dealt with and become a non-issue, and would not require qubes updater to be modified either.

I will follow the discussions here and wherever I'm tagged directly (@tlaurion on GitHub and @insurgo over Qubes forum), and if there is interest, will go back to tweaking/testing tlaurion/shaker#1 to implement what is decided to be best.

I continue to believe that with the help of extrepo and extrepo-offline (backported if needed @marmarek), we would soon enough remove the most problematic issue of adding repo+keys and install user desired software in templates without the need of opening the templates to the whole internet, nor to follow non-understood bash code snippets to install additional software.
That was the conclusion of https://forum.qubes-os.org/t/curl-proxy-wget-proxy-scripts-in-templates-so-users-can-add-gpg-distro-keys-linked-to-added-external-repositories/ thread.

With cacher, extrepo + extrepo-offilne and repo directory watchers (inotifywait script in templates per cacher enablement), users would be able to add needed software more easily without needing to open templates to the whole internet (UX work around that and GUI package installer is a parallel discussion).

[adrelanos]

enforcing better policies on what can be accessed through update proxy. As of today, tinyproxy permits to access the whole internet when accessed through 127.0.0.1, not only repositories. Anything can talk through the whole internet if the proxy address is known. atp-cacher-ng can enforce those policies and does so pretty well.

I think this too difficult and therefore maybe best not done. Other traffic through UpdatesProxy: tb-updater / flatpak. In any case, this seems unrelated to this ticket and should go into a dedicated ticket should you wish to further this feature request. Maybe there was even already a ticket for this in the past.

have some back porting of extrepo and extrepo-offline package in all templates

Seems also to belong into a different ticket.

---

For the record only (and updated original ticket), non-networked Qubes-Whonix tempaltes is leading to a non-ideal stream isolation for Qubes UpdatesProxy. Details documented here:
Qubes UpdatesProxy Stream Isolation

Despite this issue, it's probably best to keep Qubes-Whonix Templates non-networked except through the standard Qubes UpdatesProxy mechanism the same way this is implemented for all Qubes Templates. Therefore I am closing this ticket in favor of:

• Create sys-ops-whonix VM for Enhanced Security and Isolation in Qubes-Whonix #9294