Improve Onion Service Usability by Script / GUI

Development
9

B) config files

Seems more appropriate in case of Whonix sacrificing a bit usability for better onion service private key protection.

10

@patrick sorry to ping but can the gateway now the workstation qube ip?

I copied the code from anon-gw-anonymizer-config/anon-auth-autogen at c0d9e66dd3d5d84bdce9caeab6d4c1c5624dbfe0 · Whonix/anon-gw-anonymizer-config · GitHub which I thought was supposed to be ran on the GW according to http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_3:_Configure_Onion_Services_Authentication, but the qube ip read would be from the GW, not from the WS.

Edit: I guess not because of multiple GWs and WSs having to be configured per vm way to find out the name of gateway from inside the VM - qubesdb-read /qubes-gateway-name · Issue #4117 · QubesOS/qubes-issues · GitHub and Multiple Whonix-Workstation ™

do it is not possible to get the WS qube IP from the qubesdb-read command, I couldn’t find a way. What remains is using a variable on whonix.conf to set the WS IP, but this also has to be done manually or the user would need to specify the target every time.

Specifying a different domain is only available on dom0

qubesdb-read -d anon-whonix /qubes-ip

but this does not guarantee that the user is using the anon-whonix as the WS.

Well, seems target for qube-whonix is manual job as in http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_2:_Edit_Tor_Configuration:
on WS run:

qubesdb-read /qubes-ip

on GW run:

onionjuggler-cli --activate -s web -p 80,{ws_qube_ip}:80

on WS run (target_port=80):

onionjuggler-cli --web -s web -p 80 -n --no-check-service -w /var/www/folder

Now possible to set the WS qube IP address on /etc/onionjuggler/conf.d/*.conf:

tor_hiddenserviceport_target_addr=WS-QUBE-IP-ADDR

But the command line target if specified will overwrite this option.
so after setting the above configuration option, it is possible to create services for the WS on the GW with:

onionjuggler-cli --activate -s web -p 80

and if running qubes whonix and the option tor_hiddenserviceport_target_addr is still 127.0.0.1 and the service is not for the gateway, it will fail with an informative error message to set the WS qube ip address on the configuration or obviously possible to specify on the command line.

1 Like
11

I don’t know if there’s a reliable/sane way for that.

Only that part of most of anon-auth-autogen? Btw most of anon-auth-autogen would be good if upstreamed, different name, and not part of anon-gw-anonymizer-config.

Indeed.

Also I guess if we had ⚓ T947 Qubes-Whonix eth1 static networking that might help.

I doubt that exists.

1 Like
12

Yes, I only copied that part (but removed, as it was not working as explained above because it reads the GW ip, not the WS), the rest, onionjuggler-cli --auth-server and --auth-client already had, except installing from a file.

So onionjuggler-cli will eventually substitute that script if implemented. So upstreaming onionjuggler-cli later would be better.

1 Like
13

The setup currently is very easy. Should opening firewall ports be automated to /usr/local/etc/whonix_firewall.d/45_onionjuggler.conf?

WS

Configure web service:

sudo onionjuggler-cli-web --on -s <MY_SITE> --folder <SITE_FOLDER> -p 80

Allow port from the firewall:

sudo mkdir -p /usr/local/etc/whonix_firewall.d
echo "EXTERNAL_OPEN_PORTS+=\" 80 \"" | sudo tee -a /usr/local/etc/whonix_firewall.d/50_user.conf
sudo whonix_firewall

GW

Configure service:

sudo onionjuggler-cli --activate -s <MY_SITE> -p "80 <WS_QUBE_IP>"
1 Like
14

Yes, sure would be nice. Bonus points for transparently pointing out what systemd changes onionjuggler is applying (where, what kind of changes).

I don’t think there is any convention in Debian or elsewhere how applications that create configs for users should operate as per configuration file location such as in /etc or /var and naming.

45_onionjuggler.conf looks good.

Not sure about the numbering:
config files numbering convention

15

For users or developers?

  • If for users, then I’d print an info about the whonix firewall port that was opened.
  • if for developers, then it would only be on the docs.

Not sure about the numbering:

Should it use 40 like: /usr/local/etc/torrc.d/40_tor_control_panel.conf does?

1 Like
16

I want to print the ws ip and the port allowed, how can I find the WS ip inside the WS for Non-Qubes-Whonix?

for qubes-whonix is qubesdb-read /qubes-ip, but for non-whonix I don’t know how to find its ip.

1 Like
17

For users. Point out the path to the config file too? I think it would be a good idea.

The rationale behind this has been documented just now:

Good comparison. Sounds good.

Probably required parsing ifconfig but requires root afaik but I guess that is available in this situation anyhow. There’s hopefully a number of helpful posts on:

bash how to find out local IP

on stackexchange etc. I found some answers but I never liked the parsing of ifconfig. Was hoping there’s a nicer API or tool for this.

1 Like
18

Ok.
But I’d rather users not change the config file manually because it may break the script.
Anyway, I can document this.
Also, there is a simple way to see configuration files manages by onionjuggler:

$ onionjuggler-cli --getconf

openssl_cmd="openssl"
webserver="nginx"
webserver_conf="/etc/nginx/sites-enabled"
website_dir="/var/www"
vanguards_commit="10942de93f6578f8303f60014f34de2fca345545"
tor_daemon="tor@default"
tor_user="debian-tor"
tor_conf_dir="/usr/local/etc/torrc.d"
tor_conf_user_group="root:root"
tor_conf="/usr/local/etc/torrc.d/40_onionjuggler.conf"
tor_data_dir="/var/lib/tor"
tor_data_dir_services="/var/lib/tor/services"
tor_data_dir_auth="/var/lib/tor/authdir"
tor_control_port="9051"
tor_backup_dir="/var/lib/onionjuggler/backup"

missing the variable for the whonix_firewall conf, but it might be added later because for now it is default to use /usr/local/etc/wonix_firewall.d/40_onionjuggler.conf

I just asked because I thought there was a whonix way.

ip a | grep "inet .* eth0$" | sed "s/.*inet //;s/\/32.*//"

