x2go-dev March 2011

x2go-dev@lists.x2go.org

24 participants
29 discussions

x2go client for mac osx
by Ricardo Díaz Martín 14 Nov '12

14 Nov '12

Hi, Is there somebody with x2go client working in MAC OS X Leopard or Snow Leopard? I have try in two different mac box and I always get the same message info "Can't connect to X-Server. Please check your settings". In settings looks like all ok (path to X11.app in mac osx is ok and verify it got right permissions). X-Server in both macs are installed and running. I have try to connect to nomachine linux server and X works fine. Some tips? Regards, Ricardo Díaz

7 8

sound on x2gothinclient
by Philipp Huebner 04 Jul '11

04 Jul '11

Hi, following the manual for Debian Lenny I have set up a x2gothinclient, but I can't get the sound to work. Any hints how to debug this problem? alsa recognizes the soundcard, it is supportet by the running linux kernel. Is it correct that there is not a single pulseaudio package installed inside the chroot? Regards, -- .''`. Philipp Huebner <debalance(a)debian.org> : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` HP: http://www.debalance.de, Skype: philipp-huebner `- ICQ: 235-524-440, Jabber: der_schakal(a)jabber.org

6 6

x2goclient and ssh-agent
by Heiko Baumann 29 Jun '11

29 Jun '11

Hello, is there a way to use x2goclient with ssh-agent(1)? i am using ssh-agent with my etoken to login via nxclient on some machines. is this possible with x2goclient? i've started x2goclient from the same shell where a ssh login to the remote server worked with agent auth. but x2goclient seems not to use the running ssh-agent. thanks for any help. heiko

6 17

Multiserver CUPS patches
by John A. Sullivan III 15 Apr '11

15 Apr '11

Here are the patches to enable a single cups-x2go CUPS server to service multiple X2Go Servers. The documentation was posted previously. Thanks - John

3 11

Shared database patches
by John A. Sullivan III 15 Apr '11

15 Apr '11

Here are the patches for implementing a secure shared database - John

2 2

VcXsrv clipboard issue
by Dick Kniep 08 Apr '11

08 Apr '11

Hi list, Mike has developed a very nice python gui client. We are going to use this with our product. However it seems that with the latest version of VcXsrv (1.10.0) there is an issue with the clipboard. Copying from my PC to the X-session works OK. However, the other way around does not. There is a new parameter --clipboardprimary that should alter the behaviour of the clipboard. However it does not seem to make any difference. Anyone else seen this behaviour and hopefully knows something to solve this? Dick Kniep Lindix BV tel. 036-5215580 mob. 06-50991858

4 9

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

30 Mar '11

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 <jsullivan(a)opensourcedevel.com> Verzonden: wo 30-03-11 11:44:06 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 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.kniep(a)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(a)lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev !DSPAM:4d92fb66203787818312239!

2 1

X2go is insecure
by Dick Kniep 30 Mar '11

30 Mar '11

Hi list, In the past few month, Mike has developed a very nice python client for x2go that caters to our need as a Application service provider. However during that period, we have investigated the security of X2go and it proves that X2go is an insecure product if used in a hostile environment like the Internet. I know many of you are wondering: But we are using ssh, how can that be insecure? Well, as many of you know, one can connect to a server with ssh with a terminal and execute commands on that server, including commands like rm -Rf * or other commands. Even if the shell is disabled, it is still possible to execute any command on the server by using ssh user@server 'command' The problem is caused by the fact that the x2go server does not restrict the commands that can be entered thru ssh. This is bad, but what is worse, is that the X2go clients actually use this security hole to start any command it needs. To make it secure, ssh should be configured to allow only a single command. This wrapper-command effectively checks server side whether a requested command is allowed and started by the proper user. Only if both criteria are met, the command can be executed. So in the configuration of the x2gossh daemon, the following line is added: ForceCommand="x2gowrapper.sh $SSH_ORIGINAL_COMMAND" ssh-rsa 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. Currently we are developing this wrapper that checks whether a command is allowed. When this is ready, we will make this available to the X2go project. However, acceptance of this solution will only happen if the principle problem is recognized. 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. Furthermore, the client should be able to request the allowed commands for the end-user from the server and show them. If a user wants to change a profile, he/she should be allowed to choose only from the allowed commands. Also by this method it should be possible to generate the profiles automatically from the data from the server combined with some general parameters (like client-side printing and ways to connect). Therefore the following changes are requested: 1. A seperate instance of the ssh daemon for x2go. 2. A wrapper that is ALWAYS called when connecting to the server by the ssh configuration 3. Separate users for the x2go system calls and the end-user 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. Anyone willing to make a comment, please do so. The overall quality will only increase! Dick Kniep

8 8

Suggestion: Make x2gothinclientsystem less invasive
by Michael Hierweck 25 Mar '11

25 Mar '11

