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
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
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.