X2Go Bug report logs - #354
Make x2goagent listening to TCP connections configurable in x2goserver.conf

[Message part 1 (text/plain, inline)]
Package: x2goserver
Severity: wishlist
Debbugs-Cc:

Make x2goagent listening to TCP connections configurable in x2goserver.conf.

This was requested by Nick Ingegneri on x2go-user ML.

Mike
-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Hi Stefan,

On  Fr 06 Dez 2013 12:57:34 CET, Stefan Baur wrote:

> Am 06.12.2013 12:21, schrieb Mike Gabriel:
>
>> Make x2goagent listening to TCP connections configurable in
>> x2goserver.conf.
>
>> This was requested by Nick Ingegneri on x2go-user ML.
>
> IIRC, nolisten TCP was set for security reasons
> (Message-ID:  
> <20120512013211.50944typ0bgbjypn@mail.das-netzwerkteam.de>, Date:  
> Sat, 12 May 2012 01:32:11 +0200 might trigger some memories ...).
>
> Are we sure we want to make that option available?

The default should be ,,disabled'', of course. However, I think that  
we should support people that want to use X2Go in their setup as a  
replacement for *NX*. Making something configurable and putting a big  
red warning sign above the configuration should be ok IMHO.

Feedback?
Mike
-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
Am 06.12.2013 12:21, schrieb Mike Gabriel:

> Make x2goagent listening to TCP connections configurable in
> x2goserver.conf.

> This was requested by Nick Ingegneri on x2go-user ML.

IIRC, nolisten TCP was set for security reasons
(Message-ID: <20120512013211.50944typ0bgbjypn@mail.das-netzwerkteam.de>, 
Date: Sat, 12 May 2012 01:32:11 +0200 might trigger some memories ...).

Are we sure we want to make that option available?

-Stefan


Am 06.12.2013 13:06, schrieb Mike Gabriel:

>> IIRC, nolisten TCP was set for security reasons
[...]
> The default should be ,,disabled'', of course. However, I think that we
> should support people that want to use X2Go in their setup as a
> replacement for *NX*. Making something configurable and putting a big
> red warning sign above the configuration should be ok IMHO.

http://www.youtube.com/watch?v=tsXEToflqGs
(Can't watch videos/don't have sound while you're reading this? Go here 
for a textual description: http://tinyurl.com/3dhhzb)

-Stefan


Am 06.12.2013 13:06, schrieb Mike Gabriel:
> The default should be ,,disabled'', of course. However, I think that we
> should support people that want to use X2Go in their setup as a
> replacement for *NX*. Making something configurable and putting a big
> red warning sign above the configuration should be ok IMHO.

> Feedback?

Is there no way of assisting this user in migrating away from NX, other 
than raping our codebase like that?

What's wrong with using ssh -X / ssh -Y, which was previously suggested 
to the user?

Maybe some more information on what the user is trying to accomplish 
would help us come up with a better solution.

-Stefan


[Message part 1 (text/plain, inline)]
Hi Mike, Stefan,


Since I'm the one who brought this up, I'll try to be an advocate for why this change is a good thing for certain users.


We are evaluating X2Go for use in an existing corporate technical compute environment. There is a shortcoming in our current thin client solution (not NX) and we need to identify a replacement. This environment contains hundreds of users, hundreds of systems, dozens of applications, and an uncountable number of scripts. X2Go is being considered against several alternatives.

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. Simply put, any thin client solution we deploy has to support TCP connections if it is to meet our requirement of not disrupting how work is currently done.

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.

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.

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).

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.

Thanks,
Nick





On Friday, December 6, 2013 5:16 AM, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
 
Am 06.12.2013 13:06, schrieb Mike Gabriel:
> The default should be ,,disabled'', of course. However, I think that we
> should support people that want to use X2Go in their setup as a
> replacement for *NX*. Making something configurable and putting a big
> red warning sign above the configuration should be ok IMHO.

> Feedback?

Is there no way of assisting this user in migrating away from NX, other 
than raping our codebase like that?

What's wrong with using ssh
 -X / ssh -Y, which was
 previously suggested 
to the user?

Maybe some more information on what the user is trying to accomplish 
would help us come up with a better solution.


-Stefan
[Message part 2 (text/html, inline)]
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


