Slashdot Mirror
The Guy Responsible For Ctrl-Alt-Del
Gannett News is running a story about David Bradley, the IBM engineer who, in 1980, coined Ctrl-Alt-Del. Interestingly, he meant for it to remain a developer-only tool, not something for end users, and certainly not to have Windows users change their passwords or logoff. He also says he chose those keys specifically as it's not a key sequence that can be struck by accident.
Many people rag on this, but it actually made some sense at the time. Microsoft has removed it from later versions of Windows for convenience, not security, purposes.
For people who don't know, WIndows NT 4 (and perhaps 3.5 and earlier?) required one to hit CTRL-ALT-DEL to get a login prompt. Many people complained, not seeing the logic in it, but logic there is.
CTRL-ALT-DEL is can never, ever be trapped by an application -- unless Windows has hosed completely, it's guaranteed to get the OS's attention. Having to hit it to get a login box means that no other application can fake a login box. If they tried, CTRL-ALT-DEL would bring up the task manager instead of a login dialog.
So regardless of whether you like it, the minor annoyance served a good purpose and was actually a fairly clever design decision. Much smarter than, oh, allowing macro viruses to execute by default.
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
Why is it that everyone thinks that Ctrl-Alt-Del has some special hardware interrupt, or something else that makes it magical?
The BIOS traps that combination (through the normal keyboard interrupt) and initiates a system reboot.
Problem is, if your OS isn't using the BIOS for keyboard input (pretty much every modern OS uses it's own keyboard handling code) then the OS determines what this key combination does.
In either case, it is software that determines what that key combination does.
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
Not quite. Interrupt processing by the hardware is the same for real and protected modes (which are internal to the processor).
All key press/release events generate the same hardware interrupt (normally the keyboard is wired to the IRQ1 line of the interrupt controller). Standard BIOS setup configures the 8859 to generate Int 0x9 for this IRQ. The keyboard interrupt handler is then charged with identifying the Ctrl-Alt-Del combination and acting on it.
The default BIOS action is to triger a software interrupt (Int 0x17 IIRC). The motivation for this was not to prevent interceptions. Rather, this conforms to the policy of having BIOS entrypoints go through software interrupts (in this case allowing any program to generate a soft-boot).
Well, aside from your comment indicating you to be a total jackass, there is actually a good reason behind the CTRL-ALT-DEL sequence in NT. It's a security feature.
"The CTRL-ALT-DEL key combination in NT disables user mode programs so a trojan program cannot intercept the user's name and password during the logon process. No user mode programs can be run until a valid logon has occurred. This is called restricted user mode. The CTRL-ALT-DEL key sequence indicates that there is a physically connected keyboard that the keystrokes are coming from. During the logon process, the Winlogon service passes the user's point of authentication, name, and password to the client/server (CSR) subsystem. The CSR passes the information to the security reference monitor which checks the Security Accounts Manager (SAM) database against the received information to see if the user is authentic. If so, a valid access token is generated and returned back down the line to the processes that sent the information."
Read more here.
That is, that key combo cannot be intercepted by applications thus making it impossible to create infamous fake logins for grabbing user credentials mere looks-like-login-screen
o l\Keyboard Layout registry entry. This changes the key mappings before the system processes ctrl-alt-del.
This is actually untrue. There are several ways to capture ctrl-alt-del in Windows. One is by remapping the keyboard with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr
The idea of a secure access key is a good one, but MS has a broken implementation since they allow it to be circumvented.
You can see the video here. My apologies for the crappy news.com link.
Who's the black private dick, who's a sex machine for all the chicks?
This feature is properly known as a SAK - Secure Attention Key. It's an old security feature used to prevent hijacking of trusted consoles, as you said, and is implemented on many systems. The perennial place where it's needed is university computer labs, where logging in and then leaving a fake login prompt running to capture passwords is has always been considered good clean fun. (To implement it properly, one should print a "wrong password!" message, and then exit the user session completely giving the user the real login prompt)
The basic idea is that the OS traps the SAK and does something obvious (like give you a login prompt) to keep a user from running a program pretending to be the OS. Since the OS doesn't let the user handle the SAK, security is maintained.
Linux supports SAK, however it's never really been properly deployed by distributions. Part of the reason is that nobody's ever really standardized on what the SAK key should be. If SysRQ is enabled, than Alt-SysRQ-k will cause a SAK event in the kernel. Otherwise, the keyboard driver can be configured by root to use any key sequence. One key sequence I've seen used is Alt-SysRQ-PageDown, but there's really no particular standard.
When SAK is raised in linux, all programs running on the current terminal are force-killed. It's then expected that init will provide a new login prompt there.
This leads to the second problem with SAK on Linux, namely that most users run X on workstation machines. If you SAK while X is running, the kernel kill -9's X... Which trashes your video card, leaving the system in an unusable state. Which is probably not what you wanted. Some video drivers and cards in X may be stable enough that, if you're running xdm/gdm/kdm etc., it may be able to restart X and give you an X11 login prompt - but the console will still be trashed, so you won't be able to exit out of X afterwards (or eg. with ctrl-alt-f1). It used to be the case that you could store the video settings for your console and run a program (eg. restoretext etc.) to fix them, but that hasn't worked on any modern video card in years. In addition, if you just escape out of X and then fix the console, X will re-trash your console as soon as you return to it, since it only stores the console settings from when X was started, not the current settings. Hence, X and your console program get in a fight and you probably end up crashing the video card and having to pull the power plug out or something if you do this a lot.
Confusing things even more, XFree generally defines its own internal "SAK"-like key sequence, Ctrl-Alt-Backspace. This isn't actually an OS-level SAK though, it just instructs X to quit. And not surprisingly, it often doesn't work due to XFree bugs (and may be trappable by user apps).