Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make whonix templates happy to use cacher #12

Closed
tlaurion opened this issue Aug 20, 2022 · 3 comments
Closed

Make whonix templates happy to use cacher #12

tlaurion opened this issue Aug 20, 2022 · 3 comments

Comments

@tlaurion
Copy link
Contributor

tlaurion commented Aug 20, 2022 •
edited
Loading

1- The following userinfo.html would need to be put under /usr/lib/apt-cacher-ng/userinfo.htmlunder cloned template-cacher so that whonix templates proxy check detects a tor enabled local proxy (otherwise fails):

<!DOCTYPE html>
<html lang="en"><html>

<head>
<title>403 Filtered</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="application-name" content="tor proxy"/>
</head>

</html>

(As stated under #10 (comment) point 1)
@tlaurion tlaurion changed the title Make whonix happy to use cacher Make whonix tamplates happy to use cacher Aug 20, 2022
@tlaurion tlaurion changed the title Make whonix tamplates happy to use cacher Make whonix templates happy to use cacher Aug 20, 2022
@unman
Copy link
Owner

unman commented Aug 21, 2022

I had replied to this proposal by email, but gh doesnt show the comment.(?)
I've pasted it here:

That cant be the right solution.

We don't want cacher to always return "tor proxy", since it's in the
users hands whether it routes through Tor or not.
In fact returning that is completely unconnected to whether routing is
via Tor. (The case is different in Whonix where that file can be
included and Tor access is supposedly guaranteed.)

I suggest that cacher set:
qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
qubes.UpdatesProxy * @tag:whonix-updatevm @AnyVM deny
qubes.UpdatesProxy * @type:TemplateVM @default allow target=cacher

IF the current target for @type:TemplateVM is target=sys-whonix, then
the netvm for cacher can be set to sys-whonix. That way Whonix users get
caching for all templates EXCEPT the whonix ones.
This wont capture every case, because users may already be using a
tinyproxy connected to sys-whonix, or using an alternative Tor proxy:
I'm not clear how far we want to dig in to those possibilities.

If the option to update over Tor is enabled, and cacher is already
installed and the default target, then there is no need to adjust the
policy rules. Just set the cacher netvm to sys-whonix.

If we do this then the rewrite option should not be applied in Whonix
templates - is there any grain we can access specific to Whonix?

@tlaurion
Copy link
Contributor Author

tlaurion commented Aug 21, 2022 •
edited
Loading

I suggest that cacher set:
qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
qubes.UpdatesProxy * @tag:whonix-updatevm @AnyVM deny
qubes.UpdatesProxy * @type:TemplateVM @default allow target=cacher

I see that this was implemented under:
0165e76#diff-43c52f790288fc13c3c02d23567eb176a98406a79d67faef95cfde777d6539eeR7-R12

@unman said:

If the option to update over Tor is enabled, and cacher is already
installed and the default target, then there is no need to adjust the
policy rules. Just set the cacher netvm to sys-whonix.

IF the current target for @type:TemplateVM is target=sys-whonix, then
the netvm for cacher can be set to sys-whonix. That way Whonix users get
caching for all templates EXCEPT the whonix ones.

Right. But Whonix templates, being based on debian-11, will still result as of now in the same debian package being downloaded at least 3x minimum, even if using cacher:

  • everything debian cloned templates downloaded packages through cacher (good)
  • whonix-gw and additional specialized clones (meh)
  • whonix-ws and additional specialized clones (meh)

As previously said:

  • if cacher sees, prior of install, that sys-whonix is currently configured as the system defined update proxy, then cacher could have it's template-cacher simply overwrites userinfo.html to trick Whonix templates into thinking they are using a tor enabled update proxy without further change.
    • Whonix templates being already configured to download updates through tor in that case, and if the update proxy doesn't permit tor package download, the update process will fail, where apt will not be able to download packages from tor URLs.
  • Otherwise, @adrelanos gave a hint into deactivating the tor proxy check under whonix templates (would give the same result as above suggestion: package download failing if update proxy not supporting tor):

To use the override for testing, torified_check=true could be set in /etc/uwt.d/25_cacher.conf. Untested but I don't see why it wouldn't work.

To me the two solutions above are functionally equivalent. One effectively lying that the proxy supports tor (@unman is right, this would be misleading, but would not require any change applied to whonix templates), where the second option would require cacher to modify Whonix templates to deactivate the proxy check. Both would fail if the proxy doesn't effectively supports tor to download Whonix updates through tor.

On that @unman asked:

If we do this then the rewrite option should not be applied in Whonix templates - is there any grain we can access specific to Whonix?

@unman @adrelanos: I am not sure how to properly have both cacher and whonix coexist and having their packages cached through cacher without cacher hacking current Whonix template proxy check, one way or the other above.

I still see a big advantage for everyone waiting for QubesOS/qubes-issues#1957 (top 10 commented still unresolved issue) to download once on limited bandwidth to have their system up to date in precarious environments/metered internet connections/slow internet connection.

@tlaurion
Copy link
Contributor Author

tlaurion commented Aug 29, 2022 •
edited
Loading

Ideal solution would be Whonix templates actually testing for tor addresses reachability instead of relaying on crafted tinyproxy proxy response/apt-cacher response to advertise tor compliance. The test should verify tor network availibility.

This is detailed #10 (comment)

I agree with @unman, it should not be cacher's responsibility to hack into Whonix templates for them to bypass their tor proxy checks or to fake its own apt-cacher-ng userinfo.html to comply with expected hardcoded tinyproxy responses (hacked into Whonix-gw tinyproxy's webpage modification as this issue suggests to do, to replicate Whonix-gw's sys-whonix behavior).

Whonix templates should functionally test for tor addresses reachability instead.

Closing. This discussion should continue under #10 or wherever @adrelanos points to under #10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tlaurion @unman