The problem: Although either of two basic utilities, sudo or su, makes it easy for a host admin to run a console process with root-user authority without being logged in as root, running an X11 graphical application as root from a non-root login session is more difficult because root's X11 authentication and related DISPLAY and XAUTHORITY (which points to a user's MIT magic cookie token, normally in ~/.Xauthority) environment variables aren't (and normally should not be) forwarded to the non-root user.

Because on rare occasional there's no good alternative to running a graphical application with root privilege (obviously risky), wrapper tools exist to forward the auth token and environment variables. They are covered below. (Alternatively, one can handle those details manually, which is also covered.) Wrapper tools & similar methods:





From: Jean Christophe ANDRÉ (jean-christophe.andre@auf.org)
To: debian-security@lists.debian.org
Subject: allowing X display from su'd environment
Organization: Agence universitaire de la Francophonie / Bureau Asie-Pacifique / Viêt Nam
Date: Sat, 9 Nov 2002 12:40:12 +0700

Yogesh Sharma wrote:

>> I am using woody + testing + some unstable:
>> in xterm/gnome-terminal usually I do (as normal user) xhost +

Matt Zimmerman ?crivait :
> This disables access control in the X server. This is, almost always,
> a very bad idea.

A better way to allow it (when you switch from normal to root user) :

test@localhost:~$ su -
root@localhost:~# xauth merge ~test/.Xauthority
root@localhost:~# export DISPLAY=:0.0
root@localhost:~# xterm #or whatever Xwindow program you want to run

I can remember there was some 'su' feature doing it automagically somewhere (with Red Hat, Mandrake or another one)...

Cheers, J.C.




From: Matt Zimmerman (mdz@debian.org)
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Date: Sat, 9 Nov 2002 10:41:05 -0500

An easier wethod:

$ su
# export XAUTHORITY=~user/.Xauthority




From: Michael Eyrich eyrich@ee.tu-berlin.de
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Organization: Telecommunication Networks Group (TKN), TU Berlin, Germany
Date: Sat, 9 Nov 2002 17:00:23 +0100

On Sat, Nov 09, 2002 at 10:41:05AM -0500, Matt Zimmerman wrote:

| An easier wethod:
|
| $ su
| # export XAUTHORITY=~user/.Xauthority

This won't work, if ~user is NFS-mounted with the 'root_squash'-option, because 'nobody' won't be allowed to read ~users .Xauthority.

Regards,
Michael




From: Matt Zimmerman (mdz@debian.org)
To: debian-security@lists.debian.org
Subject: Re: allowing X display from su'd environment
Date: Sat, 9 Nov 2002 11:32:14 -0500

It also won't work if SE Linux or RSBAC access controls forbid root from reading this file, or if the user's X authority tokens are not in ~/.Xauthority, or any number of other reasons. The point was that it is simple. Anyone running a largish multiuser system with NFS-mounted home directories already understands these issues. Others are asking questions.




From: Rick Moen (rick@linuxmafia.com)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Sat, 9 Nov 2002 02:02:49 -0800

It's a little simpler to do:

$ ssh -Y root@localhost

2019 note: Prior to around 2008, that would have been -X rather than -Y, but -X is now restricted by the (newer) X11 SECURITY extension. I have retroactively edited all 'ssh -X' references on this page to 'ssh -Y', accordingly.

Important warning: When you use 'ssh -Y remotehost', remotehost is treated as a trusted X11 client. This option can open security problems, because it then has permission to screenshot, keylog, and inject input into all the windows of other X11 client programs. Also, it can then use all X server extensions, including ones like accelerated graphics, which are security exposures. You are essentially trusting the remote processes (run via ssh) on remotehost to be as safe as your other local programs. By contrast, using 'ssh -X remotehost' treats remotehost as an untrusted X11 client, restricting it to access only its own information, and use only those parts of the X protocol that are relatively secure.

Above is true if the machine where you run /usr/bin/ssh has "ForwardX11Trusted no" set in ssh_config, which is best practices. Some distributions, such as some releases of Ubuntu Linux, fail to define "ForwardX11Trusted no", and therefore extend the same broad security access to "ssh -X" as to "ssh -Y".

Note: The post-2009 security improvement to the handling of 'ssh -X remotehost', where client functionality is subjected to the revised SSH SECURITY restrictions, occurs only if /etc/ssh/ssh_config contains the line "ForwardX11Trusted no". Otherwise, the -X option, like the -Y option, results in a trusted X11 client. (Some Linux distributions, such as Ubuntu Linux 14.04 LTS, omit that improvement as a deliberate policy choice to avoid breaking expected ssh -X functionality.)

Where the target host is localhost, obviously you want a trusted X11 client.