Hi x2go folks, I would like to suggest a solution to make x2gothinclientsystem less invasive. Instead of mounting a ramdisk and removing/symlinking some files and directories (which might be a Debian packaging policy violation) it might be smarter to mount a read only root filesystem and transparently overlay it with a tempfs. I can this be achieved? a) Install aufs modules in the clients' chroot environment. Aufs modules are part of Squeeze's default kernel. b) Add "aufs" to /etc/initramfs-tools/modules. c) Set "BOOT=aufs" in /etc/initramfs-tools/initramfs.conf. d) Add a "magic" script (see attachment) named "aufs" to /etc/initramfs-tools/scripts e) Call update-initramfs -u inside the chroot. The "aufs" script is based on Debian's /usr/share/initramfs-tools/scripts/nfs script. The attached script provides a three layer file root filesystem. ro nfsroot/master (generic thinclients' chroot) ro nfsroot/<ip-address> (individual thinclient's configuration overriding master) rw tempfs (simulates a fully rw root file system) Pros: * simple (to my mind) * flexible * less "hacky" (less/no conflicts with other packages) * therefore more Debian compliant (to my mind) * x2go related stuff currently stored in /ramdisk can go into /var/lib/x2go... Cons: * any? Any feedback is appreciated. Michael -- EDV-Serviceteam Annika & Michael Hierweck GbR Egerstraße 53, 44225 Dortmund (Germany) http://www.edv-serviceteam.net # NFS filesystem mounting -*- shell-script -*- # FIXME This needs error checking retry_nr=0 # parse nfs bootargs and mount nfs do_nfsmount() { configure_networking # get nfs root from dhcp if [ "x${NFSROOT}" = "xauto" ]; then # check if server ip is part of dhcp root-path if [ "${ROOTPATH#*:}" = "${ROOTPATH}" ]; then NFSROOT=${ROOTSERVER}:${ROOTPATH} else NFSROOT=${ROOTPATH} fi # nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] elif [ -n "${NFSROOT}" ]; then # nfs options are an optional arg if [ "${NFSROOT#*,}" != "${NFSROOT}" ]; then NFSOPTS="-o ${NFSROOT#*,}" fi NFSROOT=${NFSROOT%%,*} if [ "${NFSROOT#*:}" = "$NFSROOT" ]; then NFSROOT=${ROOTSERVER}:${NFSROOT} fi fi if [ -z "${NFSOPTS}" ]; then NFSOPTS="-o retrans=10" fi [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-premount" run_scripts /scripts/nfs-premount [ "$quiet" != "y" ] && log_end_msg if [ ${readonly} = y ]; then roflag="-o ro" else roflag="-o rw" fi mkdir -p /aufs-root mkdir -p /aufs-conf mkdir -p /aufs-temp nfsmount -o nolock ${roflag} ${NFSOPTS} ${NFSROOT}/master /aufs-root nfsmount -o nolock ${roflag} ${NFSOPTS} ${NFSROOT}/config/${IPV4ADDR} /aufs-conf mount -t tmpfs tmpfs /aufs-temp mount -t aufs -o dirs=/aufs-temp=rw:/aufs-conf=ro:/aufs-root=ro aufs ${rootmnt} } # NFS root mounting mountroot() { [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-top" run_scripts /scripts/nfs-top [ "$quiet" != "y" ] && log_end_msg modprobe nfs # For DHCP modprobe af_packet wait_for_udev 10 # Default delay is around 180s # FIXME: add usplash_write info if [ -z "${ROOTDELAY}" ]; then delay=180 else delay=${ROOTDELAY} fi # loop until nfsmount succeds while [ ${retry_nr} -lt ${delay} ] && [ ! -e ${rootmnt}${init} ]; do [ ${retry_nr} -gt 0 ] && \ [ "$quiet" != "y" ] && log_begin_msg "Retrying nfs mount" do_nfsmount retry_nr=$(( ${retry_nr} + 1 )) [ ! -e ${rootmnt}${init} ] && /bin/sleep 1 [ ${retry_nr} -gt 0 ] && [ "$quiet" != "y" ] && log_end_msg done [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-bottom" run_scripts /scripts/nfs-bottom [ "$quiet" != "y" ] && log_end_msg }

3 3

Re: [X2go-dev] [X2go-user] LDAP-Problem: Zertifikateproblem
by Mike Gabriel 23 Mar '11

23 Mar '11

Hi Mike, On Mi 23 Mär 2011 14:21:12 CET wrote: > Yes, I know that LDAP is not absolutely necessary. I am using x2go > already that way. This is to make a test installation for a > presentation of the software with the option of using it for a > company, so LDAP is an option. I would like to use it, but I am not > experienced with LDAP yet myself and the one who is experienced > proposes NX. > Plus one can only gain experiences. Do you want to use the load balancing support of X2go/LDAP? Or do you just want to administrate users in LDAP. For the latter, I personally recommend setting up your LDAP tree manually (there are plenty of howtos in the web for this...). For learning LDAP this should be your way to go. Then make sure you can use LDAP as libnss and pam source for passwd, group, shadow. At last you have to make sure that LDAP users are in the x2gousers group (which can be local or also a group in LDAP). Once you have that, LDAP users can login via X2go. [Once you have such a simple LDAP DIT up and running you might want to start from scratch and set up an LDAP-server that gets administered by GOsa² or CIPUX ;-) ...] If you want to use load balancing with X2go, then this should also be possible manually, but basically that's what the scripts were intended for (they were also intended for easy LDAP-setup, but you can do this manually...). However, to my personal view, the LDAP implementation needs quite some work before the Baikal release and also needs proper documentation of the way LDAP data is used and interpreted... Maybe someone else has experience on LDAP/loadbalancing... 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…

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev March 2011