On Thu, 09 Aug 2018 at 21:06:37 +0200, Helge Kreutzmann wrote:
> +Further by default
> +.B su
> +does not allow the commands to access the current X display.
This is perhaps misleading: su isn't allowing or denying anything, it's
the X server that isn't allowing other users to access it. Perhaps just
state the facts and let the user sort out the implications: "Unlike the
su implementation in Debian 9 and older releases, this su implementation
does not copy the X display address (DISPLAY) and credentials (XAUTHORITY)
to the commands"?
There are two situations with different behaviour and expectations:
escalating privileges from a non-root user to root, and changing/dropping
privileges from a user (whether root or not) to a different non-root user.
When escalating from an non-root user to root, the old su in src:shadow
copied the DISPLAY and XAUTHORITY variables to the root process. This
told X clients which X display they could use (DISPLAY), and also the
file containing credentials to use when authenticating to that display
(XAUTHORITY). The file whose name is the value of XAUTHORITY is normally
only readable by the user who owns the X display, but root can read it
anyway, because root is privileged and can exercise CAP_DAC_OVERRIDE. In
this situation, it is also unnecessary to defend against root being
able to escalate privileges to the invoking user (for instance via X
misconfiguration or via bugs like CVE-2016-2779), because root can do
that anyway.
(It hopefully goes without saying that running X applications as root
is not a good idea, both because X applications and the X display trust
each other and because GUI libraries are a huge attack surface.)
When switching from a user (root or not) to a different non-root user,
copying DISPLAY had the same effect as when escalating to root, but
copying XAUTHORITY would leave the target user's process trying to read
a file to which they do not normally have read access, so simply using
su was not sufficient even with the old src:shadow su, and setting
up access for the target user with xhost (or xauth) was additionally
required. In this situation, it normally *is* a concern if the target
user can escalate to the privileges of the invoking user, either via X
misconfiguration or via something like CVE-2016-2779: that would give
the target user abilities that they did not previously have, defeating
the value of using separate users.
> +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost".
I don't actually know how much protection against keyloggers, input
injection, output capture etc. you get from ForwardX11Trusted=no;
you'd have to ask an X11 expert. It's also known to break some X apps
(and in particular it forbids use of the selection, i.e. copy/paste),
which is why Debian's ssh has been patched (since 2004, #237021) to
default to ForwardX11Trusted=yes when X-forwarding is used (the
upstream default is that -X implies -oForwardX11Trusted=no, and
-Y is equivalent to -X -oForwardX11Trusted=yes).
> +Allow \fBsu\fR explicit display access by issuing "xhost
> +si:localuser:otheruser"
This is misleading: the display access granted by xhost is not limited
to the process tree rooted at su, but is granted to any (related or
unrelated) process whose uid is otheruser.
Perhaps "Allow X display access for processes running as \fIotheruser\fR
by issuing \fBxhost +si:localuser:\fIotheruser\fR"?
smcv