From: Martin Fluch (fluch@rock.helsinki.fi)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Sat, 9 Nov 2002 13:36:25 +0200 (EET)

Even easier: the following lines in the /root/.bashrc do the same trick:

if [ ! "$LOGNAME" = "root" ]; then
export XAUTHORITY=/home/$LOGNAME/.Xauthority
fi

And then su works without any problem (and computational overhead as the ssh solution).

Cheers,
- Martin




From: Jörg Schütter (joerg@schuetter.org)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
X-Mailer: Sylpheed version 0.8.5claws56 (GTK+ 1.2.10; )
Date: Sat, 9 Nov 2002 14:12:08 +0100

On Sat, 9 Nov 2002 13:36:25 +0200 (EET)
Martin Fluch (fluch@rock.helsinki.fi) wrote:

> Even easier: the following lines in the /root/.bashrc do the same
> trick:
>
> if [ ! "$LOGNAME" = "root" ]; then
> export XAUTHORITY=/home/$LOGNAME/.Xauthority
> fi

This solution doesn't work with "su -"

> And then su works without any problem (and computational overhead as
> the ssh sollution).

You can decrease the "overhead" with ssh -c des -Y root@localhost

Cheers,
Jörg




From: Christian Jaeger (christian.jaeger@ethlife.ethz.ch)
To: debian-security@lists.debian.org
Subject: Re: su and x (was Re: XFree86 4.2 bug in Debian Testing)
Date: Sat, 9 Nov 2002 14:36:01 +0100

Try http://fgouget.free.fr/sux/sux-readme.shtml

chj




RM adds: Similar to "sux" are GKsu / GKsudo, kdesu, ktsuss, beesu, suex, and xsu. (However, as of 2019, GKsu aka gksu has been unmaintained code for several years, and is dropping out of use.)




From: Peter Cordes (peter@llama.nslug.ns.ca)
To: debian-security@lists.debian.org
Subject: Re: XFree86 4.2 bug in Debian Testing
Date: Mon, 11 Nov 2002 17:06:57 -0400

On Fri, Nov 08, 2002 at 05:28:52PM +0100, Ivan Brezina wrote:

> Another possibility is:
> su -c vim-gtk
>
> you can also use xhost +username for allowing users to connect to our
> Xserver. But this does not work for me on Debian.

xhost is host based access control, so of course xhost +username doesn't work! Debian by default starts X servers with -nolisten tcp, so doing xhost + (to allow all connections) is the same as xhost +localhost, and is ok if (and only if) there are no local users you don't absolutely trust (including trusting them not to get their accounts cracked with bad passwords).

I emphatically do not recommend using ssh running X stuff as root. That is huge overhead compared to unix sockets and shared memory! (If it's working fine for you, then whatever, do what's easiest for you, but if you're going to go to the trouble of learning how to jump through a hoop to get X working, pick the right hoop!)




From: "Michael Wenk" (mikewenk@attbi.com)
To: vox-tech@lists.lugod.org
Subject: Re: [vox-tech] vim question
Date: Tue, 12 Nov 2002 22:36:00 -0800

If you're su'd and execute any X app, it will give that error, because root doesn't have permissions for X. I used to see this while running emacs, but then emacs would go into non-windowed mode. If you "xhost +root", then you'll be fine.




Date: Tue, 07 Sep 2004 11:23:31 -0700
From: Jeffrey Siegal (jbs@quiotix.com)
To: svlug@lists.svlug.org
Subject: Re: [svlug] couldn't connect to display ":0.0"

Another solution is to have pam_xauth configured on your system. Then it just works.




[RM comments: Despite what Peter Cordes wrote (3rd message up) about xhost being host-based access control only, the xhost manpage makes clear that the name following the "+" can be either the host or the user to be added to the list allowed to connect to the X server. On reflection, then, Michael's suggestion seems the most elegant, easiest, least-security-risky, and best-performing method. However, I often fall back on "ssh -Y root@localhost" as an alternative, mostly because it generalises so perfectly to cross-host access without the need to stop and think: The "overhead" objection is entirely bogus on post-486 machines, in my experience.]




From: Yves-Alexis Perez (corsac@debian.org)
To: debian-security@lists.debian.org
Date: Sat, 09 Feb 2008 22:05:34 +0100
Subject: setuid binary in ktsuss

I'm about to upload ktsuss to debian, wich is a graphical wrapper around su (much like gksu but without any gnome dependency). One point puzzles me, the ktsuss binary is setuid root (so it can read the root password). gksu doesn't do this (it calls su, I guess).

I don't really want to upload a setuid binary if it's not safe, but the code looks good (and is really tiny). Could some people on this list take some time and check the code?

dsc can be found at:
http://molly.corsac.net/~corsac/debian/ktsuss_1.3-1.dsc