Tails

#3 Updated by intrigeri 2019-08-20 07:38:15

Might be related to Bug #12092#note-24.

#5 Updated by segfault 2019-08-27 21:32:01

Can’t reproduce. On a Tails image based on yesterday’s devel branch (commit:9f57027ef3bb7a24f255058788adb3d649af159c), I open Additional Software, then I click on “Synaptic Package Manager”, then I get asked for the administration password, then Synaptic opens.

#6 Updated by segfault 2019-08-27 21:36:13

segfault wrote:
> Can’t reproduce. On a Tails image based on yesterday’s devel branch (commit:9f57027ef3bb7a24f255058788adb3d649af159c), I open Additional Software, then I click on “Synaptic Package Manager”, then I get asked for the administration password, then Synaptic opens.

Same with an image based on devel from Aug 11 (commit:0a1ea458111f16833e10cb02c4cd445990c32019).

#9 Updated by intrigeri 2019-08-30 08:45:56

Hi!

> I was also able to reproduce this on Tails 3.15, so this is not a regression

In a way, it’s good news: one less Buster-related regression that we have to treat as particularly urgent! I’ll drop the target version: we have plenty of other FT work that’s more important and/or urgent than this one.

OTOH it’s somewhat concerning that we’ve shipped the Additional Software feature without ever noticing this bug. Anyway, trying to start Synaptic from there is almost a corner case, so I’m not utterly surprised this was neither noticed by us, nor reported by users.

> So the issue is that tails-persistence-setup is run as its own user, which has the default shell set to /bin/false. When it starts tails-addititional-software-config, that is also run as the tails-persistence-setup user, and then pkexec doesn’t seem to work because there is no working default shell configured.

Giving tails-persistence-setup a real shell should be fine: I don’t think the security design (that’s somewhat documented IIRC) relies on it having none.

> IMO the best design would be to run the tails-persistence-setup app as amnesia and have a privileged backend which the app uses for the actions which require privileges.

Fully agreed: this is tracked as Feature #15142. It’s not exactly trivial. In the meantime, the bug this ticket is about can probably be fixed cheaply, as described above.

> IIRC, it’s not possible to run graphical apps as another user under Wayland, so we have to change this anyway at some point, right?

Yes, although there’s a dirty workaround available (see the description of Feature #12213), but the current plan is that for Tails 5.0 (Bullseye) we switch to Wayland without using that workaround. We’ll see how close to this objective we manage to go :)

#13 Updated by intrigeri 2020-02-23 10:21:14

Building upon the work segfault did above, I’ve looked into it with Alan and that’s the simplest workaround we could think of, that has a chance to work, and could be implemented before the privileged backend / unprivileged GUI redesign:

• Give a working shell to the tails-persistence-setup user.
• Grant the tails-persistence-setup user the right to run synaptic-pkexec --update-at-startup as the amnesia user, in a sanitized environment that still allows running X11 apps, without any other command line argument. Set the org.freedesktop.policykit.exec.allow_gui annotation.
• In cb_activate_link, if current user is not amnesia, then instead of starting Synaptic with Gio.DesktopAppInfo, run pkexec --user amnesia synaptic-pkexec (or similar); then synaptic-pkexec will ask the user their administration password.

Given Feature #15142 likely won’t happen before 2020Q4 (at best), iff. the above works soonish without too much effort and is acceptable security-wise, it could be worth it. But if it gets any more complicated than that, we should check this again vs. the timeline for Feature #15142.