On 13-12-06 19:18, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
> Am 06.12.2013 18:44, schrieb Nick Ingegneri:
> >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.

There is one more aspect to this: If there is such a configuration
option, then sooner or later the likes of Linux Mint will enable it by
default for all their users, leaving them wide open to the whole world,
despite all the warnings. They did that with 'xhost +'[0].

So I agree that even just having such an option hidden away somewhere
would be very very bad. It needs to be hard and a lot of work to break
security or somebody will do it by default and deploy it on a wide
scale.



Ciao,

Alexander Wuerstlein.

[0] http://forums.linuxmint.com/viewtopic.php?f=90&t=106520


[Message part 1 (text/plain, inline)]
Hi Stefan, hi Alexander,

On  Fr 06 Dez 2013 20:56:00 CET, Alexander Wuerstlein wrote:

> On 13-12-06 19:18, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
>> Am 06.12.2013 18:44, schrieb Nick Ingegneri:
>> >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.
>>

>> [...]

>> 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.
>
> There is one more aspect to this: If there is such a configuration
> option, then sooner or later the likes of Linux Mint will enable it by
> default for all their users, leaving them wide open to the whole world,
> despite all the warnings. They did that with 'xhost +'[0].
>
> So I agree that even just having such an option hidden away somewhere
> would be very very bad. It needs to be hard and a lot of work to break
> security or somebody will do it by default and deploy it on a wide
> scale.
>
>
>
> Ciao,
>
> Alexander Wuerstlein.
>
> [0] http://forums.linuxmint.com/viewtopic.php?f=90&t=106520

From a security point of view: is there really a severe difference in  
having to edit x2gostartagent or vs. x2goserver.conf as root to enable  
TCP listening for x2goagent? If people want to deploy X2Go and need  
TCP enabled they will do that anyway. You do not have to rebuild some  
binary to make that happen even, you just have to create a custom copy  
of x2gostartagent in /usr/local/bin.

@Nick: The above may very well be your workaround...

>> 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.

My current focus is to spread X2Go, get more people interested in X2Go  
and get more people interested in developing / financing X2Go. If I  
here of a use case that involves hundreds of users, then I am open to  
supporting that use case one way or another. I don't think making  
TCP-listening configurable is a security problem. Once you enable that  
option, you should be aware of what you are doing. For sure.

The Linux Mint argument does not really count to me, either. As a  
package maintainer of a linux distribution, I can do anything patchy  
to the upstream code I like. People with the Linux Mint attitude may  
very easily patch x2gostartagent and ship a TCP-listening X2Go Server  
by default in their package archive. Wouldn't it make more sense,  
having that option configurable from the start then and providing the  
switch-off in an obvious place (i.e. a conffile)?

My point is: if you want to enable TCP listening of x2goagent, you  
have to switch one line in x2gostartagent. What I propose is a config  
parameter for x2goserver.conf that avoids people from nastily hacking  
x2gostartagent. I know several setups in intranet where display  
managers and X-servers run in TCP listen mode and for the local  
network that is ok and wanted. Of course for X2Go this should not be  
the default (that's why we closed down TCP listening earlier when it  
was still enabled by accident).


And Nick, I also think that you should seriously consider looking at  
the security aspects of your current IT setup. It seems quite hackable  
and you should really be sure that all of your staff members are  
really good friends (which normally is not the case for everyone at  
$WORK).


Greets,
Mike

-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
Am 07.12.2013 21:47, schrieb Mike Gabriel:

[copying the last paragraph of your mail to the top, b/c this is the 
most important statement of it]
> And Nick, I also think that you should seriously consider looking at
> the security aspects of your current IT setup. It seems quite
> hackable and you should really be sure that all of your staff
> members are really good friends (which normally is not the case
> for everyone at $WORK).

This, this, and exactly this.


[by Alexander Wuerstlein]
>> So I agree that even just having such an option hidden away somewhere
>> would be very very bad. It needs to be hard and a lot of work to break
>> security or somebody will do it by default and deploy it on a wide
>> scale.

[from Mike]
>  From a security point of view: is there really a severe difference in
> having to edit x2gostartagent or vs. x2goserver.conf as root to enable
> TCP listening for x2goagent?

Yes, there is. Putting it in the config file is convenient for the 
security-ignorant folks. Disabling security features should never be 
convenient.


