RE: Request for comments on security of authentication/authorisation UIs


> 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:
> "Screen­shot ap­pli­ca­tions (stills and video)
> Vir­tual key­boards and point­ing de­vices
> Screen shar­ing (VPN, Skype)
> Hotkeys han­dlers (?)
> Ses­sion lock­ers"
> 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>
> "   * spoof­ing at­tacks on the con­tent of the au­tho­ri­sa­tion di­a­log are (or were at least in the past) greatly fa­cil­i­tated 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]
> [1]
> [2]
> [4]
> [5]
> [6]
> [7]
> [8]
> [9]

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]