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