[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User sessions, system request

From: Jonathan S. Shapiro
Subject: Re: User sessions, system request
Date: Wed, 30 Jan 2008 10:46:42 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]