Hi list,
In the past few month, Mike has developed a very nice python client for x2go that caters to our need as a Application service provider. However during that period, we have investigated the security of X2go and it proves that X2go is an insecure product if used in a hostile environment like the Internet.
I know many of you are wondering: But we are using ssh, how can that be insecure? Well, as many of you know, one can connect to a server with ssh with a terminal and execute commands on that server, including commands like rm -Rf * or other commands. Even if the shell is disabled, it is still possible to execute any command on the server by using
ssh user@server 'command'
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.
To make it secure, ssh should be configured to allow only a single command. This wrapper-command effectively checks server side whether a requested command is allowed and started by the proper user. Only if both criteria are met, the command can be executed.
So in the configuration of the x2gossh daemon, the following line is added:
ForceCommand="x2gowrapper.sh $SSH_ORIGINAL_COMMAND" ssh-rsa
The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
Currently we are developing this wrapper that checks whether a command is allowed. When this is ready, we will make this available to the X2go project. However, acceptance of this solution will only happen if the principle problem is recognized.
In pyhoca-gui a distinction can be made between an x2go system user and the end-user that is running the application. This is a good start, but does not solve the problem mentioned above. However if combined with the wrapper it is a real secure solution, as in the wrapper, the system user can only execute a number of x2go commands, while the end-user can only execute another set of commands.
Furthermore, the client should be able to request the allowed commands for the end-user from the server and show them. If a user wants to change a profile, he/she should be allowed to choose only from the allowed commands. Also by this method it should be possible to generate the profiles automatically from the data from the server combined with some general parameters (like client-side printing and ways to connect).
Therefore the following changes are requested:
A seperate instance of the ssh daemon for x2go.
A wrapper that is ALWAYS called when connecting to the server by the ssh configuration
Separate users for the x2go system calls and the end-user
A change to the x2go clients to accomodate this change
5.An api on the server to request the allowed commands
- Automatic generation of the configuration on the cliënt side.
Anyone willing to make a comment, please do so. The overall quality will only increase!
Dick Kniep
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.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
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
On 11-03-29 15:36, Dick Kniep <dick.kniep@lindix.nl> wrote:
Hi list,
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.
An authorized user running commands over ssh is not a security problem at all. It works as intended. ssh provides shells.
To make it secure, ssh should be configured to allow only a single command. This wrapper-command effectively checks server side whether a requested command is allowed and started by the proper user. Only if both criteria are met, the command can be executed.
So in the configuration of the x2gossh daemon, the following line is added:
ForceCommand="x2gowrapper.sh $SSH_ORIGINAL_COMMAND" ssh-rsa
The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
From the invocation I infer, that the intended language for the wrapper is shellskript. This is extremely dangerous if intended as a security measure like you claim. Also please note that it is very hard to write such wrappers in a secure way, such that stuff like e.g. 'allowed_command foo bar ; evil_command' is not possible.
Currently we are developing this wrapper that checks whether a command is allowed. When this is ready, we will make this available to the X2go project. However, acceptance of this solution will only happen if the principle problem is recognized.
In pyhoca-gui a distinction can be made between an x2go system user and the end-user that is running the application. This is a good start, but does not solve the problem mentioned above. However if combined with the wrapper it is a real secure solution, as in the wrapper, the system user can only execute a number of x2go commands, while the end-user can only execute another set of commands.
Providing some 'nx' user which can 'su' to any user on the system is one of the worst design mistakes NX made and has extremely worrying security implications. But it is possible that I misunderstood your intentions.
Therefore the following changes are requested:
- A seperate instance of the ssh daemon for x2go.
What problem should this solve? What would this sshd instance do that the 'normal' one doesn't?
A wrapper that is ALWAYS called when connecting to the server by the ssh configuration
Separate users for the x2go system calls and the end-user
Again, why? What do you mean by system calls? What would be the connection sequence in your scenario?
- A change to the x2go clients to accomodate this change
5.An api on the server to request the allowed commands
- Automatic generation of the configuration on the cliënt side.
These points are valid, should however be discussed in a larger context: Various possible future extensions require interaction between server and client at session startup. E.g. when (hypothetically) doing loadbalancing, the server would send load data or redirects to the connecting client. Therefore a general API for such communications would be useful as well as versioning within that API to provide meaningful feedback when connecting with an 'old' client, or even to support interaction between different client and server versions.
Ciao,
Alexander Wuerstlein.
Hi all,
On Di 29 Mär 2011 16:55:50 CEST Alexander Wuerstlein wrote:
On 11-03-29 15:36, Dick Kniep <dick.kniep@lindix.nl> wrote:
An authorized user running commands over ssh is not a security problem at all. It works as intended. ssh provides shells.
As Reinhard has mentioned in another post: Dicks setup requires a
complete lock-down-kiosk-mode-kind-of-thing. He wants a user to be
able to run a small set of commands only (i.e. the rootless
applications he wants to provide to his customers). From his
perspective AFAIK a user logged in via SSH is a security issue. May it
be so.
The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
From the invocation I infer, that the intended language for the wrapper is shellskript. This is extremely dangerous if intended as a security measure like you claim. Also please note that it is very hard to write such wrappers in a secure way, such that stuff like e.g. 'allowed_command foo bar ; evil_command' is not possible.
This is a very worthy remark!!! I also think that it needs quite an
effort to script such a wrapper (and have it accepted in X2go
upstream!!!)
In pyhoca-gui a distinction can be made between an x2go system user and the end-user that is running the application. This is a good start, but does not solve the problem mentioned above. However if combined with the wrapper it is a real secure solution, as in the wrapper, the system user can only execute a number of x2go commands, while the end-user can only execute another set of commands.
Providing some 'nx' user which can 'su' to any user on the system is one of the worst design mistakes NX made and has extremely worrying security implications. But it is possible that I misunderstood your intentions.
What I have provided in PyHoca-GUI is a simple SSH proxy:
o the first SSH/Paramiko client connects to a ,,firewall'' and sets up a forwarding tunnel to a system behind that firewall o the second SSH client connects to the forwarded port on the client's localhost o it's a cascade of - ssh -p <fw-port> <fw-host> -L <lport>:<host-behind-fw-host>:<rport> - x2goclient -> localhost:<lport> o I use this SSH proxy option for several intranet servers I administer and it is a very handy-to-have feature
What Dick's company plans to do with this generic feature is:
o provide servers with two SSH daemons running o one daemon IP-binds to *, the other (x2gosshd) to localhost o pyhoca-gui logs in to the first daemon (in the role of SSH proxy) and sets up a tunnel to the x2gosshd's port on localhost o the first daemon allows port forwarding, but no real session (via pam_access.so) o the second x2gossh daemon allows login and only grants the execution of a single command: the wrapper script, which Dick has been explaining about
- Separate users for the x2go system calls and the end-user
Again, why? What do you mean by system calls? What would be the connection sequence in your scenario?
The ,,system call'' must be the first SSH login to the SSH daemon in
proxy role...
- A change to the x2go clients to accomodate this change
5.An api on the server to request the allowed commands
- Automatic generation of the configuration on the cliënt side.
These points are valid, should however be discussed in a larger context: Various possible future extensions require interaction between server and client at session startup. E.g. when (hypothetically) doing loadbalancing, the server would send load data or redirects to the connecting client. Therefore a general API for such communications would be useful as well as versioning within that API to provide meaningful feedback when connecting with an 'old' client, or even to support interaction between different client and server versions.
Something very similar I had in mind when talking about the
x2gofeatures script, recently. I think that there will be a time when
X2go will need such a proper handshake protocol...
However, I hope my mail gives some more information on what Dick is
talking about...
Mike
PS@Dick: I personally think that the subject of the original post is
misleading and also a little discrediting. Thus, I felt so free and
changed the subject a little...
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi,
On Tue, Mar 29, 2011 at 06:31:07PM +0200, Mike Gabriel wrote:
On Di 29 Mär 2011 16:55:50 CEST Alexander Wuerstlein wrote:
On 11-03-29 15:36, Dick Kniep <dick.kniep@lindix.nl> wrote:
An authorized user running commands over ssh is not a security problem at all. It works as intended. ssh provides shells.
As Reinhard has mentioned in another post: Dicks setup requires a
complete lock-down-kiosk-mode-kind-of-thing. He wants a user to be able to run a small set of commands only (i.e. the rootless applications he wants to provide to his customers). From his perspective AFAIK a user logged in via SSH is a security issue. May it be so.The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
From the invocation I infer, that the intended language for the wrapper is shellskript. This is extremely dangerous if intended as a security measure like you claim. Also please note that it is very hard to write such wrappers in a secure way, such that stuff like e.g. 'allowed_command foo bar ; evil_command' is not possible.
This is a very worthy remark!!! I also think that it needs quite an
effort to script such a wrapper (and have it accepted in X2go
upstream!!!)
An example for rsync via SSH can be found at: http://troy.jdmz.net/rsync/index.html
The validate-rsync script there can be used as a starting point.
Regards, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
On Wed, 2011-03-30 at 10:58 +0200, Erik Auerswald wrote:
Hi,
On Tue, Mar 29, 2011 at 06:31:07PM +0200, Mike Gabriel wrote:
On Di 29 Mär 2011 16:55:50 CEST Alexander Wuerstlein wrote:
On 11-03-29 15:36, Dick Kniep <dick.kniep@lindix.nl> wrote:
An authorized user running commands over ssh is not a security problem at all. It works as intended. ssh provides shells.
As Reinhard has mentioned in another post: Dicks setup requires a
complete lock-down-kiosk-mode-kind-of-thing. He wants a user to be able to run a small set of commands only (i.e. the rootless applications he wants to provide to his customers). From his perspective AFAIK a user logged in via SSH is a security issue. May it be so.The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
From the invocation I infer, that the intended language for the wrapper is shellskript. This is extremely dangerous if intended as a security measure like you claim. Also please note that it is very hard to write such wrappers in a secure way, such that stuff like e.g. 'allowed_command foo bar ; evil_command' is not possible.
This is a very worthy remark!!! I also think that it needs quite an
effort to script such a wrapper (and have it accepted in X2go
upstream!!!)An example for rsync via SSH can be found at: http://troy.jdmz.net/rsync/index.html
The validate-rsync script there can be used as a starting point.
Regards, Erik I admit I have not thought this issue through thoroughly as I'm under a brutal deadline right now but I would think the problem is that one can use X2Go for application publishing and not just complete desktops. Do we know in advance every possible application one might want to publish via X2Go? If we did (and I can't imagine we would), would we want to identify those via X2Go or some other mechanism built more for the task? My guess is, since we are an application publishing application, we should leave restriction of applications to the sysadmin using the tools already at their disposal. Again, that is only a half baked thought but I think it has some merit - John
Hi,
I disagree with almost everything you wrote, but I think it boils down to the following:
On 2011-03-29 15:35, Dick Kniep wrote:
The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper.
Why must there be an extra wrapper to disallow commands, when Linux provides enough tools to do so at system level? Why prohibit those commands in the first place. What you are suggesting, only makes sense when you want to limit parameters passed to a command. BTW: No one needs x2go to run "rm -rf /"! You can just do ssh <server> rm - Why bother using x2go?
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi Dick,
Am 29.03.2011 15:35, schrieb Dick Kniep: [snip]
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. [snip]
Thank you for sharing your concerns about the usage of x2go with us. As some people pointed out before the execution of commands via ssh is definitely a feature. Without this capability, x2go wouldn’t work at all. There is nothing "creepy" about executing commands on the server. I totally understand that you want to restrict the user from running vicious commands, but there are really a lot of "philosophies" how to do that.
An "integrated" solution could be to offer the system a login shell with a reduced command set.
Maybe a better solution could be to implement a connection to an already existing project doing that job better than a new attempt (this would be more the OS way).
As always: this is an Open Source project. This means: feel free to use it and - if you want to help - please do so. If you want to submit concerns or bugs it would be very helpful if you would name than in the subject like:
Wanted: Solution to prohibit remote execution of commands
Regards,
Heinz
-
Alexander Wuerstlein -
Dick Kniep -
Erik Auerswald -
Heinz-M. Graesing -
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Reinhard Tartler