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

["Jasper St. Pierre" <jstpierre mecheye net>]

Hi Steve,

This is exactly the sort of design I love to see, and it's what I was strongly pushing for. This sort of an approach of designing APIs after use cases on a one-by-one basis is what GNOME design is about, and it makes me a lot more comfortable than a generic request/response system.

I'm not a UX designer, so I can't speak to the flow of the system you've designed, whether it fits in with our plans, or if we even want such a widget to display or provide credentials in the first place. It's simply an example, of course.

I feel like we can do this on a case-by-case basis, by looking at places where security is poor or limited (Portals, Intents, and the ability to choose user content by delegating to a system component is the most often quoted example), and designing a new solution that takes security measures into account.

Things like screen sharing are more generic and difficult. Imagine I have a program like OBS: the goal is to capture my desktop and stream it to a service like Twitch. This is a perfectly acceptable use case for screen sharing, but we don't want the user to have their screen shared when they don't want it.

A design here could be to have an indicator available to the user when an application is capturing the desktop, and when the user clicks it, they can see all the applications currently recording and have the ability to stop the recordings, flat out kill the app, or go to a more detailed settings panel to see exactly what the applications are capturing.

While this design may not be perfect, it affords what I think are the key frustrations with SELinux: it gives transparency into what the application is doing (the user will notice a red icon to mean their screen is being recorded), why it's doing it (well, if they're running OBS, then they want to stream this game), and gives them the ability to set their own policy.

At this point, I'm reminded of tef's post, asking, "What's your threat model?" [0]:

Who is attacking? How are they attacking? Will we know when somebody's attacking? Will the user know when somebody's attacking? Can we know a legitimate actions compared to an illegitimate one? Can the user know a legitimate action compared to an illegitimate one?

How much of a choice should the user be making, and how much of a choice should we make for the user? What choices can we, or the user make? What information do we expose to the user in the case of a questionable action?

How can the user stop a perceived attack? Should they stop a perceived attack? What can go wrong if the user stops a perceived attack that is a legitimate action?

We need to be asking those questions, and more, rather than talk about GtkPasswordForms and the X,Y positions of widgets. Those are just technical implementation details of how to implement a more secure design. We can crank those out in a day. The tough part is the thinking towards making a more usable, transparent, secure system in general.

[0] http://programmingisterrible.com/post/67851666020/whats-your-threat-model

On Fri, Mar 28, 2014 at 9:01 PM, Dodier-Lazaro, Steve <s dodier-lazaro 12 ucl ac uk> wrote:

>>> 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).

>> 

>> This idea is brilliant! Password store access definitely needs protection from

>> abuse... by other apps and oneself (if malware kicks in). However I hadn't dared

>> to ask users to click on a permission prompt for every login. Is it still better

>> than a SSO authentication? Your 'somehow' and the GTK 3.12 ChangeLog make me

>> think that GtkPopovers could be used when hovering a password field for which

>> there is a stored password (e.g., the browser always reports to the keyring and

>> the keyring presents the popover the UDAC way; browser can't see it). That would

>> make the password re-use a one-click interaction without intrusive dialogs!

>  

> 

> These sort of ideas are what I mean by designing the security systems and desktop together. These are the sort of ideas that we need to be thinking in terms of: rather than a protocol with accept/deny/prompt responses, think about it in terms of the entire user flow.

> 

> Instead of asking "is it OK for this application to access the keyring?" where the compositor really can only reply with yes/no, we need to instead think of redesigning the entire flow. No, it's really bad for an application to access the entire keyring. Give them discriminated access to the password the user wants the browser to access.

> 

> That's why I'm deathly afraid of a generic accept/deny/prompt protocol. It reeks of prompts like "do you want to accept this HTTP certificate" showing up, without any way of 1) digging for more information, 2) knowing what will break if the user chooses either option, 3) changing the decision at some point in the future if the user chose the wrong one.

For me the first step was/is to identify where we need to change the current "do whatever you want" approach, the next step is to discuss what interactions must be supported and what information / APIs are needed to support such interactions. Of course I don't want a XACE-like set of hooks where security experts have to figure out what they're supposed to do and what's gonna happen next!

For the password manager so far I'd say one could support two types of requests:

A request to display a credentials-providing widget (RDW) needs:

- The ID of the app*

- What credentials to provide

- whether the widget should be a "hover" widget or whether it should be embedded in the UI

- some form of protocol to negotiate the position [and size if embedded] of the widget, and to indicate when the hover widget must be display

A request to directly access credentials (DAC) needs:

- The ID of the app*

- What credentials to provide

- Anything else?

A DE could decide (or not) to gather the following information to support its decisions:

- how long the app was launched for, what permission requests it sent before

- the history of (security) interactions between the user and the app

- trust assumptions from the distributor about the app (difficult thing to do without distributors getting involved...)

- pretty much anything

A default policy could be:

- for RDW, allow providing a widget provided that the negotiation of position/space results in the content of the widget being displayable in full (e.g. indicates credentials will be surrendered to the app and content of said credentials). Then the user's action with the widget provides the authorisation.

- for DAC, make a decision based on one's own logic or by asking the user in a way or another (DEs who have a specific idea of what policy they'd like should suggest that the information they require be made accessible by other DEs/compositors too)

This could be made awesome in GTK+ by providing a GtkCredentialsForm with a GtkIdField and GtkPasswordField (or whatever one wants to name them), that already contains all the logic to negotiate space / manage the hovering of the hover widget (GtkPopovers) on behalf of the client. And also by providing a GtkCredentialsSelector for the rare use cases where a user may want to select and give specific credentials to an app (though I can't think of a use case myself where this would be clever to do). The only thing that's important to me is that the code that actually displays the credentials and indicates the keyring app they should be sent over IPC to the requesting process should run in a third-party process. It should be obvious that we cannot entrust the requesting process with the task of displaying credentials itself!

Jasper, what is your opinion on this? Would you think this is a decent way of approaching the problem? Any information that's missing (1) ? Is it clear what allowing/denying implies from the DE perspective (2)? [I don't think there's any way to change the decision though for this specific topic -- a leaked secret is leaked!]

If you want, we/I can set up a (more or less formal) process (e.g., the three questions above) to evaluate whether a proposed API holds up to expectation, for each permission we're willing to discuss.

PS: on app IDs, one should consider the ability for a set of binaries to share an identity... some apps are built with multiple binaries after all. Not sure what's the preferred way around identifying apps

Thanks,

--
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

--
  Jasper