Bug #9051
Tor Launcher is not accessible
30%
Description
- When started in the context of Tails, Tor Launcher is invisible to the Orca screen reader.
- When started on Debian Jessie, Orca works fine with Tor Launcher.
This problem has probably the same root as Bug #7502, Bug #7504: applications run as a different users or chrooted, etc. cannot be read by Orca.
Subtasks
Related issues
| Related to Tails - Bug #11755: Dogtail does not work for X applications running as non-amnesia users | In Progress | 2016-08-31 | |
|
Related to Tails - |
Resolved | 2015-04-18 | |
| Related to Tails - Bug #7502: Unsafe Browser is not accessible | Confirmed | 2014-07-06 | |
|
Related to Tails - |
Resolved | 2014-07-06 | |
| Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) | In Progress | 2017-09-02 | |
|
Has duplicate Tails - |
Duplicate | 2015-11-02 |
History
#1 Updated by sajolida 2015-03-14 14:29:14
- related to
Bug #7504: Tails Installer is fully inaccessible added
#2 Updated by sajolida 2015-03-14 14:29:28
- related to Bug #7502: Unsafe Browser is not accessible added
#3 Updated by intrigeri 2015-07-19 09:44:25
- related to deleted (
Bug #7504: Tails Installer is fully inaccessible
#4 Updated by intrigeri 2015-11-04 02:27:23
- has duplicate
Bug #10470: Tor settings cannot be read by Orca added
#5 Updated by intrigeri 2016-08-31 03:49:42
- related to Bug #11755: Dogtail does not work for X applications running as non-amnesia users added
#6 Updated by anonym 2017-03-29 16:20:03
- Status changed from Confirmed to In Progress
Applied in changeset commit:998e424d0ab5c5278290a85ab866a88a2722d8a2.
#7 Updated by anonym 2017-03-29 16:21:44
- Assignee set to anonym
- Target version set to Tails_2.12
- % Done changed from 0 to 20
- QA Check set to Ready for QA
- Feature Branch set to feature/9051-tor-launcher-accessibility
This branch should fix it, but I haven’t tested it yet. Let’s just first make sure Jenkins like it!
#8 Updated by anonym 2017-03-31 13:37:56
- Assignee deleted (
anonym) - Target version deleted (
Tails_2.12) - % Done changed from 20 to 30
- QA Check changed from Ready for QA to Dev Needed
This branch indeed makes Tor Launcher run as the Live user, Jenkins likes it, and tor_bridges.feature passes for me locally.
However, orca still doesn’t work with the Tor Launcher window that auto-starts via the NetworkManager hook. When I start tor-launcher myself as the Live user, then it works. The environment variables are set fairly similarly (thanks to export_gnome_env), so I don’t think that is the problem here. Sadly this looks harder than I expected, so I’m dropping the ball for now. :/
(I guess a fix could be to drop the tails-tor-launcher wrapper and instead make Tor Launcher autostart via XDG + wait for Tor to be running before actually starting.)
Also, I’m slightly uncomfortable with filters targeting the firefox binary; since it’s extensible it can be made to run any commands (unlike e.g. Onionshare, whose control port interaction is fixed), so if the Live user is compromised e.g. Socks5Proxy can be set to an attacker controlled host => deanonymized. By fixing the Tor Launcher filter to another dedicated user this attack vector is mitigated.
This is actually also a problem with Tor Browser although it seems it’s commands are less harmful; it was a big motivation for inventing restrict-stream-events. There might still be attacks possible with GETINFO ns/id/[a-fA-F0-9]+, and since we allow GETINFO circuit-status the circuit state must now be considered as fully known to the Live user. So, yeah, I’m not completely comfortable with that situation either…
#9 Updated by intrigeri 2017-04-01 06:52:54
- related to
Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it added
#10 Updated by intrigeri 2017-04-01 06:59:21
> However, orca still doesn’t work with the Tor Launcher window that auto-starts via the NetworkManager hook.
> When I start tor-launcher myself as the Live user, then it works.
This might be related to Bug #9260.
> The environment variables are set fairly similarly (thanks to export_gnome_env), so I don’t think that is the problem here.
I suspect that Tor Launcher might try to connect to D-Bus (that’s not started yet) or to Orca’s D-Bus service (that’s not available yet).
> (I guess a fix could be to drop the tails-tor-launcher wrapper and instead make Tor Launcher autostart via XDG + wait for Tor to be running before actually starting.)
Yes, absolutely (modulo s/XDG/a systemd user service/, like config/chroot_local-includes/usr/lib/systemd/user/tails-upgrade-frontend.service).
But then some parts of our NM hooks will need to wait for Tor Launcher having configured Tor before they can proceed with the next steps, no?
> Also, I’m slightly uncomfortable with filters targeting the firefox binary; since it’s extensible it can be made to run any commands (unlike e.g. Onionshare, whose control port interaction is fixed), so if the Live user is compromised e.g. Socks5Proxy can be set to an attacker controlled host => deanonymized. By fixing the Tor Launcher filter to another dedicated user this attack vector is mitigated.
I don’t follow, sorry! What do you mean with “it’s extensible it can be made to run any commands”?
> This is actually also a problem with Tor Browser although it seems it’s commands are less harmful; it was a big motivation for inventing restrict-stream-events. There might still be attacks possible with GETINFO ns/id/[a-fA-F0-9]+, and since we allow GETINFO circuit-status the circuit state must now be considered as fully known to the Live user. So, yeah, I’m not completely comfortable with that situation either…
Research ticket, maybe?
#11 Updated by intrigeri 2017-06-04 10:36:50
At some point “Tor Launcher will probably initiate some network activity of its own, for example to start meek-client to talk to bridgedb”. Whenever this happens (and if we want that feature in Tails), I don’t see how we can safely run Tor Launcher as the amnesia user :/
#12 Updated by intrigeri 2017-09-02 08:20:32
- related to deleted (
Bug #7502: Unsafe Browser is not accessible)
#13 Updated by intrigeri 2017-09-02 08:21:15
- related to deleted (
Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it
#14 Updated by intrigeri 2017-09-02 08:21:22
- Parent task set to Feature #14522
#15 Updated by intrigeri 2017-09-02 08:21:42
- related to
Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it added
#16 Updated by Anonymous 2018-01-15 11:03:46
- related to Bug #7502: Unsafe Browser is not accessible added
#17 Updated by Anonymous 2018-01-15 11:04:37
- related to
Bug #7504: Tails Installer is fully inaccessible added
#18 Updated by Anonymous 2018-01-15 11:05:17
- Type of work changed from Code to Research
#19 Updated by Anonymous 2018-01-15 11:06:14
Next steps: Research details referring to https://labs.riseup.net/code/issues/9051#note-10.
#20 Updated by intrigeri 2019-03-08 15:48:02
- blocked by Feature #12213: Wayland in Tails 5.0 (Bullseye) added
#21 Updated by intrigeri 2019-03-08 16:55:15
- blocks deleted (
Feature #12213: Wayland in Tails 5.0 (Bullseye))
#22 Updated by intrigeri 2019-03-08 16:55:22
- related to Feature #12213: Wayland in Tails 5.0 (Bullseye) added
#23 Updated by intrigeri 2019-08-30 20:16:17
- Status changed from In Progress to Confirmed
#24 Updated by zersiax 2020-05-01 16:46:09
I see we ran into a roadblock for this one …is it still true that the workaround for this one is to just start the launcher as the live user?
If so, can we add the command to do that here for documentation purposes until we find a better solution?
#25 Updated by intrigeri 2020-05-07 09:18:16
> is it still true that the workaround for this one is to just start the launcher as the live user?
It’s correct that it’s part of the solution, but as often, “just” makes things look much simpler than they really are.
> If so, can we add the command to do that here for documentation purposes until we find a better solution?
I’m afraid there’s no simple solution that’s simple enough to be documented for end users :(