Hiding keyboard state

[Keith Packard]

> But I don't think this is a huge issue for us anyway because we don't
> want to support simultaneous input from non-xpra clients, and if
> applications modify the keyboard state programmatically.. things are
> likely to get out of sync no matter what we do.

Cool.

> Just a thought: could this be tied somehow with selection ownership?
> A window manager would be expected to have more privileged access, and
> this is usually arbitrated through selections.

I'm not sure what you're thinking could work here, but I want privilege
to be secure, which to me means being mediated by an agent with more
authority than the base session user.

As such, window managers would need elevated privileges of some sort,
along with input systems and compositing managers.

> Excellent, we'll be happy to test any security changes, if anything to
> ensure that it doesn't break our stuff too much!

I've got a branch started in my X server git repository that is hacking
on the security extension. What I want to do is audit all protocol
requests and characterize their operation in terms of information
disclosure so that we can figure out what we want to control and
how. That's pretty much already captured in the existing X/SELinux and X
security extensions, so I don't think will be all that much new work.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160708/c3525584/attachment.sig>