cc'ing gnome-keyring-l...@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-l...@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! _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
