Hello Davide,
hello Simon,
On Thu, Aug 09, 2018 at 09:53:48PM +0200, Davide Prina wrote:
> On 09/08/2018 21:06, Helge Kreutzmann wrote:
> >+Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent 
> >fast-user-switching feature in other desktop environments),
> here probably it is better to say that the user can switch from one to other
> user with the Ctrl-Alt-Fx keys
> >+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost".
> and here, I think it is better to write somethings like:
> +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no $OTHERUSER@$LOCALHOST".
> +Where $OTHERUSER is the user you want to use to execute commands
> +and $LOCALHOST is your localhost (it can be: localhost,, ...)

I introduced otheruser above. I updated the text to explicitly include
localuser as well.

> and probably it is better to mention that you need sshd process active in
> your system (you must install openssh-server).

Remember that this is not an introduction of how to use all those
other tools but rather points to them. I explicitly referenced now the
man page of ssh.

> I don't know if it is better to evidence that with this solution you can
> have performance problems and not all can work correctly as you expected.

I think the man page is not the right place to discuss those issues.
It is intended as first pointer for future reading or simply using
(i.e. the user might now already about those solutions, but simply
needs a gentle reminder).

> >+Allow \fBsu\fR explicit display access by issuing "xhost 
> >+si:localuser:otheruser" in
> and here, I think it is better to write somethings like:
> +explicit display access by issuing "xhost +si:localuser:$OTHERUSER"
> ...
> >+the originating X session and "DISPLAY=:0 command" under \fBsu\fR.

As stated above, I updated the introduction of the roles localuser and

> and here
> +the originating X session and "DISPLAY=:0 $COMMAND" under \fBsu\fR.

I don't know if using $COMMAND provides more clarity than command.

> +or export the DISPLAY variable as "export DISPLAY=:0"
> +and then execute all the commands with GUI you like: "$COMMAND &"
> +where $COMMAND is the GUI command you like to exec (eg: qcalculate &)

This is longer and I would rather avoid writing this, because using
graphical applications should remain the exception, and explaining
this here might people lend to have such shell open permanently and
running much more than desired. And again, people who need this either
know how to export the DISPLAY permanenetly or they can now look up
other documentation to find out how to do it. Keep it short and simple
and let the other documentation do its work.

> Probably it is better to put some link to documentation
> man sshd
> man ssh_config
> man sshd_config

No, this is going beoynd what is needed here. In ssh(1) you get all
the pointers.

> man xhost

I reworded the text to include this link.

On Fri, Aug 10, 2018 at 08:13:05AM +0100, Simon McVittie wrote:
> 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"?

I update the text.

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

This explanation is in my opinion well suited for some README or more
extensive documentation but goes byond the scope and breadth of a man
page. Further it is mentioned that there are security issues. I made
it even more explicit in the text now.

> > +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).

I did not investigate the implications of -oForwardX11Trusted=no.
However, I thinks it serves a good pointer. If the user knows he needs
more privileges (e.g. access to the clipboard) or needs to run
applications which fail in this context, he'll probably even more
aware that this has serious security implications. 

Again I would avoid going into detail here, because this is beyond the
scope of the su tool and there is other literature available which
better explains these issues. (Pointers welcome, we could add them
below SEE ALSO).

> > +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"?

I updated the text accordingly, including the formatting for the user

Updated patch:

--- ./su.1.orig 2017-09-27 11:05:13.717361420 +0200
+++ ./su.1      2018-08-11 10:39:20.418324781 +0200
@@ -261,6 +261,33 @@
 session  required  pam_lastlog.so nowtmp
+Further for security reasons unlike the \fBsu\fR implementation in Debian 9 
and older releases, this \fBsu\fR implementation
+does not copy the X display address (DISPLAY) and credentials (XAUTHORITY) to 
the commands issued
+as the new identity. To allow
+graphical applications with the privileges of a different user
+(called \fIotheruser\fR in this example) graphical output while the X display 
is running for \fIlocaluser\fR several
+options exists. These are, in order of preference (security-wise):
+.RS 10
+Use a separate X display (e.g. using the keys Ctrl-Alt-Fx, using "Switch User" 
in GNOME, 
+or the equivalent fast-user-switching feature in other desktop environments), 
or a "thicker" remoting layer
+like VNC, Spice or Xpra.
+.B ssh (1), 
+e.g. "ssh -X -oForwardX11Trusted=no \fIotheruser\fR@localhost".
+Allow X display access for processes running as \fIotheruser\fR using
+.B xhost(1)
+to issue \fBxhost +si:\fIlocaluser\fR:\fIotheruser\fR in
+the originating X session and "DISPLAY=:0 command" under \fBsu\fR.
+This has serious security implications and hence should only be used in
+trusted environments.
 .BR setpriv (1),


      Dr. Helge Kreutzmann                     deb...@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

Attachment: signature.asc
Description: Digital signature

Reply via email to