On Tue, 2011-03-29 at 16:33 +0200, Reinhard Tartler wrote:
On Tue, Mar 29, 2011 at 15:35:32 (CEST), Dick Kniep wrote:
The problem is caused by the fact that the x2go server does not restrict the commands that can be entered thru ssh. This is bad, but what is worse, is that the X2go clients actually use this security hole to start any command it needs.
I don't get this. In the default setup, x2go is used to provide a full desktop environment like Gnome or KDE. There, I can of open some terminal emulator and also execute arbitrary commands like 'rm -rf *'.
What you explain would make sense in a locked-down kiosk-like environment.
I think the concerns are valid. I would love to see it addressable at the X2Go level but we took a different approach since our environment is exposed to the Internet and is also multi-tenant and, as Reinhard points out, the problem is not limited to X2Go and is part of the fundamental functionality.
We run all the X2Go servers in VServer guests and we use KDE in KIOSK mode. We also separate the user systems from the server farms and use micro-perimeter security with ISCS (http://iscs.sourceforge.net) but that's another story. The VServer guests have no root access and limited kernel privileges. Each X2Go server is dedicated to a single user. With VServer, that incurs minimal overhead. However, we did have to make major changes to X2Go to make it more efficient and more secure in that environment. I believe we documented those and shared them with the list over a year ago. We still have a few quirks but it is running fairly well and with reasonable security - John