Bug#880601: gdm fails to give wayland an Xauthority file, preventing running applications as root

[Phil Susi]

Package: gdm3
Version: 3.26.1-3

The man page for gdm3 states that it will create an XAUTHORITY file in
/var/run/gdm3 and set the environment variable to point to it. It does
not do this when running wayland. Instead it leaves Xwayland configured
to allow connections only from local processes running as the same user
ID. This prevents you from being able to run X applications as root,
such as gparted or synaptic. It also means that two users on two
different terminals using a shared/guest UID can interfere with one
another's X session, making it a security issue as well.

Please restore the sane XAUTHORITY settings under Xwayland.

[Simon McVittie]

On Thu, 02 Nov 2017 at 13:56:34 -0400, Phil Susi wrote:
> The man page for gdm3 states that it will create an XAUTHORITY file in
> /var/run/gdm3 and set the environment variable to point to it. It does
> not do this when running wayland. Instead it leaves Xwayland configured
> to allow connections only from local processes running as the same user
> ID. This prevents you from being able to run X applications as root,
> such as gparted or synaptic.

Wayland is designed to be per-uid. If you want X11, I would suggest
using X11.

Running GUIs as root gives them a huge attack surface, breaking the
privilege separation between root and the user that owns the display.
It has historically worked, but that doesn't make it a good idea for the
future (or the present, for that matter). The move from X11 to Wayland,
at which traditional approaches to various things (e.g. screenshots) break
anyway due to Wayland having the concept of privileged and unprivileged
clients, is a convenient flag-day to move from "discouraged but still
works" to "a line has been drawn here, this no longer works".

A much safer design is for an unprivileged GUI running as the user to
submit requests to a privileged service (for example GNOME Software
running as the user and submitting requests to PackageKit via D-Bus,
GNOME Disks submitting requests to udisks2 via D-Bus, and printing GUIs
submitting requests to CUPS via IPP/HTTP), and having the privileged
service make access-control policy decisions about those requests
(for example PackageKit, udisks2 and many other privileged services
authenticate the user using D-Bus' credentials-passing and delegate the
authorization decision to polkit, while CUPS authenticates the user with
a password and carries out its own authorization check for membership
of the lpadmin group).

> It also means that two users on two
> different terminals using a shared/guest UID can interfere with one
> another's X session, making it a security issue as well.

Two users sharing a uid can interfere with each other's files and
processes in numerous ways. Unix kernels are not designed to put a
boundary between different processes of the same uid, and I would
strongly recommend not attempting to do so.

Regards,
smcv

[Phil Susi]

On 11/2/2017 2:46 PM, Simon McVittie wrote:
> Wayland is designed to be per-uid. If you want X11, I would suggest
> using X11.

XWayland will use whichever authentication method you want, and the
MIT-MAGIC-COOKIE has worked quite well for a very long time, even in the
presence of multiple user login sessions and su.

> Running GUIs as root gives them a huge attack surface, breaking the
> privilege separation between root and the user that owns the display.
> It has historically worked, but that doesn't make it a good idea for the
> future (or the present, for that matter). The move from X11 to Wayland,
> at which traditional approaches to various things (e.g. screenshots) break
> anyway due to Wayland having the concept of privileged and unprivileged
> clients, is a convenient flag-day to move from "discouraged but still
> works" to "a line has been drawn here, this no longer works".

So someone high and mighty just decided to screw over users because it
"isn't a good idea" to have root gui applications?

> A much safer design is for an unprivileged GUI running as the user to
> submit requests to a privileged service (for example GNOME Software
> running as the user and submitting requests to PackageKit via D-Bus,
> GNOME Disks submitting requests to udisks2 via D-Bus, and printing GUIs
> submitting requests to CUPS via IPP/HTTP), and having the privileged
> service make access-control policy decisions about those requests
> (for example PackageKit, udisks2 and many other privileged services
> authenticate the user using D-Bus' credentials-passing and delegate the
> authorization decision to polkit, while CUPS authenticates the user with
> a password and carries out its own authorization check for membership
> of the lpadmin group).

That's nice in theory, but there are tons of applications out there that
are not going to be rewritten to do that, and people expect them to
continue to work. Breaking those applications because there is an
arguably better way they could have been implemented is a huge
disservice to users and is likely to make many of them say to hell with
Wayland.

> Two users sharing a uid can interfere with each other's files and
> processes in numerous ways. Unix kernels are not designed to put a
> boundary between different processes of the same uid, and I would
> strongly recommend not attempting to do so.

Linux certainly can. Each login session can be given a unique, private
filesystem namespace that the other can not see. PID namespaces can be
used to separate even their ability to see and signal each others
processes. If you do that, then with the MIT-MAGIC-COOKIE
authentication, each session has its own authenticator that the other
session can not see.

[Emilio Pozuelo Monfort]

Please forward this request upstream. We are unlikely to add a patch for this.

Cheers,
Emilio

[Phil Susi]

forwarded 880601 https://bugzilla.gnome.org/show_bug.cgi?id=789867
affects 880601 + gparted synaptic
thanks

On 11/3/2017 10:26 AM, Emilio Pozuelo Monfort wrote:
> Please forward this request upstream. We are unlikely to add a patch for this.

It is a shame that you are unwilling to make a simple configuration
change to prevent a completely broken experience for your users. People
get very frustrated when they try to open an application and nothing
happens. No error message; nothing. All because of a silly default policy.

[Michael Biebl]

Hi Phil

Am 03.11.2017 um 18:57 schrieb Phil Susi:
> On 11/3/2017 10:26 AM, Emilio Pozuelo Monfort wrote:
>> Please forward this request upstream. We are unlikely to add a patch for this.
>
> It is a shame that you are unwilling to make a simple configuration
> change to prevent a completely broken experience for your users. People
> get very frustrated when they try to open an application and nothing
> happens. No error message; nothing. All because of a silly default policy.

It is my understanding that not allowing root X applications is an
explicit choice, as it was considered a bad idea to run complex X
applications as uid 0 (which I agree with)

Let's see what upstream has to say about this.

Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Phil Susi]

FYI, this appears to be a quite extensive list of debian applications
that are now broken by this issue: