[X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)

[Mike Gabriel]

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

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

>> 4. A 	change to the x2go clients to accomodate this change
>>
>> 5.An 	api on the server to request the allowed commands
>>
>> 6. 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 at 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 at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110329/2c6da6c1/attachment.pgp>