On Wed, 2008-01-30 at 06:54 +0100, [EMAIL PROTECTED] wrote: > > And in a way the program cannot detect. For example, the alt-SysRq > > was pretty much designed for this purpose. However, it is unusable: > > if we find out that a program is malicious, and we want to stop it > > immediately, pressing alt-SysRq means first pressing alt, which the > > program can see. In response, it can do its worst (thinking it's > > about to die anyway). This must be avoided. > > To be honest, the bit about Alt sounds a bit too paranoid to me...
Given how common keyboard sniffing software is these days, it is not overly paranoid. But I'm not sure that ALT is required. On most keyboards, SysRq is an *unshifted* key. Even if ALT is required, there is a fairly "simple" solution: inject a low-level keyboard driver that captures key code sequences from the keyboard. This state machine confirms that each key code sequence is "well formed", and passes the key code sequence along (unmodified) only when the full sequence has been seen. If the key code sequence for SysReq is seen, it is hijacked. Note that on modern machines this means that the low-level USB channel driver, keyboard driver, and all USB hub drivers must be trusted. More broadly, the "drivers" for any secure input and output devices, and any channels used by those devices to communicate to the CPU, must be managed by 100% trusted drivers. A secure system cannot let those drivers be replaced and remain secure. This is a well-known issue. It's known as the "trusted path" problem. Unfortunately, this includes the window manager, and therefore the video subsystem... shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
