From unknown Fri Mar 29 06:40:30 2024 X-Loop: owner@bugs.x2go.org Subject: Bug#354: [X2Go-Dev] Bug#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf Reply-To: Stefan Baur , 354@bugs.x2go.org Resent-From: Stefan Baur Resent-To: x2go-dev@lists.berlios.de Resent-CC: X2Go Developers X-Loop: owner@bugs.x2go.org Resent-Date: Fri, 06 Dec 2013 18:18:02 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.x2go.org X-X2Go-PR-Message: followup 354 X-X2Go-PR-Package: x2goserver X-X2Go-PR-Keywords: Received: via spool by 354-submit@bugs.x2go.org id=B354.13863532871790 (code B ref 354); Fri, 06 Dec 2013 18:18:02 +0000 Received: (at 354) by bugs.x2go.org; 6 Dec 2013 18:08:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_PASS autolearn=ham version=3.3.2 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ymir (Postfix) with ESMTP id E739E5DB05 for <354@bugs.x2go.org>; Fri, 6 Dec 2013 19:08:06 +0100 (CET) Received: from [192.168.0.3] (HSI-KBW-149-172-200-27.hsi13.kabel-badenwuerttemberg.de [149.172.200.27]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MBWuQ-1Vgmci1D42-00Aedj; Fri, 06 Dec 2013 19:08:06 +0100 Message-ID: <52A21285.7090407@stefanbaur.de> Date: Fri, 06 Dec 2013 19:08:05 +0100 From: Stefan Baur User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Nick Ingegneri , Mike Gabriel CC: "354@bugs.x2go.org" <354@bugs.x2go.org>, "x2go-dev@lists.berlios.de" References: <20131206112155.Horde.SbfwdHK-kyPj8MElQt3mrQ1@mail.das-netzwerkteam.de> <52A1BBAE.90909@stefanbaur.de> <20131206120625.Horde.SkFUuwsrCrkJ3OMw64wKaA1@mail.das-netzwerkteam.de> <52A1C089.3090709@stefanbaur.de> <1386351855.74486.YahooMailNeo@web122101.mail.ne1.yahoo.com> In-Reply-To: <1386351855.74486.YahooMailNeo@web122101.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:7QTiC4V0GJYsiyBd28up5rrpdgF3VjB59MnWQvaDTNG ZCfnBAqDZQsZue1y7AMkwUAtG3EY7n6HnUtGhqAdKjjug+fj9T n3ITSqA0IO7kgClA3y3nLppvM78Yy0ViGv2Od1mE9O85nmEnyk zxi4/Jz9CfL5JqweGrqQJ1kvlPu6nmaC4mNkWe6xaZHQ+FC2WB E7HxtqJKYqdY2cku0+9XdZkEzEwrvqxvb6cdTdpoocUb4elirQ KoHdCwbAjvb0ZkAi6RxwV+NvpB+hGRTCdYarznsVV0fRiWWgkN /eJ0H3o8ysUgr9oOv+j1hO3tvpkIlYURNXywIZT+DtpNEVkjUO j6N9n3ZC4hnAtf24SxbTUwzkctlc0KxOdaMdaiNre Am 06.12.2013 18:44, schrieb Nick Ingegneri: > Whatever solution we choose has to work within the existing environment > and support the existing workflow. Our current workflow uses a mixture > of xhost and xauth to allow xclients to connect to xservers. While "ssh > -Y" may technically be an elegant solution, requiring it would break our > existing tools, processes, and scripts. Well, guys, it's 2013, almost 2014, and we live in the Post-NSA-Scandal world. The times of using "xhost +" and not having to worry about it are long over. Do yourself a favor and change your scripts. > I acknowledge that there is a security issue with TCP connections in > X11, but that is an architectural issue with X11 itself and not with > X2Go per se. If the developers of X2Go were to make TCP connections > impossible then effectively the defined security model of X11 (as > documented in places like the XSecurity and Xauth man pages) would be > broken. TCP is part of how X11 works. As a side-note, I hope you're aware that those newfangled GUI thingies like Wayland and Mir are ditching TCP in their core design? Just sayin' (I don't like them, either) - not that that comes to bite you in the lower back in a few years when you don't expect it. > Once it became apparent in our testing that exporting displays didn't > work as expected, the system administrator who installed it went through > the configuration files and documentation looking for a solution. He > couldn't find one, so he escalated it to me to look into. If we hadn't > been able to find a fix it would have ruled out X2Go from further > consideration, which would have been unfortunate as it is currently our > leading choice for this particular need. In my opinion, Mike is a bit too customer-friendly here by turning your request into a wishlist item that lets every newbie shoot him-/herself in the foot, security-wise, by toggling a setting in the configuration. Sorry, but I've seen way too many people go "chmod 777 -R /*" as soon as something doesn't work as expected, and I'm fearing the same for an easily reachable option to allow TCP connections - because "xhost +" is the X/TCP equivalent of "chmod 777 -R /*" in the filesystem. Of course, everybody is free to shoot him-/herself in the foot, that's why it's Linux - but merely leaving a "this is dangerous" note next to the parameter is like sticking a tag "please don't use this unless you know what you're doing" on a loaded 12-gauge in a room full of toddlers. > Hopefully the above helps persuade you that there is a need for some > users to be able to continue to support the existing X11 security model > (including TCP). Sorry, but you don't have me convinced that this is something anyone should use for a prolonged period of time. > If you accept that point, then it seems there should be a more elegant > way of enabling TCP than editing the x2gostartagent file. As someone > brand new to looking at the project, files like x2goagent.options or > x2goserver.conf are the obvious places I would expect to find an option > to make this change. My understanding of the issue is: It's possible to allow TCP connections, and the fact that it's not easily reachable - but can be reached - is a Good Thing(TM). We should leave it that way. You can manually allow TCP connections in your environment to ease transition to X2Go - but by all means, go ahead and fix your scripts so they use ssh -X/-Y, and do that soon. And reconfigure X2Go to "nolisten TCP" the second you're done fixing your scripts. -Stefan