From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.18-gps i586) when using run-level 3 and startx, any user can gain access to the user at the console's shell by simply pressing ctrl-alt-backspace at the console or switching to the virtual console that started startx (ctrl-alt-FunctionKey) and then pressing ctrl-C. This can be done even if the X console has been locked. I have verified that this problem exists on RH 6.0, RH 6.2 and RH 7.0. Reproducible: Always Steps to Reproduce: 1. configure machine to use run level 3 (modify /etc/initab if necessary). 2. log in any user 3. run startx to bring up the x console 4. lock the x console (using whatever means are installed on the machine, it doesn't matter). 5. press ctrl-alt-backspace (or ctrl-alt-FunctionKey followed by ctrl-C), you will now be at the text mode prompt of the user that was using the x console. You have now broken in to that account. Actual Results: You will have complete access to the user account, imagine if root was logged in! Expected Results: the login shell should have terminated so that when the X console was gone it would not be possible to access the account without at least providing a password. One solution would be to require authentication when startx terminates.
You can change this with the 'DontZap' parameter in your XF86Config or XF86Config-4.
This problem is not yet resolved. I indicated two ways to gain access to a user's account one of which was to use ctrl-alt-backspace, that security hole is plugged by uncommenting DontZap in the XF86Config file. The other method is to switch to the virtual console that the user used to run startx (using ctrl-alt-F1, ctrl-alt-F2, etc) and then press ctrl-c. That hole still exists even with DontZap uncommented.
No - there is NO security hole. A user with physical access to a machine can do a lot of things. If you do not want someone mucking with things then do not give them physical access. If one needs secure physical access, it does not exist period. If you want to stop someone from switching to a VC, then boot the system in runlevel 5 and disable all vc's completely. Again, I repeat - there is no security hole - this is a local site misconfiguration. Even when configured to boot in runlevel 5, with no VC's available, if a user has physical access to a machine, they can do all sorts of things to get access, and it is up to you to read up on security howto's and whatnot to reconfigure the box to be as secure as you need it to be including passwording the CMOS, passwording LILO and disabling floppy and CDROM boots. This is a bug report system however, not a security tutorial, so please read the Security documents in the /usr/share/doc/HOWTO directory if you want to set up a fairly secure machine. Again, do realize, and I stress this - ANY machine with physical access is insecure *period*. If you need help configuring secure access, please join our mailing lists.