Project

General

Profile

Bug #9051

Feature #14522: Make Tails usable for blind users

Tor Launcher is not accessible

Added by sajolida over 4 years ago. Updated over 1 year ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Accessibility
Target version:
-
Start date:
03/14/2015
Due date:
% Done:

30%

Feature Branch:
feature/9051-tor-launcher-accessibility
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Tor Launcher

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 #7502, #7504: applications run as a different users or chrooted, etc. cannot be read by Orca.


Related issues

Related to Tails - Bug #11755: Dogtail does not work for X applications running as non-amnesia users In Progress 08/31/2016
Related to Tails - Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it Resolved 04/18/2015
Related to Tails - Bug #7502: Unsafe Browser is not accessible Confirmed 07/06/2014
Related to Tails - Bug #7504: Tails Installer is fully inaccessible Resolved 07/06/2014
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 09/02/2017
Duplicated by Tails - Bug #10470: Tor settings cannot be read by Orca Duplicate 11/02/2015

Associated revisions

Revision 9c32058a (diff)
Added by anonym over 2 years ago

Run Tor Launcher as the Live user.

This is a first step towards making Tor Launcher accessible.

Refs: #9051

Revision 98d4c744 (diff)
Added by anonym over 2 years ago

Don't create the tor-launcher use any more.

It is not needed since we now run Tor Launcher as the Live user.

Refs: #9051

Revision c21f9788 (diff)
Added by anonym over 2 years ago

Make sure Tor Launcher is started in a proper environment.

... where all the Xorg/GNOME stuff are set, so accessibility hopefully
will work.

Refs: #9051

Revision fe453a97 (diff)
Added by anonym over 2 years ago

gnome.sh: Export more variables via export_gnome_env().

Hopefully they will help orca making applications accessible.

Refs: #9051

History

#1 Updated by sajolida over 4 years ago

  • Related to Bug #7504: Tails Installer is fully inaccessible added

#2 Updated by sajolida over 4 years ago

  • Related to Bug #7502: Unsafe Browser is not accessible added

#3 Updated by intrigeri almost 4 years ago

  • Related to deleted (Bug #7504: Tails Installer is fully inaccessible)

#4 Updated by intrigeri over 3 years ago

  • Duplicated by Bug #10470: Tor settings cannot be read by Orca added

#5 Updated by intrigeri almost 3 years ago

  • Related to Bug #11755: Dogtail does not work for X applications running as non-amnesia users added

#6 Updated by anonym over 2 years ago

  • Status changed from Confirmed to In Progress

Applied in changeset commit:998e424d0ab5c5278290a85ab866a88a2722d8a2.

#7 Updated by anonym over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

  • Related to Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it added

#10 Updated by intrigeri over 2 years ago

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 #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 about 2 years ago

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 almost 2 years ago

  • Related to deleted (Bug #7502: Unsafe Browser is not accessible)

#13 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it)

#14 Updated by intrigeri almost 2 years ago

  • Parent task set to #14522

#15 Updated by intrigeri almost 2 years ago

  • Related to Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it added

#16 Updated by u over 1 year ago

  • Related to Bug #7502: Unsafe Browser is not accessible added

#17 Updated by u over 1 year ago

  • Related to Bug #7504: Tails Installer is fully inaccessible added

#18 Updated by u over 1 year ago

  • Type of work changed from Code to Research

#19 Updated by u over 1 year ago

Next steps: Research details referring to https://labs.riseup.net/code/issues/9051#note-10.

#20 Updated by intrigeri 4 months ago

#21 Updated by intrigeri 4 months ago

  • Blocked by deleted (Feature #12213: Wayland in Tails 5.0 (Bullseye))

#22 Updated by intrigeri 4 months ago

Also available in: Atom PDF