> If people want to deploy X2Go and need TCP
> enabled they will do that anyway. You do not have to rebuild some binary
> to make that happen even, you just have to create a custom copy of
> x2gostartagent in /usr/local/bin.

And exactly that means extra work. Most security-ignorant folks are 
security-ignorant because they are lazy, they just don't want to bother 
with it.
A config file remains in place during package upgrades.
With x2gostartagent, they'll have to make sure that their copy in 
/usr/local/bin gets pulled (And we should make it hard for them, by 
specifying /usr/bin/x2gostartagent instead of x2gostartagent without a 
path), or they have to change/patch /usr/bin/x2gostartagent with every 
new package version.

This means work. This means paying attention. Things that such folks 
don't like. In fact, if we could, we should make disabling security on 
X2Go a harder and more complex task than re-writing all those insecure 
scripts the user might have. Sadly, we can't.


> @Nick: The above may very well be your workaround...

And indeed it is, for a short-lived migration path.


>>> 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.
>
> My current focus is to spread X2Go, get more people interested in X2Go
> and get more people interested in developing / financing X2Go. If I here
> of a use case that involves hundreds of users, then I am open to
> supporting that use case one way or another. I don't think making
> TCP-listening configurable is a security problem. Once you enable that
> option, you should be aware of what you are doing. For sure.

I'm saying it again, you're being too customer-friendly. In this 
particular case, the issue can be fixed by locally patching 
x2gostartagent. With more obscure stuff, you should tell them to 
contract you or Alex for a forked x2go package and have them pay for the 
B**ls**t they want. That way, we don't pollute our main codebase with 
it, plus you get some extra cash.

Man, where are my pills, I don't want to go into full Theo de Raadt mode ...


> The Linux Mint argument does not really count to me, either. As a
> package maintainer of a linux distribution, I can do anything patchy to
> the upstream code I like. People with the Linux Mint attitude may very
> easily patch x2gostartagent and ship a TCP-listening X2Go Server by
> default in their package archive.

See above, it is extra work for them, an extra file outside the config 
tree that they have to monitor for changes, etc. While we can't stop 
them, we can at least make it hard for them to follow through with such 
a plan.


> Wouldn't it make more sense, having
> that option configurable from the start then and providing the
> switch-off in an obvious place (i.e. a conffile)?

No. Just no.


> My point is: if you want to enable TCP listening of x2goagent, you have
> to switch one line in x2gostartagent. What I propose is a config
> parameter for x2goserver.conf that avoids people from nastily hacking
> x2gostartagent.

Again, those who know what they are doing are already able to make the 
change, and should realize the consequences (having to look for changes 
in x2gostartagent with every new release).

Those who do not know what they are doing should not be given access to 
the setting.

There's a reason why you need licenses for firearms, cars, airplanes, 
etc. - and this is the software equivalent.
If one has proven enough coding proficiency to have located the code 
part in x2gostartagent, one is worthy of being allowed to change it on 
one's own.
If you have to ask here, you should either listen to the more 
experienced folks telling you not to change it, or pay one of the core 
developers for a fork, that's my opinion (and not being a core developer 
myself, flames like "you're a greedy a**h**e that thinks of X2Go users 
as cash cows ready for milking" directed at me are outright silly, so - 
shove them, folks).

-Stefan


[Message part 1 (text/plain, inline)]
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
-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
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






On Saturday, December 7, 2013 2:51 PM, Mike Gabriel <mike.gabriel@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
-- 

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

GnuPG Key ID 0x25771B31

mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
[Message part 2 (text/html, inline)]
Am 08.12.2013 16:13, schrieb Nick Ingegneri:
> 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.

[long blahblah snipped]

If you believe Xauth Cookies alone will protect you from nastiness, 
think again:
http://www.hackinglinuxexposed.com/articles/20040608.html - "Abusing X11 
for fun and passwords."

All the nastiness shown in that write-up works *with* .Xauthority in place.
And this was published in 2004, so every script kiddie, every 
pimple-faced youth among your trainees, every disgruntled employee knows 
about this. (And so does the NSA.)

