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