Hi, Morning,
I am testing PyHoca. One of the problems a came around is, that the client checks whether I am in the x2go group - which I'm not. I also noticed that some other security-checks are done in the client. I believe this is dangerous, because administrators might think that these are real security checks, while they can easily be circumvented. I believe these check must be done server-side. That way they can also easily be adjusted by administrators.
Besides that, one of our admins did quite a few security patches to avoid x2gowrapper having to run as root. At the moment this only works for Postgres. None the less I must say that I'm not happy running x2gowrapper, which is easy to exploit using SQL-Injections, as root. It should at least do a "sudo -u x2go" or similar. This user only needs access to the database. That way worst case the db is corrupted and not the whole system.
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 20.01.2011 10:24, schrieb Moritz Struebe:
Besides that, one of our admins did quite a few security patches to avoid x2gowrapper having to run as root
Ooops. Linking isn't bad: http://git.informatik.uni-erlangen.de/cgi-bin/gitweb.cgi?p=x2go.git;a=commit...
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 20.01.2011 10:24, schrieb Moritz Struebe:
Hi, Morning,
I am testing PyHoca. One of the problems a came around is, that the client checks whether I am in the x2go group - which I'm not. I also noticed that some other security-checks are done in the client. I believe this is dangerous, because administrators might think that these are real security checks, while they can easily be circumvented. I believe these check must be done server-side. That way they can also easily be adjusted by administrators.
Besides that, one of our admins did quite a few security patches to avoid x2gowrapper having to run as root. At the moment this only works for Postgres. None the less I must say that I'm not happy running x2gowrapper, which is easy to exploit using SQL-Injections, as root. It should at least do a "sudo -u x2go" or similar. This user only needs access to the database. That way worst case the db is corrupted and not the whole system.
Cheers Morty
Hello Moritz,
I can't say nothing about PyHoca, but x2goclient make those checks not.
You are quite right about pgwrapper. Changing "sudo" to "sudo -u x2go" is on top of our todo list and will be made in the next version of x2goserver. But I don't think, that it is so easy to use x2gowrapper to do something bad with a system. Sure, if you can show me a working exploit, I will put all other things I have to do on ice and concentrate on this problem. In all cases I'll change behavior of x2goserver very soon.
Regards, alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On 11-01-20 11:06, Oleksandr Shneyder <oleksandr.shneyder@obviously-nice.de> wrote:
Am 20.01.2011 10:24, schrieb Moritz Struebe:
Hi, Morning,
I am testing PyHoca. One of the problems a came around is, that the client checks whether I am in the x2go group - which I'm not. I also noticed that some other security-checks are done in the client. I believe this is dangerous, because administrators might think that these are real security checks, while they can easily be circumvented. I believe these check must be done server-side. That way they can also easily be adjusted by administrators.
Besides that, one of our admins did quite a few security patches to avoid x2gowrapper having to run as root. At the moment this only works for Postgres. None the less I must say that I'm not happy running x2gowrapper, which is easy to exploit using SQL-Injections, as root. It should at least do a "sudo -u x2go" or similar. This user only needs access to the database. That way worst case the db is corrupted and not the whole system.
Cheers Morty
Hello Moritz,
I can't say nothing about PyHoca, but x2goclient make those checks not.
You are quite right about pgwrapper. Changing "sudo" to "sudo -u x2go" is on top of our todo list and will be made in the next version of x2goserver. But I don't think, that it is so easy to use x2gowrapper to do something bad with a system. Sure, if you can show me a working exploit, I will put all other things I have to do on ice and concentrate on this problem. In all cases I'll change behavior of x2goserver very soon.
Simplest case: SQL injection to execute arbitrary commands as 'postgres' on the database as well as on the system. Just intently look at /usr/bin/x2gopgwrapper_local line 42 (especially the '$2'). Exploiting this would allow you to do anything to any database on that postgres instance (since postgres is the administrative account by default) and possibly (depending on the local postgres configuration) to execute arbitrary commands as user 'postgres'. For a quick glance at what you could do, see http://pentestmonkey.net/blog/postgres-sql-injection-cheat-sheet/
Also, in /usr/bin/x2golistsessions line 31, the perl system() function is used together with sudo in an insecure way. I'm currently not totally sure, how this can be used to execute arbitrary commands as root but it surely looks very suspicious.
Suggestions for fixing those problems would at least include the following:
- Never sudo to root, always use a less privileged user
- Never use a database as 'postgres', always create one or more less privileged database users. Also, use the permissions system of the database and stored procedures to limit the amount of damage those database users can do. In the case of x2go, that would mean at least 2 database users, e.g. 'x2go' for the unprivileged (select) database accesses and 'x2go_adm' for all '_root' accesses or writing.
- Always use prepared statements for database access. Since this is not really possible in bash, e.g. perl DBI should be used for everything accessing the database. This would remove the need for all those ugly skripts like x2golistsessions which just filter the output of psql to remove spaces and stuff[1].
- Never use backticks or the 'evil' one-argument form of system().
Ciao,
Alexander Wuerstlein.
[1] btw, psql has parameters -A and -F
On 11-01-20 14:48, Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> wrote:
On 11-01-20 11:06, Oleksandr Shneyder <oleksandr.shneyder@obviously-nice.de> wrote:
Am 20.01.2011 10:24, schrieb Moritz Struebe:
Hi, Morning,
Besides that, one of our admins did quite a few security patches to avoid x2gowrapper having to run as root. At the moment this only works for Postgres. None the less I must say that I'm not happy running x2gowrapper, which is easy to exploit using SQL-Injections, as root. It should at least do a "sudo -u x2go" or similar. This user only needs access to the database. That way worst case the db is corrupted and not the whole system. You are quite right about pgwrapper. Changing "sudo" to "sudo -u x2go" is on top of our todo list and will be made in the next version of x2goserver. But I don't think, that it is so easy to use x2gowrapper to do something bad with a system. Sure, if you can show me a working exploit, I will put all other things I have to do on ice and concentrate on this problem. In all cases I'll change behavior of x2goserver very soon. Also, in /usr/bin/x2golistsessions line 31, the perl system() function is used together with sudo in an insecure way. I'm currently not totally sure, how this can be used to execute arbitrary commands as root but it surely looks very suspicious.
Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first parameter. Choose the 11th parameter in a way such that SHADOW_USER is set to 'root'. Set the second parameter ($CLIENT) to something like 'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite: the x2gopgwrapper_sqlite runs as root meaning that any sql injection into sqlite would run as root. One possible injection would set the sqlite output file to /etc/shadow (via .output /etc/shadow) and overwrite it with a customized version including a new root password chosen by the attacker. Profit.
Ciao,
Alexander Wuerstlein.
Am 20.01.2011 15:39, schrieb Alexander Wuerstlein:
Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first parameter. Choose the 11th parameter in a way such that SHADOW_USER is set to 'root'. Set the second parameter ($CLIENT) to something like 'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite: the x2gopgwrapper_sqlite runs as root meaning that any sql injection into sqlite would run as root. One possible injection would set the sqlite output file to /etc/shadow (via .output /etc/shadow) and overwrite it with a customized version including a new root password chosen by the attacker. Profit.
I see, thank you Alexander. We'll fix it as quick as possible. Regards,
alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 20.01.2011 15:39, schrieb Alexander Wuerstlein:
Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first parameter. Choose the 11th parameter in a way such that SHADOW_USER is set to 'root'. Set the second parameter ($CLIENT) to something like 'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite: the x2gopgwrapper_sqlite runs as root meaning that any sql injection into sqlite would run as root. One possible injection would set the sqlite output file to /etc/shadow (via .output /etc/shadow) and overwrite it with a customized version including a new root password chosen by the attacker. Profit.
I see, thank you Alexander. We'll fix it as quick as possible. Regards, <snip> It has probably been roughly a year but I had posted some changes we made because we were very uncomfortable calling PostgreSQL as postgres. In fact, we combined it with our vserver work and eventually used user
On Thu, 2011-01-20 at 16:17 +0100, Oleksandr Shneyder wrote: based schemas so we could use a single database for any number of X2Go Servers - John
Hi Alex,
On Do 20 Jan 2011 17:26:28 CET "John A. Sullivan III" wrote:
Am 20.01.2011 15:39, schrieb Alexander Wuerstlein:
Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first parameter. Choose the 11th parameter in a way such that SHADOW_USER is set to 'root'. Set the second parameter ($CLIENT) to something like 'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite: the x2gopgwrapper_sqlite runs as root meaning that any sql injection into sqlite would run as root. One possible injection would set the sqlite output file to /etc/shadow (via .output /etc/shadow) and overwrite it with a customized version including a new root password chosen by the attacker. Profit.
I see, thank you Alexander. We'll fix it as quick as possible. Regards, <snip> It has probably been roughly a year but I had posted some changes we made because we were very uncomfortable calling PostgreSQL as postgres. In fact, we combined it with our vserver work and eventually used user
On Thu, 2011-01-20 at 16:17 +0100, Oleksandr Shneyder wrote: based schemas so we could use a single database for any number of X2Go Servers - John
John sent these patches (with docs!!!) to the list on 20100702. I had
taken a look at them then and they looked quite promising. They are
definitely worth looking at to address this issue.
Cheerio, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hello x2go devs,
I've noticed that although you seem to have solved the security flaws in the database access the preinst script in the repository for lenny [1] has not been updated since late 2009. It still contains the command to give all users sudo root permissions on the x2togowrapper.
I would appreciate to know some kind of time frame when you are planning to integrate the update into your repository, because we're planning to install x2go on around 50 hosts of a PC pool at the RWTH Aachen University. Since we do not want to go through the process of checking out new sources, building them and installing them now and then on every machine, we would like to use the deb-repository with apt-get and not some git based source repository.
Furthermore I've got a rather special question. On a current test-system we have replaced the x2gousers group by a custom group that each user that should be allowed to use x2go already is included in. We have decided to do so, because our we do not want to add additional groups. Since you are going to change this specific line in the sudoers file, I wonder if this is still possible. If you are just replacing the semantics of "everybody in x2gousers gets root for /usr/bin/x2gopgwrapper" by "everybody in x2gousers gets $someSpecialX2goUser for /usr/bin/x2gopgwrapper" (where $someSpecialX2goUser is a user that is just allowed to access the databases) the should be easily possible, shouldn't it?
And last but not least: You're doing a very good piece of work :)
Thanks in advance for your help.
With regards,
Kevin Möllering
[1] http://x2go.obviously-nice.de/deb/pool-lenny/x2goserver/
Mike Gabriel schrieb:
Hi Alex,
On Do 20 Jan 2011 17:26:28 CET "John A. Sullivan III" wrote:
Am 20.01.2011 15:39, schrieb Alexander Wuerstlein:
Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first parameter. Choose the 11th parameter in a way such that SHADOW_USER is set to 'root'. Set the second parameter ($CLIENT) to something like 'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite: the x2gopgwrapper_sqlite runs as root meaning that any sql injection into sqlite would run as root. One possible injection would set the sqlite output file to /etc/shadow (via .output /etc/shadow) and overwrite it with a customized version including a new root password chosen by the attacker. Profit.
I see, thank you Alexander. We'll fix it as quick as possible. Regards, <snip> It has probably been roughly a year but I had posted some changes we made because we were very uncomfortable calling PostgreSQL as postgres. In fact, we combined it with our vserver work and eventually used user
On Thu, 2011-01-20 at 16:17 +0100, Oleksandr Shneyder wrote: based schemas so we could use a single database for any number of X2Go Servers - John
John sent these patches (with docs!!!) to the list on 20100702. I had taken a look at them then and they looked quite promising. They are definitely worth looking at to address this issue.
Cheerio, Mike
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hi Kevin,
sudoers is only needed for the sqlite-version. For that this it works fine, needing some minor adjustments like ownership of the database, etc. It's probably worth doing the postinst of x2goserver-one by hand instead of installing it. http://code.x2go.org/gitweb?p=x2goserver-one.git;a=blob;f=debian/postinst I personally haven't looked at the postgres solution. As far as I understood you currently need to import users first - but it's probably worth looking at the code and providing a patch. :)
Cheers Morty
On 2011-02-14 10:23, Kevin Moellering wrote:
Furthermore I've got a rather special question. On a current test-system we have replaced the x2gousers group by a custom group that each user that should be allowed to use x2go already is included in. We have decided to do so, because our we do not want to add additional groups. Since you are going to change this specific line in the sudoers file, I wonder if this is still possible. If you are just replacing the semantics of "everybody in x2gousers gets root for /usr/bin/x2gopgwrapper" by "everybody in x2gousers gets $someSpecialX2goUser for /usr/bin/x2gopgwrapper" (where $someSpecialX2goUser is a user that is just allowed to access the databases) the should be easily possible, shouldn't it?
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Mon, 2011-02-14 at 11:09 +0100, Moritz Struebe wrote:
Hi Kevin,
sudoers is only needed for the sqlite-version. For that this it works fine, needing some minor adjustments like ownership of the database, etc. It's probably worth doing the postinst of x2goserver-one by hand instead of installing it. http://code.x2go.org/gitweb?p=x2goserver-one.git;a=blob;f=debian/postinst I personally haven't looked at the postgres solution. As far as I understood you currently need to import users first - but it's probably worth looking at the code and providing a patch. :) <snip> Just as a suggestion to the original poster, unless you are already running sqlite for something else, you may wish to consider a single, shared postgresql database. There are pros and cons each way. Good luck - John
Hi there,
this should work: http://x2go.obviously-nice.de/deb/pool-heuler/
Cheers Morty
On 2011-02-14 10:23, Kevin Moellering wrote:
I've noticed that although you seem to have solved the security flaws in the database access the preinst script in the repository for lenny [1] has not been updated since late 2009. It still contains the command to give all users sudo root permissions on the x2togowrapper.
I would appreciate to know some kind of time frame when you are planning to integrate the update into your repository, because we're planning to install x2go on around 50 hosts of a PC pool at the RWTH Aachen University. Since we do not want to go through the process of checking out new sources, building them and installing them now and then on every machine, we would like to use the deb-repository with apt-get and not some git based source repository.
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi Kevin,
On Mo 14 Feb 2011 10:23:57 CET Kevin Moellering wrote:
I would appreciate to know some kind of time frame when you are
planning to integrate the update into your repository, because we're
planning to install x2go on around 50 hosts of a PC pool at the RWTH
Aachen University. Since we do not want to go through the process of
checking out new sources, building them and installing them now and
then on every machine, we would like to use the deb-repository with
apt-get and not some git based source repository.
As the release model is currently not very transparent to outsiders
(we are working on that) I recommend the following (in case you are in
a hurry):
- Mirror the following repositories
deb http://x2go.obviously-nice.de/deb lenny main deb http://x2go.obviously-nice.de/deb heuler main
The heuler repository is testing upstream code that runs on ,,all''
(let's see if there will be any objections to this) .deb based systems
since Debian lenny (even Ubuntu hardy).
So testing in the heuler repos really refers to ,,upstream'' testing
and it does not relate at all with any ,,testing'' repos in Debian or
similar.
- Once you have mirrored, disable automatic mirror sync
That is: currently the main packages (x2goclient(-qt), x2goserver,
x2goserver-one etc., I am not talking about the thin client env and
the KDE tools) need some more testing but I also use them for
production (as a system administrator).
Install packages from your local mirror
Watch the x2go-dev and the x2go-announcement list for updates.
Ideally new packages should be announced on
x2go-announcement@lists.berlios.de.
Only last Saturday Heinz and I sat with Jonas Smedegaard (Debian
developer) and we hope to provide packages in Debian within the next
months (that will be for sid and wheezy).
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi all,
Reinhard and I already started cleaning up packages in our repo. Did you guys agree on someone to publish your roadmap. Possibly the Wiki is the right place....
Cheers Morty
On 2011-02-14 11:22, Mike Gabriel wrote:
Only last Saturday Heinz and I sat with Jonas Smedegaard (Debian developer) and we hope to provide packages in Debian within the next months (that will be for sid and wheezy).
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi Morty,
On Mo 14 Feb 2011 11:32:33 CET Moritz Struebe wrote:
Hi all,
Reinhard and I already started cleaning up packages in our repo. Did you guys agree on someone to publish your roadmap. Possibly the Wiki is the right place....
Cheers Morty
[I divert this thread to pkg-x2go-devel@lists.alioth.debian.org to
stay on-topic with the discussion. Contributors to this thread please
use the Debian pkg-x2go-devel list.]
We have received your patches. Thanks a lot for them. All packages
will be converted to CDBS in the long run, though. Jonas and I
discussed and worked-out an upstream(!!!) Git-based release strategy
that will be pre-requisite for easy packaging for Debian and that will
also help other distros to grab the released tarballs directly from
the upstream Git (code.x2go.org/gitweb).
The /debian folders will disappear from upstream in the near future
and will re-appear on collab-maint at debian.org (as CDBS based
versions). Collab-maint on debian.org will be the Debian packaging
Git. We have learned to differentiate clearly between these two.
We already migrated one x2go project and uploaded it to the upstream
Git for reference and feedback:
http://code.x2go.org/gitweb?p=x2goclient-cli.git;a=summary
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi there,
I've noticed that all the repos at http://code.x2go.org/gitweb were renamed with a prefix _old_. What is the reason for this? Renaming repos really is not a nice thing to do, as all clones must be adjusted. And if you set up new repos the checksums will not match anymore, breaking the part of the cool features of git. What is the reason for doing so? I'm also still missing a road map. This would really help to avoid doing duplicate work. And if there is talk in the back ground: Please(!) make it public.
Cheers Morty
Am 14.02.2011 11:48, Mike Gabriel schrieb:
Reinhard and I already started cleaning up packages in our repo. Did you guys agree on someone to publish your roadmap. Possibly the Wiki is the right place....
Cheers Morty
[I divert this thread to pkg-x2go-devel@lists.alioth.debian.org to stay on-topic with the discussion. Contributors to this thread please use the Debian pkg-x2go-devel list.]
We have received your patches. Thanks a lot for them. All packages will be converted to CDBS in the long run, though. Jonas and I discussed and worked-out an upstream(!!!) Git-based release strategy that will be pre-requisite for easy packaging for Debian and that will also help other distros to grab the released tarballs directly from the upstream Git (code.x2go.org/gitweb).
The /debian folders will disappear from upstream in the near future and will re-appear on collab-maint at debian.org (as CDBS based versions). Collab-maint on debian.org will be the Debian packaging Git. We have learned to differentiate clearly between these two.
We already migrated one x2go project and uploaded it to the upstream Git for reference and feedback:
Hi Morty, dear Heinz, dear Alex,
On Mo 21 Feb 2011 21:52:51 CET Moritz Strübe wrote:
Hi there,
I've noticed that all the repos at http://code.x2go.org/gitweb were renamed with a prefix _old_. What is the reason for this? Renaming repos really is not a nice thing to do, as all clones must be adjusted. And if you set up new repos the checksums will not match anymore, breaking the part of the cool features of git. What is the reason for doing so? I'm also still missing a road map. This would really help to avoid doing duplicate work. And if there is talk in the back ground: Please(!) make it public.
Cheers Morty
First: the Git at code.x2go.org has so far not been officially
announced on any channel. The main reason for this is (from my
perspective) that I have had no definite confirmation from Heinz and
Alex, yet, that they will really change over X2go development to a
publically available Git based release model. From my point of view,
there has been good will so far, but no definite: YES. That means:
o upstream code is comitted into upstream Git and reflects the upstream development process (i.e. there are more commits than releases) o at some stages the upstream developers ask a release manager to tag a release o the release tagging informs distro packagers that there is a new upstream version of one of the X2go projects
The Git on code.x2go.org was already ,,nice'', but it's main flaw was
the lack of history. Also: the lack of being able to extract the
original tarball releases from the git directly. However, that shall
be possible in the future.
In the run of meeting Heinz and Jonas in Zweibrücken and talking to
Heinz on the phone later, a slightly different Git model has come up
that I am preparing now for proposal.
I have asked Heinz and Alex internally for an opinion on the new
model, but have not received a reply within the last week. I must
confess that I explained the gains of the new structure only shorly
Thus my basic idea with the latest work on code.x2go.org was to show
the new structure to the world and discuss the following advantages of
upstream Git projects that:
o contain a pristine-tar branch o contain a nearly complete history (that is as many of the older releases as possible) on the x2go-dev ML. o release numbers do not contain hyphens (''-'') anymore o all X2go projects have a a.b.c.d version number (major.minor.micro.nano(?))
Everything I do currently is reversible and in upstream we (Heinz,
Alex, Mike) are still in the middle of a discussion process. There is
not yet a consensus on how the Git will be used and there is no
roadmap yet either. However, I urge everyone involved (and this not
for the first time, but maybe the first time in public) to focus on
that in the oncoming days and weeks before diving into new absorbing
coding work. That is: I recommend to sharpen the tools first.
@Heinz+Alex: we have to get this to a definite state now. I feel
myself getting gradually impatient about the sluggyness of this
process. Please, contribute to this thread. My personal goal is that
we have a definite result on X2go upstream git usage at the end of
this discussion thread.
@Morty: thanks for re-addressing this topic!!!
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi again,
On Mo 21 Feb 2011 23:02:11 CET Mike Gabriel wrote:
o contain a pristine-tar branch o contain a nearly complete history (that is as many of the older releases as possible) on the x2go-dev ML. o release numbers do not contain hyphens (''-'') anymore o all X2go projects have a a.b.c.d version number
(major.minor.micro.nano(?))
another characteristic of the new Git model will be that there will be
no /debian folders anymore. Thus, the X2go projects will be distro
independent/generic.
@Heinz+Alex: the release of an X2go project in the future should only
happen in Git. There could be an optional tarball as http-download.
But the package building itself should then be left for the packagers.
Currently, that is Jonas+Mike+? (pkg-x2go-devel) for Debian and
Reinhart+? for Ubuntu. And maybe others for other distros...
@Heinz: if you direct debian.x2go.org to the same hostname as
code.x2go.org, I will build up a reprepro there for Debian backports
of X2go (that is: all X2go packages for Debian distro versions down to
lenny that cannot not make its way into official Debian repositories).
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Moritz,
On Do 20 Jan 2011 10:24:12 CET Moritz Struebe wrote:
I am testing PyHoca. One of the problems a came around is, that the
client checks whether I am in the x2go group - which I'm not. I also
noticed that some other security-checks are done in the client. I
believe this is dangerous, because administrators might think that
these are real security checks, while they can easily be
circumvented. I believe these check must be done server-side. That
way they can also easily be adjusted by administrators.
I only added this check because missing group membership results in
endless spamming of the auth.log file during the login process while
the server load goes up tremendously. Of course, the client software
presumes that the system is set up with default values. I agree that
there actually should be a server script that pre-checks if a user (or
a command) is welcome to the server.
The Qt x2goclient doesn't check this, which raises performance and log
spamming problems once a user logs in that is not allowed to log in.
What other security checks do you refer to?
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike
Am 20.01.2011 23:46, schrieb Mike Gabriel:
I agree that there actually should be a server script that pre-checks if a user (or a command) is welcome to the server.
Jep, the server does need some cleanup. :-)
The Qt x2goclient doesn't check this, which raises performance and log spamming problems once a user logs in that is not allowed to log in.
Yep, that's why I was a little confused, when I was told, that I'm not allowed to run x2go.
What other security checks do you refer to?
I didn't test them, but I also saw similar checks around fuse, sound and printing, I think.
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 21.01.2011 09:21, schrieb Moritz Struebe:
Hello list,
I working on new database wrappers for x2goserver. This wrappers using Perl DBI to access database, not shell. There is no sudo user for postgresql wrapper and for sqlite wrapper unprivileged x2godbadmin sudo will be created.
postgresql wrapper use triggers to check user permissions to modify table entries and views to allow user see only his rows.
New wrappers should be ready on weekend or begin next week.
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Morty,
On Fr 21 Jan 2011 09:21:37 CET Moritz Struebe wrote:
I didn't test them, but I also saw similar checks around fuse, sound
and printing, I think.
In case of x2goprint: if a user is not allowed to use x2goprint, there
are still spool jobs created which cram the server hard disk... So I
thought it better, to avoid this behaviour via a client control.
I also check the group memberships to report failures properly and to
reduce unnecessary SSH port forwarding...
But YES: actually we need a server command that return available
features and functions for a specific user...
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Alexander Wuerstlein -
John A. Sullivan III -
Kevin Moellering -
Mike Gabriel -
Moritz Struebe -
Moritz Strübe
-
Oleksandr Shneyder