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