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

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

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

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

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

Thanks a lot for this interesting discussion.

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

Although I should comment this thing from the linked article: it begins with the following words: 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

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

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