x2go-dev April 2011

x2go-dev@lists.x2go.org

25 participants
52 discussions

Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
by Dick Kniep 01 Apr '11

01 Apr '11

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) Dick Kniep -----Oorspronkelijk bericht----- Van: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Verzonden: wo 30-03-11 20:22:45 Aan: x2go-dev(a)lists.berlios.de; Dick Kniep <dick.kniep(a)lindix.nl>; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) Hi Dick, On Mi 30 Mär 2011 18:46:49 CEST Dick Kniep wrote: > 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. What I have been thinking the last day is that it might be much more generic and by far more effective to use the apparmor tool for this kind of lock-down. However, I have never played with apparmor, only in cases when the rules package maintainers had included in their packages were too strict... Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

6 6

Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
by Dick Kniep 01 Apr '11

01 Apr '11

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(a)opensourcedevel.com> Verzonden: vr 01-04-11 02:56:09 Aan: x2go-dev(a)lists.berlios.de; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) On Fri, 2011-04-01 at 02:44 +0200, Dick Kniep wrote: > 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, 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(a)lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev !DSPAM:4d9522a930777730779061!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev April 2011