Subject: Re: wsmux inject
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 03/14/2006 16:01:08
Steven M. Bellovin wrote:
> On Tue, 14 Mar 2006 23:17:12 +0000 (GMT), Iain Hibbert
> <firstname.lastname@example.org> wrote:
>> On Wed, 15 Mar 2006, Valeriy E. Ushakov wrote:
>>> With current code you can inject events into the mux for processes
>>> that read from the mux (as your hexdump exepriment demonstrates),
>>> e.g. you should be able to inject events for x server to read from the
>>> mux, but you cannot inject "terminal input" for /dev/ttyE*
>> Hm, I see.. (vaguely :)
>>> To feed terminal input from user space, you need a way to inject raw
>>> scancodes that need to end up being passed to wskbd_input.
>> Well, it seems that I could do that quite simply by creating a
>> WSKBDIO_INJECT ioctl in wskbd_displayioctl() though thats a bit of a
>> I'm thinking it would likely be better to make a pseudo-device that would
>> attach as a wsbkdN when necessary, not sure if that will work as planned.
> Have the ability to inject keyboard and mouse events, though useful for
> many purposes, poses serious security issues that should be thought
> through. The issue is ancient; see
> http://securitydigest.org/unix/archive/004 or
> http://securitydigest.org/unix/archive/015 about TIOCSTI, for example,
> or the discussion about allowSendEvents in the xterm man page.
> >From that perspective, requiring a separate driver is a good thing,
> since it's then easy to exclude from the system.
> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
FYI, this is in the context of Bluetooth. I believe that we need to
have something. It isn't necessarily true that having a mechanism that
is accessible from userland is a good idea, but at least from the kernel
(or a trusted root process) we need the ability.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191