Re: User sessions, system request

[Jonathan S. Shapiro]

On Wed, 2008-01-30 at 06:54 +0100, address@hidden 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