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.
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.
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.'
try using ssh -Y should actually work correctly.
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...
Just confirming. Same results. Is this dependent on USE flags used, or is it part of the base ebuild?
Confirming, --enable-xcsecurity fixes the problem. But should we make it always enabled or based on some USEflag?
If the user has "X" as a use flag, then xcsecurity should be included.
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.
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?
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.
Created attachment 176119 [details] updated ebuild w/ xcsecurity USE flag ebuild with xcsecurity use flag which adds --enable-xcsecurity in configure options.
(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>
When will this come into the regular ebuild(s)? With every new version I still have this old problem?
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
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
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?
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'.