Hi list,
First of all sorry for the somewhat provocative way I entered this discussion. Now about the use case we have: We are providing an application over the internet to users. This application should run seamlessly on the desktop of the user. So we do NOT export a complete desktop but only a single application. The users should be able to start this application, but nothing else...... Our users are on the Internet at random places. Some might logon with the nice python client of Mike, some might use an X2go plugin in a browser etc. As the users should only be able to execute our application and nothing more, security should be done at the server and NOT at the client. The way X2go works is that commands defined in the client are sent to the server and executed there. So if a user starts a desktop, the client sends the command to start the desktop to the server and it is executed there. The screen shows throught nx and he can work. From the moment the desktop is running, only the screens, the mouseclicks and keyboard is sent thru the tunnel. Because the user can change the profiles stored in the X2goclient, he could enter any command there and send it to the server. So, what I suggest is that on the server there is a file where the allowed user commands are stored per usergroup (Off-course Unix usergroups can be used here). This is not very complicated, because if the user is allowed to start the shell, this is only checked when the connection is made and not afterwards. This should be sufficient. Example ---------//----------- The group x2gousers on the server is allowed to execute the terminal and kde and a special application (say CVix, our application). So, when the user connects to the server, the server reports to the user, OK, you can start kde, the terminal or CVix. If the user chooses the terminal, then the terminal is started and the user can execute any command allowed for him in the terminal. Now this is a trivial example, because the user is allowed to execute the terminal and can do anything he likes. However if the user is only allowed to execute CVix, there is no way whatsover for him to circumvent this authorization, because the wrapper simply prohibits any command that is not defined in the db. ----------//---------- In the X2go client, commands must be executed on the server to build the session. The number of commands that must be issued by the client is not very high and can be delivered preconfigured with the X2go server in the allowed commands db. We have developed the wrapper that does exactly what I describe here. Currently it is lacking a screen where an authorized user can change the authorization db, but that will come on short notice. I hope it is a little clearer now what the problem is and how it can be solved. Dick Kniep -----Oorspronkelijk bericht----- Van: John A. Sullivan III <jsulli...@opensourcedevel.com> Verzonden: wo 30-03-11 11:44:06 Aan: x2go-dev@lists.berlios.de; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) 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.kn...@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 _______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev !DSPAM:4d92fb66203787818312239!
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
