Project

General

Profile

Bug #12297

Feature #12213: Wayland

Make Tails Server compatible with Wayland

Added by segfault 9 months ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
03/04/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Server

Description

In Wayland, only the local user (amnesia) is able to run UI applications. It is not planned that this will be changed, for more information see this ticket.

So, the previous plan to run tails-server as a dedicated user with polkit rules to allow priviliged actions is not compatible with Wayland.

There seem to be 4 options:

1. Run tails-server as a dedicated user with polkit rules, using some workaround like `xhost si:amnesia:tails-server-user` or `XDG_RUNTIME_DIR=/run/user/$MY_UID`. This would make use of XWayland instead of Wayland. We would have to investigate further implications of this.
  • Pro: Almost no additional coding required
  • Contra: Still has to be investigated
2. Create polkit rules to allow amnesia to execute the required priviliged actions. This would allow all apps to execute these actions, so we have to think about security implications. We could adjust the polkit rules to only allow the exact actions required by Tails Server, i.e. install/remove those packages required by some service in Tails Server, start/stop the corresponding systemd units, edit the config files, etc.
  • Contra: This would offer a lot of attack surface to other applications.
3. Run the GUI as amnesia and the back-end as root in separate processes, and expose a reduced high-level control interface.
  • Contra: This would require additional effort to implement 1. the Inter-process-communication, and 2. the reduced high-level control interface.
  • Contra: The back-end would accept commands from all apps running as amnesia user, which might offer attack surface (but certainly less than option 2, because the interface can be reduced more fine-grained).
4. Run the GUI as amnesia and the back-end as root in separate processes, and expose a low-level control interface, that only accepts commands from the GUI process. This could be done with something like the Tor control port filter, which handles incoming requests depending on the AppArmor profile currently applied to the client.
  • Contra: This would require additional effort to implement 1. the Inter-process-communication, and 2. the "control-port-filter"-like functionality (maybe the Tails control port filter proxy could be reused for this?).
  • Pro: The back-end would accept commands only from the Tails Server GUI
5. Run the GUI as amnesia and the back-end as root in separate processes, and expose a reduced high-level control interface, that only accepts commands from the GUI process.
  • Contra: This would require additional effort to implement 1. the Inter-process-communication, 2. the reduced high-level control interface, and 3. the "control-port-filter"-like functionality.
  • Pro: The back-end would accept commands only from the Tails Server GUI and has a reduced control inteface (providing some fallback security in case the control filter is circumvented)

History

#1 Updated by segfault 9 months ago

  • Affected tool set to Server

#2 Updated by segfault 9 months ago

  • Subject changed from Make Tails-Server compatible with Wayland to Make Tails Server compatible with Wayland

#3 Updated by intrigeri 9 months ago

3. Run the GUI as amnesia and the backend as root in separate processes, and expose a reduced high-level control interface.
  • Contra: The back-end would accept commands from all apps running as amnesia user, which might offer attack surface (but certainly less than option 2, because the interface can be reduced more fine-grained).

Note that this IPC interface can be limited to the Tails Server GUI, just like in option 4.
You may choose to include this provision in option 3, or call it option 5.

#4 Updated by segfault 9 months ago

  • Description updated (diff)

Note that this IPC interface can be limited to the Tails Server GUI, just like in option 4.
You may choose to include this provision in option 3, or call it option 5.

Sure, I added it as option 5. This only provides additional security in case the control filter was circumvented, right? Personally, I feel like leaning towards option 1 or 4, because they require the least additional work and increase of code complexity.

#5 Updated by intrigeri 3 months ago

  • Parent task set to #12213

#6 Updated by intrigeri 3 months ago

  • Target version changed from Tails_4.0 to 2019

(Like the parent ticket, assuming we don't have to switch to Wayland earlier.)

Also available in: Atom PDF