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

[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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20171102/0674b91a/attachment-0001.sig>