Tails

#4 Updated by Anonymous 2018-08-18 10:39:06

I don’t think this is currently possible. We have AppArmor, but as said on Bug #9534, we might want to sandbox applications in the future using other techniques.

#5 Updated by intrigeri 2018-08-19 11:40:55

To clarify, this is a post-Buster goal but still something we need.

#12 Updated by intrigeri 2019-09-07 18:42:15

I gave a quick first try at a trick @hefee told me about (they tested this successfully with Firefox 64) to make Tor Browser use Portals.

I’ve done this:

• export GTK_USE_PORTAL=1 in the environment
• the GNOME portal backend: apt install xdg-desktop-portal-gtk
• a relaxed AppArmor profile for Tor Browser, that allows everything except reading ~/.gnupg/gpg.conf

⇒ Tor Browser 8.5.5 still does not use the file chooser portal to open/save files:
it cannot open ~/.gnupg/gpg.conf.

https://wiki.archlinux.org/index.php/Firefox says it only works with Firefox 64 or newer, at least for KDE. But in the diff between Tor Browser based on Firefox 60 vs. 68, the only Portal/Flatpak-related stuff I see seems irrelevant (in widget/gtk/nsFilePicker.cpp but that’s merely a fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1517074, and apart of that support for screen sharing with PipeWire and printing), so I’m a bit surprised.

The latest WIP Flatpak from https://github.com/flathub/flathub/pull/1135 (flatpak install https://dl.flathub.org/build-repo/7084/com.github.micahflee.torbrowser-launcher.flatpakref), also using Tor Browser based on Firefox 60, does not use the Portal by default either. But I’ve not tried injecting GTK_USE_PORTAL=1 in there.

Given Tor Browser based on Firefox 68 is coming in 1.5 month (Feature #16356), let’s come back to it once we have Tails images based on it.

#15 Updated by intrigeri 2019-09-09 19:54:33

intrigeri wrote:
> Given Tor Browser based on Firefox 68 is coming in 1.5 month (Feature #16356), let’s come back to it once we have Tails images based on it.

There’s progress but it still does not work. Using basically the same test procedure as described above, on a Tails built from feature/16356-tor-browser-9.0+force-all-tests (Stretch so I installed the needed packages from stretch-backports), and an AppArmor profile that denies reading gpg.conf and reading+writing ~/Music/, I see surprising behavior:

• dbus-monitor shows that Tor Browser is talking to the org.freedesktop.portal.FileChooser portal as intended.
• I can navigate to any directory allowed by DAC, even those that are forbidden by AppArmor. I see an error dialog that tells me it’s forbidden but the file chooser displays the content of the directory anyway.
• AppArmor denies reading/saving files from/to places that the minimal profile allows.

It might be that the GTK version in Stretch is not good enough for effectively using portals: there’s no GTK_USE_PORTAL in its source code. OTOH what dbus-monitor tells me is consistent with a GTK that uses portals, and Tor Browser uses the system GTK libs (confirmed with pmap --show-path) so I’m confused. Now there’s this weird thing called /usr/local/lib/tor-browser/libmozgtk.so which might interfere. Will retry with a Buster image built from devel + feature/16356-tor-browser-9.0+force-all-tests to check the “too old GTK” hypothesis.

#16 Updated by intrigeri 2019-09-09 20:54:58

intrigeri wrote:
> Will retry with a Buster image built from devel + feature/16356-tor-browser-9.0+force-all-tests to check the “too old GTK” hypothesis.

Same behavior. It looks like Firefox is using the FileChooser portal to display native dialogs but not to actually open/save files. Or, I’m doing it wrong / misunderstanding it, which is entirely possible. Was worth a quick try anyway :)

Before I work on this more some day, I should learn about how the FileChooser portal passes back files to the GTK app, and what GTK + the app do with it then.

#17 Updated by hefee 2019-09-10 09:05:09

@intrigeri: I made a test on my Debian Sid system with KDE and Firefox (69.0) and TorBrowser.

I have the environment variable GTK_USE_PORTAL=1 and use xdg-desktop-portal-kde.

Firefox is using native kde file dialogs for opening/saving file (use right-click “save page as” and File->open file). Additionaly if I download a file and selects open file (e.g. /code/attachments/download/1551/weblate.svg) I get the “Open with dialog” from kde. That’s like I exptected the portals to work.

Testing TorBrowser I see GTK file dialogs, for open/saving files aka the portal is not working for that part. But if I download a file, I see the same “Open with dialog” from kde. So from my point of view something is blocking the FileChooser Portal to work together with TorBrowser.

#18 Updated by hefee 2019-09-10 09:16:40

I tried aa-complain torbrowser.Browser.firefox to set TorBrowser to complain mode and restarted it. It is still not working, but I see now all my mounted devices in the FileChooser dialog, but still GTK FileChooser.

journalctl give me nothing interesstingly just:
```
apparmor=“ALLOWED” operation=“open” profile=“torbrowser_firefox” name=“/etc/fstab”
```

=> it is not AppArmor that is stopping the FileChosser dialogs.

#19 Updated by hefee 2019-10-28 18:07:16

At least for me, this is solved on my sid system with TorBrowser 9.0 (based on Mozilla Firefox 68.2.0esr). I see the KDE Open/Save FileChoose dialogs, like I expect them.
environment variable GTK_USE_PORTAL=1 and xdg-desktop-portal-kde

@intrigeri: it is maybe time to retest for a GTK environment.

#21 Updated by intrigeri 2019-11-10 18:11:31

> At least for me, this is solved on my sid system with TorBrowser 9.0 (based on Mozilla Firefox 68.2.0esr). I see the KDE Open/Save FileChoose dialogs, like I expect them.
> environment variable GTK_USE_PORTAL=1 and xdg-desktop-portal-kde

> intrigeri: it is maybe time to retest for a GTK environment.

Great!