|
Hi!
> Hi, I was lucky that you raised this here, as I missed the thread at wayland-dev. The thread and the posts are long, but I would like to share my first comments.
Sorry about that :)
> [...]
> 1. From [1], the list of privileged interfaces you provide is the following:
> "Screenshot applications (stills and video)
> Virtual keyboards and pointing devices
> Screen sharing (VPN, Skype)
> Hotkeys handlers (?)
> Session lockers"
> There are some one you missed, unless you are including it as part of the "virtual keyboards and pointing devices" bullet point. I'm talking about accessibility. Accessibility requirements are similar to virtual keyboards (in fact, a screen on keyboard
can be also an accessibility tool), although accessibility would probably need more. Some months ago I made an initial attempt to discuss accessibility needs for wayland. As part of that I sent two emails about specific needs and asking/guessing how it could
be solved at Wayland [4][5]. The more similar thing to a conclusion to those threads were this email [6], and I summarized it as "if we can consider an on-screen keyboard, or a screen reader trusted clients, but we can't consider as a trusted client the daemon
providing accessibility services, then we have a problem." I guessed if we could use DBUS authentication for that, but right now, probably more than just that would be needed.
It should include any software that generates input events. So, any UNIX process that wants to tell the compositor to inject some keyboard input events into the currently active app (I'd assume that also means said process needs to be able to receive input
events without getting activated -- I don't know enough of the Wayland protocol to know how this c/should be done), and any process that wants to simulate some pointer input (or multitouch, and again I'm not sure what else exists) could grab this permission.
Listening to and consuming kb events could be part of being a virtual keyboard, so that Orca can capture the keystrokes it need to process from the user and send all other strokes to the active app. The only question for me is how to find a very explicit/distinguishable
(visual / four or five words) description of what exactly that permission would allow!
> 2. From [1]
>
> "Apple OS X"
> <skip>
>
> " * spoofing attacks on the content of the authorisation dialog are (or were at least in the past) greatly facilitated by the API"
>
> Well, yes, it was greatly facility by the API. In fact, afaik, the easier API to global key event spoofing are the accessibility APIs. Somehow they needed to provide security exceptions in order to allow accessibility to be working [7].
Likewise on Linux, the Xtest extension makes implementing keyloggers incredibly easy!
> And somewhat related to all this, as we are talking about granting privileges, now and then you mention sandbox, on both the the thread and on your blog posts. Sandboxing was also an accessibility concern when it was made a requirement at the Mac App
Store [8]. That change broke several apps using the Accessibility APis. In theory accessibility and sandboxing works, but as the same Apple documentation says [9] "However, you cannot sandbox an assistive app such as a screen reader, and you cannot sandbox
an app that controls another app". I conclude from that that is not possible to provide a third-party screen reader through the App Store.
I'll keep that in mind. Thanks for the reminder. We do need some a11y expert to explain what kind of apps exist and what special relationship to the compositor they need, because neither Martin or I know anything about this... If you're aware of other
things that need to be thought of, please drop us an email!
> And this is all for now. I will read the thread and posts with more detail, and will go back if needed.
>
> Best regards
>
>
> Thanks,
>
> [0] http://lists.freedesktop.org/archives/wayland-devel/2014-February/013359.html
> [1] http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> [2] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
> [4] http://lists.freedesktop.org/archives/wayland-devel/2013-December/012532.html
> [5] http://lists.freedesktop.org/archives/wayland-devel/2013-December/012533.html
> [6] http://lists.freedesktop.org/archives/wayland-devel/2013-December/012617.html
> [7] http://support.apple.com/kb/PH14397
> [8] http://blog.boastr.net/sandboxing-in-the-mac-app-store/
> [9] https://developer.apple.com/library/mac/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXModel/OSXAXmodel.html
--
Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 |