Seriously, I've been in the IT Security business for quite a few years 
*ahem ahem* - and the real enemy usually isn't some obscure Chinese 
hacker, it's an employee, either a lazy and careless one or a malicious 
one that has been turned over by a competitor. So do not trust anyone 
and anything on your network. Encrypt even your internal traffic.
I've even seen reports of power plugs with surge protectors containing 
Network sniffers. So the spying device has unlimited power supply and 
sits right in your network, logging all your traffic and sending it out 
either via innocuous http requests or via a seperate WiFi network.

And please, do not fool yourself into thinking "but we don't have 
anything to hide". Yes, you have. We all have. Unless you see "1984" as 
an instruction manual.

-Stefan


Thanks a lot for this interesting discussion.

Although I should comment this thing from the linked article: it
begins with the following words:
> log into the victim's desktop, become root
It's too obvious that with root one can do almost anything, not only
grab X sessions.
So, you article is not a proof of X11 insecurity (after all, we know
that it's not secure, but example is not good), just a howto for root
usage.
One should notice that without root ( who would give root access to
generic employee? except (possibly) on his workstation) you still
cannot access other users' cookies (except cases when one have too
wide permissions or known vulnerabilitites with privelege escalation),
so you cannot grab their X sessions, can you?

2013/12/8, Stefan Baur <newsgroups.mail2@stefanbaur.de>:
> Am 08.12.2013 16:13, schrieb Nick Ingegneri:
>> 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.
>
> [long blahblah snipped]
>
> If you believe Xauth Cookies alone will protect you from nastiness,
> think again:
> http://www.hackinglinuxexposed.com/articles/20040608.html - "Abusing X11
> for fun and passwords."
>
> All the nastiness shown in that write-up works *with* .Xauthority in place.
> And this was published in 2004, so every script kiddie, every
> pimple-faced youth among your trainees, every disgruntled employee knows
> about this. (And so does the NSA.)
>
> Seriously, I've been in the IT Security business for quite a few years
> *ahem ahem* - and the real enemy usually isn't some obscure Chinese
> hacker, it's an employee, either a lazy and careless one or a malicious
> one that has been turned over by a competitor. So do not trust anyone
> and anything on your network. Encrypt even your internal traffic.
> I've even seen reports of power plugs with surge protectors containing
> Network sniffers. So the spying device has unlimited power supply and
> sits right in your network, logging all your traffic and sending it out
> either via innocuous http requests or via a seperate WiFi network.
>
> And please, do not fool yourself into thinking "but we don't have
> anything to hide". Yes, you have. We all have. Unless you see "1984" as
> an instruction manual.
>
> -Stefan
> _______________________________________________
> X2Go-Dev mailing list
> X2Go-Dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/x2go-dev
>


Am 08.12.2013 21:05, schrieb Nable 80:
> One should notice that without root ( who would give root access to
> generic employee? except (possibly) on his workstation) you still
> cannot access other users' cookies (except cases when one have too
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> wide permissions or known vulnerabilitites with privelege escalation),
  ^^^^^^^^^^^^^^^^
> so you cannot grab their X sessions, can you?

And here we are again at "Hey, $FOO doesn't work, I'll just do chmod -R 
777 * and see if that makes it work."

Plus, the rogue employee may as well be the admin, and thus have root 
rights on the machine where you're logged in.

-Stefan


[Message part 1 (text/plain, inline)]
Hi Stefan,

On  So 08 Dez 2013 21:10:57 CET, Stefan Baur wrote:

> Am 08.12.2013 21:05, schrieb Nable 80:
>> One should notice that without root ( who would give root access to
>> generic employee? except (possibly) on his workstation) you still
>> cannot access other users' cookies (except cases when one have too
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> wide permissions or known vulnerabilitites with privelege escalation),
>   ^^^^^^^^^^^^^^^^
>> so you cannot grab their X sessions, can you?
>
> And here we are again at "Hey, $FOO doesn't work, I'll just do chmod  
> -R 777 * and see if that makes it work."
>
> Plus, the rogue employee may as well be the admin, and thus have  
> root rights on the machine where you're logged in.
>
> -Stefan

For X2Go we must assume that the root user is a trustworthy person.  
Otherwise we are completely lost.

Mike


-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
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@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@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Control: reopen -1
Control: tag -1 - wontfix

Hi all,

On  Mo 09 Dez 2013 09:08:29 CET, Mike Gabriel wrote:

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

