Hi LIst,

I completely agree with you John, it looks like some people understand the need for this and others simply don't see the point (and probably for good reasons). 

However the problem is more complex than it seems, because to be able to use a wrapper, changes must be implemented in the clients. This is because the client cannot simply say anymore:

x2gomount ... ... ...

or any other command it needs to execute on the server, but it has to start this command thru the wrapper. So not only do we have to change the client, but also without extra measures we will be incompatible with earlier clients and most definitely older clients will not work with a newer server.

That is, IF we implement this as a standard part of the X2go package. We could implement this by adding a package (x2gokiosk?) that alters the ssh config and adds the wrapper. Requirements for this solution are:

An api is needed for communications between the server and the client that defines:

     - Kind of server that is there (x2goserver or x2gokiosk)

     - Version of the interface

     - Possibility to retrieve the allowed commands from the server

In that case we get the best of both worlds. If one wants the extra security the x2gokiosk package offers, x2gokiosk is installed and there is no problem that older clients cannot connect anymore, because the user has chosen for the extra security.

However if a newer client connects to an older server without the x2gokiosk package it should be able to see that there is no secure x2gokiosk on the other side and it should use the old way of connecting. In that case, also an older client with a newer server (no x2gokiosk) will work as expected.

Cheers,

Dick Kniep

-----Oorspronkelijk bericht----- Van: John A. Sullivan III <jsullivan@opensourcedevel.com> Verzonden: vr 01-04-11 02:56:09 Aan: x2go-dev@lists.berlios.de; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)

Hi list,

 

Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution)

I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem.

 

Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it.

 

This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.

 

Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor) <snip> Again I confess that I've not taken a lot of time to digest this issue but, I wonder if the back and forth is cause because for some users,

On Fri, 2011-04-01 at 02:44 +0200, Dick Kniep wrote: this would be a highly desirable feature whereas, for others, it not only makes no sense but would be a significant obstacle.  Can it be built as a configurable option that can be enabled with a setting in x2go.conf (or whatever file we are using for configuration)? - John

X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

!DSPAM:4d9522a930777730779061!