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.

On 03/26/2014 03:56 PM, Dodier-Lazaro, Steve wrote:

Currently on the Wayland ML, a bunch of devs are discussing security issues [0,1] and the need to restrict userland processes' privileges to e.g., take screenshots, act as virtual keyboards or read keyboard events for other apps, etc (basically introducing privileged interfaces that require explicit user authorisation). We've also been discussing how the introduction of Wayland allows for redesigning and securing authentication and authorisation UIs.

This has led me to question the way authorisation and authentication are currently done, and to write a couple of proposed requirements for both tasks. I'd be very keen on hearing the opinions of various DE developers on a blog post I've written [2], that focuses a lot on the infrastructure needs (both in Wayland and desktop environments). I'd also like to debate UX aspects of authorisation and authentication UIs. As far as I'm aware GNOME Shell implements a polkit agent and so relies on the polkit infrastructure for all its auth needs. Given the proposals I made (which really are ideas that need experimentation and refinement), what would fit within the GNOME way of doing things? What's the viewpoint of the UX people in GNOME? Can you spot any missing technical (security or UX) requirements in the post? Anything you disagree with and want me to review?

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.

2. From [1]

"Apple OS X"

"   * 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].

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.

And this is all for now. I will read the thread and posts with more detail, and will go back if needed.

Best regards

Alejandro Piñeiro

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