ip r get 1.1.1.1 | grep 1.1.1.1 | sed "s/.*src //;s/ uid .*//"

sudo ifconfig | sed -n "/eth0/,/inet/p" | grep inet| sed "s/.*inet //;s/  netmask .*//"
1 Like
19

Yes. Most users shouldn’t do it. Not supposed to be manually changed. Just useful in case there’s ever a bug then advanced users already get the idea to look into that file and report it.

20

This was done where I could catch on recent commits.

Auth scripts now have some activation options

  • import file (servers/clients)
  • import config (servers/clients)
  • import onion+priv key (clients)
  • import pub key (servers)
  • generate keys (servers/clients)

These options are almost the same, it is just to facilitate for the user, maybe he has the config as a file, or maybe the config is on the clipboard, or maybe the client just sends the server the his pub key or vice verse, or maybe a new key needs to be generated and automatically imported.

Another thing missing but it is a non-blocker for whonix, is removing invalid auth files if tor fails to parse it improve verify_config_tor() parser and safe_edit() file mangement · Issue #66 · nyxnor/onionjuggler · GitHub

Missing separate debian packages, work is being done.

1 Like
21

Does Whonix have any example of a Source with multiple Packages that have man pages that need to be installed per package?

Currently, it is installing all man pages for each package. Didn’t find anything searching the web. Just trying to understand how other packages does this.

Edit:
NVM
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#manpages

1 Like
22

Please add manpages here using the same format:

These I will later use to create the “real” (roff) format using genmkfile manpages.

The Debian packaging “magic” is here:

23

OnionJuggler is 1 source and multiple packages.
Using:

override_dh_installman:
	dh_installman $(CURDIR)/auto-generated-man-pages/*

doesn’t work because all manual pages will be installed to all packages.

Each package need a debian/PACKAGE_NAME.manpages to install the correct man pages per package.

Anyway, there is already man/ and auto-generated-man-pages/ directories, but it is made by ./configure.sh -m (create man pages).

Does it affect your build? Do you generate man pages for every build or just build the packages?

Because if just building and the man pages are already updated, then no extra effort.

1 Like
24

Im remembering now I already tried to port my manpage generation from pandoc to ronn, but it didn’t work. Tried again, don’t know how to fix.

The manpages are pretty dense on information, so I need to keep them organized and easy to read, and with pandoc is working. If you can port the manuals to ronn without drawbacks then that is ok.

1 Like
25

Ah. Yeah. For multiple packages…

https://manpages.debian.org/dh_installman

FILES

debian/package.manpages

Lists man pages to be installed.

  • debian/package1.manpages
  • debian/package2.manpages

File content would be only the path to the autogenerated man pages.

Example:

The ronn / format isn’t too important as long as the final package is alright.

26

genmkfile manpages is manual when a man page source file was updated (ronn) and the roff needs to be updated. If I remember to do that. Doesn’t seem too useful to automate that during the build process. Would have to check contents are reproducible / deterministic.

Otherwise the build process only automatically takes the files from the autogenerated folder.

1 Like
27

So you don’t need to worry about manpages. I generate them with a script before pushing (most of the time hehe).

Just fixing lintian warnings and it is pretty much ready for review and trying to break the scripts.

GW should install onionjuggler-cli onionjuggler-cli-auth
WS should install onionjuggler-cli-web

GW or WS can install onionjuggler-tui, it is quite handy, just not “beautiful” because it has to be versatile to check which onionjuggler-cli commands it has.

GW

sudo apt install onionjuggler-cli onionjuggler-cli-auth onionjuggler-tui

WS

sudo apt install onionjuggler-cli-web onionjuggler-tui
1 Like
28

Note: anon-apps-config is installed on both workstation and gateway. But
that is good enough. The config snippet itself could check where it’s
running (the usual marker files) and only apply gateway config to
gateway and workstation config to workstation.

https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/anon-workstation.conf
https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/anon-gateway.conf

Also, as I don’t have a local repo to test, the steps to test are the following:

Build the package as usual, mk-build-deps, dpkg-buildpackage.

Then install first the onionjuggler-lib, then any wanted deb package.

## _apt user can access /tmp
cp ../onionjuggler*.deb /tmp
sudo apt install /tmp/onionjuggler-lib_*.deb

Then, copy the anon configuration files to /etc/onionjuggler/conf.d/

##From inside the git repo: 

## GW
sudo cp etc/onionjuggler/anon-gateway.conf /etc/onionjuggler/conf.d/

## WS
sudo cp etc/onionjuggler/anon-workstation.conf /etc/onionjuggler/conf.d/
1 Like