Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 237778 - xorg-server doesn't build the XC-SECURITY extension, which causes ssh X11 tunnels to fail
Summary: xorg-server doesn't build the XC-SECURITY extension, which causes ssh X11 tun...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal with 2 votes (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: Inclusion
Depends on:
Blocks:
 
Reported: 2008-09-15 19:29 UTC by Joshua Roys
Modified: 2015-12-08 03:37 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
updated ebuild w/ xcsecurity USE flag (xorg-server-1.5.3-r1.ebuild,16.30 KB, text/plain)
2008-12-22 01:48 UTC, Alex Alexander (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Roys 2008-09-15 19:29:43 UTC
From xorg-server-1.5.0's configure.ac:
AC_ARG_ENABLE(xcsecurity,     AS_HELP_STRING([--disable-xcsecurity], [Build Security extension ***(default: disabled)***]), [XCSECURITY=$enableval], [XCSECURITY=no])

A strace of ssh (or just ssh -vvv) shows this xauth command being run:
/usr/bin/xauth -f /tmp/ssh-tmlUOx2553/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200

ssh shows this:
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.

Graphical applications fail to start on the remote system due to this.

When xauth is run by hand, the following is displayed:
/usr/bin/xauth:  creating new authority file /tmp/ssh-tmlUOx2553/xauthfile
/usr/bin/xauth: (argv):1:  couldn't query Security extension on display ":0.0"


Reproducible: Always

Steps to Reproduce:
1. ssh -X machine
2. xterm

Actual Results:  
The graphical app (xterm in this case) fails to start.

Expected Results:  
The app should be run and displayed on the local machine.
Comment 1 Donnie Berkholz (RETIRED) gentoo-dev 2008-09-16 11:01:37 UTC
Huh.

commit 1c6cb353f77747c101ce47716ff1fa055fbf85a4
Author: Eamon Walsh <ewalsh@tycho.nsa.gov>
Date:   Thu Nov 8 16:46:49 2007 -0500

    Restore the XC-SECURITY option in configure.ac, but disabled by default.
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2008-09-16 11:03:07 UTC
23:27 < dberkholz > anyone know why eamon disabled XC-SECURITY by default?
23:27 < dberkholz > it makes X over ssh unhappy
23:30 <   daniels > because it was about as useful as xedit
23:30 <   daniels > ssh's x support is very unhappy anyway.
23:31 <   daniels > 'oh my god it has SECURITY in the name.  this is AWESOME.  
                    we have to use it as much as possible.' 'but it's 
                    pointless!' 'YOU DON'T KNOW THE FIRST THING ABOUT SECURITY.'
Comment 3 Luca Barbato gentoo-dev 2008-09-16 11:39:32 UTC
try using ssh -Y should actually work correctly.
Comment 4 Joshua Roys 2008-09-16 16:01:21 UTC
From what I understand, -Y allows the remote computer to have more access to the local machine...  and personally, I operate under a hierarchy of trust if you will.  I only ssh from more trusted to less trusted machines.  Documentation suggests that -Y could allow keylogging and other types of remote monitoring.  Yes, I'm paranoid, but you kind of have to be IMHO.

A PDF on the extension:
http://www.xfree.org/current/security.pdf

Hmm, is there a problem in the extension though?  Looking at that IRC conversation seems to indicate a rather low point-of-view of the whole thing...
Comment 5 brent 2008-09-20 17:54:32 UTC
Just confirming. Same results.

Is this dependent on USE flags used, or is it part of the base ebuild?
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2008-10-04 07:31:00 UTC
Confirming, --enable-xcsecurity fixes the problem. But should we make it always enabled or based on some USEflag?
Comment 7 Steve Garcia 2008-10-17 18:55:07 UTC
If the user has "X" as a use flag, then xcsecurity should be included.
Comment 8 Donnie Berkholz (RETIRED) gentoo-dev 2008-11-01 22:39:26 UTC
Upstream X developers have chosen to disable it on their own expertise and judgment of its usefulness. I'm not going to go against that.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2008-11-06 13:41:49 UTC
Is this Debian or Gentoo? Is it really that hard to give users some USEflag, allowing their to enable compilation of this extension? The X developers have disabled this by default, but still allow users to reenable it. Why shouldn't we do the same?
Comment 10 Antti Mäkelä 2008-11-18 20:28:52 UTC
I also ran into this issue. Not really interested in putting ForwardX11Trusted yes to my ssh_config or running with -Y. The useflag would be nice.
Comment 11 Alex Alexander (RETIRED) gentoo-dev 2008-12-22 01:48:05 UTC
Created attachment 176119 [details]
updated ebuild w/ xcsecurity USE flag

ebuild with xcsecurity use flag which adds --enable-xcsecurity in configure options.
Comment 12 DanH 2009-06-16 10:41:21 UTC
(In reply to comment #2)

As daniels so charmingly puts it, I 'DON'T KNOW THE FIRST THING ABOUT SECURITY'.  But I do know that having xcsecurity, and therefore being able to get X11 tunneling in ssh -X without the -Y provides the following important (at least to me) convenience:

I often want to run an instance of Firefox on a remote ssh server.  In ssh -X (without the -Y), I can achieve this by just typing "firefox".  In ssh -X -Y, on the other hand, just typing "firefox" leads instead to the opening of a new tab in a Firefox running on the ssh client machine.  To achieve what I'm looking for then requires me to add some -a switch to the firefox command.

So, Alex: do you have a version of your amended ebuild that works for xorg-server 1.5.3-r6 (or later), please?

Thanks,

DanH <vi5u0-gentoobugs@yahoo.co.uk>
Comment 13 tazinblack 2009-07-04 11:37:53 UTC
When will this come into the regular ebuild(s)? With every new version I still have this old problem?
Comment 14 Rémi Cardona (RETIRED) gentoo-dev 2009-07-05 18:47:56 UTC
Please read this discussion about XC-SECURITY here : https://bugs.freedesktop.org/show_bug.cgi?id=2606

It looks to me that XC is _broken_ (it uses unsafe hash algorithms, among other flaws). If you want _security_, you should be using XACE along with something like SELinux.

Again, we won't change that because we'd be shipping code that's known to be broken and unsafe, and which nobody is still using. I honestly doubt XC is going to stay much longer in upstream's repo.

Thanks
Comment 15 DanH 2009-07-05 19:12:11 UTC
Rémi: ironically, my web browser won't let me see the page you cited, because it allegedly has an invalid security certificate.

But I think what you're saying is that the word "security" in the name of the XC_SECURITY option is misleading.  As I pointed out above, there are non-security-related reasons to want XC_SECURITY.  Perhaps we could have it under another name?

Thanks.

Regards,

Dan
Comment 16 tazinblack 2009-07-07 19:33:01 UTC
So should we better use something like telnet and export DISPLAY?

I think you should give it back to us until "unsafe hash algorithms" are replaced with something safe.

Better something with an unsafe hash algorithm than something complete insecure. 
Isn't it like that?
Comment 17 peyser.alex 2009-09-10 17:46:03 UTC
Thank to AA #12! This broke a clustering application I wrote/use -- and this keeps off the inevitable day when I have to make the code much uglier to appease the Upstream Gods -- the same guys who have decided that I may not have no encryption ssh, since they apparently are omniscient on all use cases.

Please keep the 1.5.3-r1 patches in the portage tree as long as possible -- r6 already doesn't compile with xsec on.

This is the same quality of thinking that leads facilities to put in seven layers of security, thereby causing users of the building to leave the back-door ajar. Sooner rather than later, folks will have to just turn off all xauth for use cases where multiple ssh'ing becomes intolerable or unavailable. Security is NOT primarily a function of the 'quality of hashes'.