Yes. You have to privileged code handling input, either living in the kernel or in a privileged process. It's possible to write secure code, it's just very hard when you have as much code as the X server does (or...for that matter, the linux kernel, but that's a different issue). If you put the input server in a separate privileged process, you have to secure a lot less code, so the problem becomes feasible.
And note that it doesn't actually have to run as root, just as a priv user.
Posted Sep 9, 2010 23:45 UTC (Thu) by martinfick (subscriber, #4455)
[Link]
Additionally, this code would not likely be exposed to nearly the huge attack base that the current X server is exposed to. It would likely only be exposed to the proxied data, and perhaps to some user switching input code, but that is surely a greatly reduced attack vector than the current model.
Where are the non-root X servers?
Posted Sep 13, 2010 21:30 UTC (Mon) by oak (subscriber, #2786)
[Link]
And even that attack surface is reduced if that input daemon doesn't proxy the input, but only tells X which input device to use and on "hot seat" arrangements takes care of switching access rights on the input devices so that only the active X server can access given device at any given time...?