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:
Hello,
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:
- "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.
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].
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
[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
--
----
Alejandro Piñeiro
|
