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

[Hashem Nasarat <hnasarat gmail com>]

cc'ing gnome-keyring-list gnome org

On 03/26/2014 10:56 AM, 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?
>
> 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/
> --
> 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
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Great article (erm...I mean paper)!

I strongly urge you to watch Stef Walter's talk from this past summer's
GUADEC:
http://www.superlectures.com/guadec2013/more-secure-with-less-security

Stef is the author of gnome-keyring (the secure storage daemon), gcr (a
set of reusable widgets to present various security-related things), and
seahorse aka "Passwords & Keys".

For one, I believe your designs rely too heavily on standard (though
well-designed & thought-out) dialogs since, as you acknowledged, that
users often have difficulty understanding context, let alone being able
to make proper security decisions.

I believe that the solution to better security understanding lies in
innovative UI interactivity. Stef talks about this more in depth in his
talk, and you seem to allude to it:

> In an utopian world, the user knows which data can be affected by an authorisation (e.g., whether their 
> bank website currently on screen will appear on a screenshot, which files’ content can be leaked to an app, 
> etc.) so s/he can make a `blink of an eye’ decision; the effects of authorisations should be tangible

But as an example, if an app would like to capture screen contents
outside its borders, it would express this desire to privilege moderator
(e.g. the wayland compositor?), which would then offer controls to the
user so that they may define the area permitted to the app.

Additionally, there should probably be one more requirement added to
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/#5-security-requirements
This being the ability for a non-privileged application to access stored
secrets (e.g. passwords stored in a password manager).
To provide another example of how to actively integrate the user into
this security-granting action, the app (say, a web browser) would issue
a call to, e.g., the compositor which would somehow present the list of
the user's saved passwords, and the user would actively have to double
click the password for the particular username/website (in addition,
perhaps the app could tell the compositor the desired username/website,
and the compositor would scroll the presented list to the suggested
password for username/website combo).

Also, you say:
> Hopefully others will agree with me and I will be able to take a FreeDesktop spec out of this article

I'm unsure what kind of spec you had in mind. To me, what seems most
useful would be a standard API for a finite number of security
requirements (as in section 5 of your paper), with concrete interfaces,
AND suggested guidelines / reference implementation (gosh, that sounds
like wayland/weston...) for each of the interactive security widgets for
the requirements.

Again, thanks for the email, the article, and all this research!