Steven M. Bellovin wrote:
> On Tue, 14 Mar 2006 23:17:12 +0000 (GMT), Iain Hibbert
> <plunky@rya-online.net> 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
>> bodge..
>>
>> 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

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191