Project

General

Profile

Feature #10422

Feature #15678: Improve UX of saving downloaded files from Tor Browser

Grant Tor Browser access to files as designated by the user

Added by sajolida almost 4 years ago. Updated 13 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/30/2018
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Starter:
Affected tool:
Browser

Description

In https://mailman.boum.org/pipermail/tails-ux/2015-September/000645.html we're been discussing the idea of granting Tor Browser access to files if and only if the user decide to open or otherwise access it.

This would improve on the current control access policy based on a set of folders (~/Tor Browser and ~/Persistent/Tor Browser). This idea is inspired by "Guidelines and Strategies for Secure Interaction Design" by Ka-Ping Yee and also seems to be of interest to GNOME as "Implicit permission grants from interactive operations":

https://mail.gnome.org/archives/gnome-os-list/2015-March/msg00010.html

We should follow-up on the plans of GNOME regarding this but there's not much we can do ourselves for the time being.

Existing WIP and discussions:


Subtasks

Feature #15874: Start looking at snaps/Flatpak for sandboxingConfirmedintrigeri


Related issues

Related to Tails - Bug #15472: Rebase our Tor Browser AppArmor policy on top of torbrowser-launcher 0.2.9-2's Resolved 03/28/2018
Related to Tails - Bug #9534: Tighten AppArmor policy Resolved 06/04/2015
Related to Tails - Feature #16356: Upgrade to Tor Browser 9.0 (based on Firefox 68) In Progress 01/14/2019

History

#1 Updated by intrigeri almost 4 years ago

  • Blueprint set to https://tails.boum.org/contribute/design/application_isolation/

(I've been keeping the corresponding technical info quite up-to-date on the blueprint, let's point to it so that this ticket doesn't become an incentive to duplicate work.)

#2 Updated by u about 1 year ago

  • Related to Bug #15472: Rebase our Tor Browser AppArmor policy on top of torbrowser-launcher 0.2.9-2's added

#3 Updated by u about 1 year ago

  • Related to Bug #9534: Tighten AppArmor policy added

#4 Updated by u about 1 year ago

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

#5 Updated by intrigeri about 1 year ago

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

#6 Updated by sajolida about 1 year ago

  • Parent task set to #15678

This could be a solution for #15678.

#7 Updated by intrigeri 8 months ago

  • Related to Feature #15874: Start looking at snaps/Flatpak for sandboxing added

#8 Updated by intrigeri 7 months ago

  • Related to deleted (Feature #15874: Start looking at snaps/Flatpak for sandboxing)

#9 Updated by intrigeri 7 months ago

  • Blocked by Feature #15874: Start looking at snaps/Flatpak for sandboxing added

#10 Updated by intrigeri 7 months ago

  • Blocked by deleted (Feature #15874: Start looking at snaps/Flatpak for sandboxing)

#11 Updated by intrigeri 7 months ago

  • Type of work changed from Wait to Code

#12 Updated by intrigeri 15 days ago

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 (#16356), let's come back to it once we have Tails images based on it.

#13 Updated by intrigeri 15 days ago

  • Description updated (diff)

#14 Updated by intrigeri 15 days ago

  • Related to Feature #16356: Upgrade to Tor Browser 9.0 (based on Firefox 68) added

#15 Updated by intrigeri 13 days ago

intrigeri wrote:

Given Tor Browser based on Firefox 68 is coming in 1.5 month (#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 13 days ago

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 13 days ago

@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. https://redmine.tails.boum.org/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 13 days ago

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.

Also available in: Atom PDF