Hi Reinhard,
On Mo 18 Jul 2011 14:06:04 CEST Reinhard Tartler wrote:
As user foo I execute /usr/bin/x2gosqlitewrapper, this wraps an execvpe call around the Perl script /usr/lib/x2go/x2gosqlitewrapper.pl. The execvpe call evokes a change of the effective UID/GID as /usr/lib/x2go/x2gosqlitewrapper.pl has its setuid bit set.
So this trick effectively disables perls internal suid check somehow, and I currently don't see what this non-suid wrapper does differently than the shell that tries to execute the script.
Ok. Good question.
What you can try out is: do a chmod 6755 /usr/bin/X2gosqlitewrapper and a chown x2gouser:x2gousers /usr/bin/x2gosqlitewrapper and then call x2golistsessions (on a server that uses sqlite as X2go db backend). You will get a kernel complaint (or libc) that this is not allowed with the current kernel configuration.
I just did: -rwsr-sr-x 1 x2gouser x2gousers 5388 2011-07-18 00:12
/usr/bin/x2gosqlitewrapper* -rwxr-xr-x 1 x2gouser x2gousers 10094 2011-07-18 00:02
/usr/lib/x2go/x2gosqlitewrapper.pl*And everything works as expected. You need to become more specific what you observed.
I had an error messages, two lines, all written in capital letters,
noticing me about some kernel option/flag or something not set. I
cannot reproduce this now... :-(
Hmmm... Ok... so maybe we should change the set bits accordingly?
Now after reading the perlsec manpage, let me quote this part:
,---- | Security Bugs | | Beyond the obvious problems that stem from giving special | privileges to systems as flexible as scripts, on many versions of | Unix, set-id scripts are inherently insecure right from the | start. The problem is a race condition in the kernel. Between | the time the kernel opens the file to see which interpreter to | run and when the (now-set-id) interpreter turns around and | reopens the file to interpret it, the file in question may have | changed, especially if you have symbolic links on your system. | [...] | | The use of suidperl is considered deprecated, and will be | removed in Perl 5.12.0. It is strongly recommended that all | code uses the simplier and more secure C-wrappers described | below. | | If the kernel set-id script feature isn't disabled, Perl will | complain loudly that your set-id script is insecure. You'll | need to either disable the kernel set-id script feature, or put | a C wrapper around the script. A C wrapper is just a compiled | program that does nothing except call your Perl program. | Compiled programs are not subject to the kernel bug that | plagues set-id scripts. `----
Reading this, we should definitely change the setuid bits as you
propose above. I cannot reproduce the problem I formerly had. When
trying out the file permissions you propose above everything works for
me as well...
In any case, I guess no file should be made actually writeable by the x2gouser. Moreover, is the script run in tainted mode this way? AFAIUI no, but we can (and should) set it forcefully in the perl script.
Then we should also make sure, no one can su to the x2gouser,
shouldn't we? Or at least make sure that x2gouser cannot change
permissions on that file? How that?
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...