From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.5) Gecko/20050109 Fedora/1.7.5-3 Description of problem: I have written a patch against xscreensaver-4.19 as available on Jamie Zawinski's Web site which adds a "New Login" button to the xscreensaver password dialog which, when pressed, initiates a dialog with gdm over /tmp/.gdm_socket and asks it to start a new flexi server. This would allow computers used by more than one person to easily provide multiple graphical logins on demand. The patch has one shortcoming: The mouse is either invisible or entirely disabled during the lifetime of the xscreensaver password dialog, so, while the button works when running the password dialog from a test utility (part of xscreensaver), it doesn't work "live", because there's no mouse available for clicking on it. Version-Release number of selected component (if applicable): xscreensaver-4.19 How reproducible: Always Steps to Reproduce: 1. Log in on gdm. 2. Lock the screen. 3. Good luck to anyone else trying to log in via gdm. Actual Results: It's very difficult to start another graphical login manager, let alone another GNOME session. Expected Results: There should be a way to start a new login screen - much like fast user switching on Windoze or OSX. Additional info:
Created attachment 111191 [details] New button to allow logins from the xscreensaver password dialog
Created attachment 111465 [details] Final (?) version of the patch, adding mouse functionality during password dialog I finished off the patch. Thus, the mouse cursor becomes visible during the password dialog. The cursor is trapped inside the password dialog (as it should be), and the user can click on the "New Login" button to start a new flexi server. This patch is against version 4.20 of xscreensaver.
Hi Jamie, What are your thoughts on this patch? Would something like this every make it upstream?
Hi! I talked to jwz about this, and he was not very enthusiastic about my first patch (the one where the mouse wasn't working) because when he tried starting a flexi server, it messed up his X. I can forward you the messages we've exchanged, if you'd like. I sent him the new, fully working patch, but I haven't heard back from him yet (as of 2005-02-28 10:06:27 MST).
Yeah, the one time I tried to play around with gdmflexiserver it fucked up my machine real bad. I haven't had the stomach to try again. I don't object to a gdmflexiserver button in principle, but if my experience is any indication of what other users are going to experience, we might as well label that button "Self Destruct". Also, after thinking about it some more, I think it's probably a lot less fragile (and hopefully no less secure?) to fork/execvp the "gdmflexiserver" program than to explicitly speak to gdm through a socket. The gdm protocol looks marginally hairy, and I wouldn't trust it not to change on us at some point.
I would be the first to change my patch over to fork/execvp instead of re-implementing part of the protocol from the gdmflexiserver sources, however, I share Jamie's jitters over executing stuff from the login screen. We will need to think of a way to determine the path to the gdmflexiserver binary securely so that, when we finally execute it, we can be relatively sure that we're executing the gdmflexiserver binary and not another binary named gdmflexiserver. To this end, I can think of 2 different ways: 1. Path search: pfile = popen ("which gdmflexiserver", "r") ; Read off the path (if any) from pfile pclose (pfile) ; The currently logged in user may prefix the PATH with her own directories and we may end up executing some other binary. A malicious user could /fake/ a login screen and harvest a password like so: xinit ${HOME}/my_fake_gdm_login_screen_I_wrote_in_GTK -- :1 2. app-defaults X resources can be overwritten by the logged in user, correct ? If so, my view of the consequences is reduced to the scenario speculated about above. Is there someplace we can specify the path to gdmflexiserver in a way that cannot be overridden by the currently logged-in user ? Another concern: The currently logged in user could choose to run her own version of xscreensaver, where the button is totally hacked up, so it will do what she wants, irrespective of what we tried to make it do. Once again, the fake login scenario comes to mind. Bottom line: How can a user who walks up to the screenlocked computer wanting to log in be absolutely assured that when she presses the "New Login" button, she will get a brand-spanking new, completely genuine gdm login screen ? I suppose, looking at the way OSX does it, I'm lead to conclude that the above question can be asked in any "Switch User" scenario. Perhaps the most secure way to allow multiple logins is for gdm to "fork off" the session to a new X server after authenticating the user, and to switch vts to the new X server which houses the user's session. In such a case, the genuine gdm login screen would always be present, and a person walking up to the computer need only browse through the vts to find it. Even so, a gdm login screen could be faked on a vt other than the genuine one, however, there would always be at least one genuine gdm login screen on /some/ vt. The fake one could be killed with a Ctrl+Alt+Backspace and, unlike the genuine one, it wouldn't come back. This is something an extremely paranoid user could do to be absolutely assured that she is logging into a genuine gdm. Of course, this would not be very convenient for non-computer-literate users, who are unaware of the hidden powers of Ctrl+Alt+F([1-9]|1[0-2]). For instance, I would have to teach my mom to "walk through all the F-keys until you find the blue login screen".
xscreensaver's primary function is to execute programs, so I think we can assume that if an attacker can manipulate the $PATH that xscreensaver sees, the game is already lost. E.g., they could just as easily replace "qix" as "gdmflexiserver". (Though this is made somewhat less likely by the compile-time -DDEFAULT_PATH_PREFIX=/usr/X11R6/lib/xscreensaver) > The currently logged in user could choose to run her own version of > xscreensaver, where the button is totally hacked up, Or, today, they could run a hacked-up gdm that makes it look like nobody is logged in when really someone is and it's logging passwords. This is not a new attack, and not made worse, I think, by a gdmflexiserver button. > Bottom line: How can a user who walks up to the screenlocked > computer wanting to log in be absolutely assured that when she > presses the "New Login" button, she will get a brand-spanking new, > completely genuine gdm login screen ? Only by rebooting, and probably not even then. You can't even assume that C-Alt-BS will actually reset the server: the attacker might be running X with DontZap and trapping that too. For that matter, the machine might be running a trojan kernel booted off a USB disk. It depends on how paranoid you want to be, and how persistent you think an attacker might be.
Created attachment 111511 [details] Instead of socketeering over to gdm, simply run gdmflexiserver Well, I was assuming the user didn't have root access to the machine. I was also assuming that the machine couldn't be mutilated hardware-wise. Anyhow, this patch executes the value of the resource "passwd.login.command" using system(), instead of connecting to the gdm socket.
Instead of system(), use fork_and_exec() -- see do_prefs() and do_help() in splash.c. (You'll have to make it not be static, or put do_loginmanager() in splash.c) Also, I'd arrange for loginmanager_p() to be called once at startup instead of every time the passwd window is created. Store the command in struct saver_preferences along with demo_command and help_url.
Created attachment 111516 [details] Modified the patch to follow Jamie's suggestions
So, ummm ... not to impose or anything, but, ummm ... what, if anything, is to become of this patch ?
Created attachment 111691 [details] new patch This patch should work against xscreensaver 4.20 (line numbers are slightly off.) Please try it and let me know what you think. If it seems to work, I'll include this in 4.21. I made it be less paranoid about the command it's executing, since I think that if $PATH is attackable, we've already lost. Also, the button is there if the "newLoginCommand" resource is set at all (it doesn't sanity-check it first.) It does, however, only let you click the button once (to avoid launching multiple copies of gdmflexiserver.) If you dismiss the dialog (e.g. with RET) then the button will be active again next time. Use configure --with-login-manager to turn it on by default. On my FC3 system (2-head xinerama, nvidia drivers) running "gdmflexiserver" is still a "self-destruct" command: if I run it, it totally fucks my machine and I have to ssh in and kill X and gdm to get it to come back. I can't even switch VTs. So, you know, color me unimpressed with this new facility.
Well, it works perfectly. Love the "Self Destruct!" label :o)
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there haven't been any updates to the report in quite a long time now after we've requested additional information, we're assuming the problem is either no longer present in our current OS release, or that there is no longer any interest in tracking the problem. Setting status to CANTFIX, however if you still experience this problem after updating to our latest Fedora Core release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thank you in advance. (this message is mass message)