Change which Tor controller functions are called for Tails support

[micahflee]

I'm trying to see if I can get the new OnionShare working in Tails. When I launch it it throws this exception:

Traceback (most recent call last):
  File "/app/lib/python3.8/site-packages/onionshare-2.3.1-py3.8.egg/onionshare/settings_dialog.py", line 693, in test_tor_clicked
  File "/app/lib/python3.8/site-packages/onionshare_cli-2.3.1-py3.8.egg/onionshare_cli/onion.py", line 565, in connect
  File "/app/lib/python3.8/site-packages/stem/control.py", line 489, in wrapped
    return func(self, *args, **kwargs)
  File "/app/lib/python3.8/site-packages/stem/control.py", line 1277, in get_version
    version_str = self.get_info('version')
  File "/app/lib/python3.8/site-packages/stem/control.py", line 489, in wrapped
    return func(self, *args, **kwargs)
  File "/app/lib/python3.8/site-packages/stem/control.py", line 1209, in get_info
    stem.response.convert('GETINFO', response)
  File "/app/lib/python3.8/site-packages/stem/response/__init__.py", line 124, in convert
    message._parse_message(**kwargs)
  File "/app/lib/python3.8/site-packages/stem/response/getinfo.py", line 46, in _parse_message
    raise stem.OperationFailed(error_code, error_msg)
stem.OperationFailed: Command filtered

This is because https://github.com/micahflee/onionshare/blob/develop/cli/onionshare_cli/onion.py#L565 calls get_version() on the Tor controller object, and Tails filters everything that isn't absolutely necessary.

# Get the tor version
self.tor_version = self.c.get_version().version_str
self.common.log("Onion", "connect", f"Connected to tor {self.tor_version}")

We should wrap self.c.get_version() in a try/except block and just say "unknown version" if that command is filtered.

[mig5]

I think there might be a workaround.

According to https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/onion-grater.d/onionshare.yml , Tails has allowed OnionShare to issue the GETINFO version command on the controller.

Therefore, rather than use Stem's get_version, we can use Stem's get_info('version'). I think that will be okay?

[mig5]

Actually I'm clearly off my tree.. because as the stack trace above shows, it's ultimately already running get_info('version') under the hood anyway, even if it's using the convenience function of get_version().

So what I'm not clear on, is why it's throwing an exception at all, if the link above shows that GETINFO is allowed in the filter. Unless the Gitlab link I linked to, is for a file that isn't actually making it into the Tails OS for some reason, or it doesn't do what I assumed it does?

https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/onion-grater.d/onionshare.yml#L8-9

[micahflee]

I've been working on this in the https://github.com/micahflee/onionshare/tree/1309_tails branch but I'm hitting problems and I don't quite understand how onion-grater works. I think the correct solution to this issue is to get Tails to update https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/onion-grater.d/onionshare.yml to include allow all of the commands that modern OnionShare needs.

I think I might decide to not support Tails for version 2.3.2 and instead get Tails devs help to modify the onion-grater config so it will work.

Testing an OnionShare branch in Tails

Testing an OnionShare branch in Tails is pretty complicated so I decided to document it here.

There are tricks to make flatpak stuff persist in Tails by following this blog post: https://bisco.org/notes/installing-and-running-signal-on-tails/

But ignoring that, create a Tails USB and run:

# install flatpak
sudo apt update
sudo apt install flatpak -y

# install onionshare from flathub (in order to install the flatpak dependencies)
torify flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
torify flatpak install  --user flathub org.onionshare.OnionShare

# uninstall onionshare
flatpak remove org.onionshare.OnionShare

Then on another computer, clone https://github.com/flathub/org.onionshare.OnionShare and then basically apply this diff (build onionshare from the 1309_tails branch instead of the v2.3.1 tag):

diff --git a/org.onionshare.OnionShare.yaml b/org.onionshare.OnionShare.yaml
index 2c46dd3..f7eeedc 100644
--- a/org.onionshare.OnionShare.yaml
+++ b/org.onionshare.OnionShare.yaml
@@ -111,7 +111,7 @@ modules:
     sources:
       - type: git
         url: https://github.com/micahflee/onionshare.git
-        tag: v2.3.1
+        branch: 1309_tails
     modules:
       - name: python3-qrcode
         buildsystem: simple
@@ -129,7 +129,7 @@ modules:
         sources:
           - type: git
             url: https://github.com/micahflee/onionshare.git
-            tag: v2.3.1
+            branch: 1309_tails
         modules:
           - name: python3-modules
             buildsystem: simple

Then build a flatpak single-file bundle of OnionShare:

# build the flatpak package
flatpak-builder build --force-clean --install-deps-from=flathub --install --user org.onionshare.OnionShare.yaml

# export it as a single-file bundle
flatpak build-bundle ~/.local/share/flatpak/repo/ onionshare.flatpak org.onionshare.OnionShare

Then transfer onionshare.flatpak to the test Tails box (perhaps by using OnionShare) and install it on Tails:

flatpak install --user ./onionshare.flatpak

Then you can try running the modified OnionShare in Tails:

flatpak run org.onionshare.OnionShare

[micahflee]

I just created a new upstream issue in Tails: https://gitlab.tails.boum.org/tails/tails/-/issues/18287

[mig5]

One clue might be that the file https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/onion-grater.d/onionshare.yml suggests it assumes OnionShare is located at /usr/bin/onionshare and /usr/bin/onionshare-gui - at least in terms of the apparmor-profile statement. I don't know onion-grater either so I'm not sure if that's a rule saying 'these rules only apply if OnionShare ran as a program at this location'.

A flatpak package is probably a different path, and therefore maybe it is not being run past this set of 'allowed' commands in the filter. Just a theory

[micahflee]

When I run flatpak run org.onionshare.OnionShare then then run ps aux in another terminal, the path for the onionshare process is is /usr/bin/python3 /app/bin/onionshare -- that's a path inside the Flatpak linux container.

I attempted to add /app/bin/onionshare to the apparmor-profile statement and even attempted to copy the /usr/bin/onionshare-gui AppArmor profile and change it work for /app/bin/onionshare, but sadly no luck.

The only way I've gotten it to work in Tails is by basically bypassing onion-grater by putting it in complain mode:

sudo systemctl stop onion-grater
sudo /usr/bin/python3 -u /usr/local/lib/onion-grater --listen-address 0.0.0.0 --complain

Then in another tab, flatpak run org.onionshare.OnionShare and change the Tor settings to connect to the control port.

Everything in OnionShare works great in Tails after doing this, and you can monitor the output in the onion-grater terminal to watch all the communication with the control port. But of course, you've basically disabled the Tor control port filter.