Make Tails Server compatible with Wayland
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)
Parent Task: #5688
Original created by @segfault on 12297 (Redmine)