I have talked to Alex. We will implement a config option that enables  
TCP listening of x2goagent. There will be a big red sign in the config  
and the default will be to TCP-nolisten.

light+love
Mike

-- 

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

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]
tag #354 pending
fixed #354 4.0.1.10
thanks

Hello,

X2Go issue #354 (src:x2goserver) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:

    http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=13ec71f

The issue will most likely be fixed in src:x2goserver (4.0.1.10).

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
commit 13ec71f7df3efae239c2dbe96a5abe9370fa7b2f
Author: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Date:   Tue Dec 10 09:36:44 2013 +0100

    Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).

diff --git a/debian/changelog b/debian/changelog
index 3a54b9d..9c562e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,7 @@ x2goserver (4.0.1.10-0x2go1) UNRELEASED; urgency=low
     - x2goserver-fmbindings/Makefile: install share/applications and share/mime.
     - x2goserver-printing/Makefile: create feature.d directory before installing
       files into it.
+    - Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).
   * Grab systemd service file from Fedora and ship it upstream.
   * Add init script for RPM based distro. Taken from the Fedora
     package.


close #354
thanks

Hello,

we are very hopeful that X2Go issue #354 reported by you
has been resolved in the new release (4.0.1.10) of the
X2Go source project »src:x2goserver«.

You can view the complete changelog entry of src:x2goserver (4.0.1.10)
below, and you can use the following link to view all the code changes
between this and the last release of src:x2goserver.

    http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=1a793e3d843bbeee3e597c762d9fe1d19c97baa7;hp=f26122424320ebdb563af072fc89cc03ce8bc158

If you feel that the issue has not been resolved satisfyingly, feel
free to reopen this bug report or submit a follow-up report with
further observations described based on the new released version
of src:x2goserver.

Thanks a lot for contributing to X2Go!!!

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
X2Go Component: src:x2goserver
Version: 4.0.1.10-0x2go1
Status: RELEASE
Date: Fri, 03 Jan 2014 11:34:36 +0100
Fixes: 354 355
Changes: 
 x2goserver (4.0.1.10-0x2go1) RELEASED; urgency=low
 .
   * New upstream version (4.0.1.10):
     - Fix x2goresume-session. The several parameters placed into the NX options
       file are expected by x2goresume-session at very specific positions. This
       we broke by trying to fix the fullscreen/geometry issue in x2gostartagent.
       Thanks to Harvey Eneman for tracking this down!!! (Fixes: #355).
     - x2goserver-fmbindings/Makefile: install x2gofm.
     - x2goserver-fmbindings/Makefile: install share/applications and share/mime.
     - x2goserver-printing/Makefile: create feature.d directory before installing
       files into it.
     - Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).
     - Clean up Makefiles, remove commented out lines.
     - Use xkb ruleset 'base' rather than xfree86 as on RHEL systems the
       xfree86 symlink to base ruleset does not exist.
     - Grab systemd service file from Fedora and ship it upstream.
     - Provide RHEL/Fedora support in x2goserver-xsession.
     - Only sanity check for existence of /etc/x2go/Xsession.d on Debian
       (derived) systems.
     - Provide man page for x2goserver.conf.
   * x2goserver.spec:
     + Ship x2goserver.spec (RPM package definitions) in upstream project.
       (Thanks to the Fedora package maintainers). File differs from the Fedora
       file already.
     + Add init script for RPM based distro. Taken from the Fedora
       package.
     + Clear (Fedora package) changelog.


[Message part 1 (text/plain, inline)]
Hello,
        With the support of setting this option through x2goagent.options,
the way we previously worked around this issue no longer work's and I am
not able to make tcp X forwarding work with the new option's file setting.
 Am I missing something. In the mean time is there a way we can downgrade
back to the previous server version?

-- 
-Dustin Foudray

[Message part 2 (text/html, inline)]
[Message part 1 (text/html, inline)]
[Message part 1 (text/html, inline)]
[Message part 1 (text/html, inline)]
[Message part 1 (text/html, inline)]
[Message part 1 (text/html, inline)]

X2Go Bug report logs - #354 Make x2goagent listening to TCP connections configurable in x2goserver.conf

X2Go Bug report logs - #354
Make x2goagent listening to TCP connections configurable in x2goserver.conf