[X2Go-Dev] Bug#354: Bug#354: Bug#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf

[Mike Gabriel]

Hi Nick,

On  So 08 Dez 2013 16:13:02 CET, Nick Ingegneri wrote:

>> On Saturday, December 7, 2013 2:51 PM, Mike Gabriel  
>> <mike.gabriel at das-netzwerkteam.de> wrote:
>>
>> Control: tag -1 wontfix
>> Control: close -1
>>
>> Hi Stefan,
>>
>> On  Sa 07 Dez 2013 22:30:17 CET, Stefan Baur wrote:
>>
>>> [...]
>>
>>> Man, where are my pills, I don't want to go into full Theo de  
>>> Raadt mode ...
>>
>> Okokokok... heard!
>>
>> @Nick: please place a copy of x2gostartagent into
>>  /usr/local/bin for a transition period and modify it to your  
>> needs. We won't reenable TCP listening in upstream X2Go. For long  
>> term usage of X2Go, adapt your workflows to a more secure model.
>>
>> Mike

> Mike, Stefan, Alexander, et al.,
>
> I was watching this conversation play out before replying.
>
> It isn't going to be fruitful to be pulled into a long discussion  
> about the specifics of our compute environment. There are many  
> assumptions being made in this discussion that aren't correct, and  
> saying "don't use TCP" without knowing these specifics is ignorant.  
> There are industry-standard commercial products that disabling TCP  
> breaks. Our IT department cannot decide to stop supporting TCP; it  
> is the users and our commercial suppliers who determine what IT has  
> to support.
>
> I think that because I used "xhost +" in my original debugging  
> example, the assumption was immediately made that "xhost +" was my  
> primary concern. My primary concern is that disabling TCP
>  breaks almost every possible use model except for one narrow case  
> (ssh). Among other things, it breaks the MIT-MAGIC-COOKIE-1  
> mechanism. While there are very valid concerns regarding use of TCP  
> on the internet, we have a different hierarchy of concerns regarding  
> what happens on our internal network.
>
> One incorrect assumption that is being made in this discussion is  
> that some action to initiate the display can take place on the  
> system the user is logged into, or that the user is even involved in  
> initiating the display.  Consider this use model:
>
> 1: User's display is system100:24
> 2: Automated processes, with no user involvement, launch a program  
> on a randomly chosen system (let's say it is system204).
> 3: The new program running on system204 now has to connect back to  
> the display on system100:24
>
> Personally, the problem is solved for us for at least the moment and  
> we can move forward with what we are trying to do. Having to
>  edit /usr/bin/x2gostartagent every time we install or upgrade the  
> package is inelegant and creates additional administrative overhead,  
> but it is manageable.
>
> This is your project, not mine, I merely came to the mailing list  
> with a problem looking for a solution. I can tell you that our use  
> model is extremely common in industry and that breaking it will  
> render X2Go unusable. Of the five alternatives we are looking at,  
> X2Go was the only one with TCP disabled. Most system administrators  
> trying to set up an evaluation of X2Go aren't typically going to dig  
> further than the documentation and config files in trying to fix  
> this problem. If you make fixing it so obscure that it escapes these  
> system administrators, then X2Go isn't going to get very far in  
> those evaluations.
>
> How accessible or obscure you make this setting is up to you as  
> developers, but saying to users "your use model is wrong" doesn't  
> show appreciation for the diversity of ways that X is used in  
> production.
>
> Cheers,
> Nick

Thanks again for this valuable feedback. I must say, I am a little  
undecided on this. I have been working at a university institute where  
X-servers with TCP disabled also simply would have blocked all  
established workflows.

I will discuss this issue personally with Alex (Oleksandr Shneyder)  
and the two of use will then decide how to procede here.

@Stefan: I completely get your concerns, but I also here quite a big  
deal of paranoia. I am not working on X2Go to protect X2Go users from  
themselves, I am working on X2Go to provide a flexible remote desktop  
solution.

light+love,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20131209/4408e31d/attachment.pgp>