Request for comments on security of authentication/authorisation UIs

[Alistair Buxton]

On 27 March 2014 01:30, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:

> The way we see things so far:
> - there will be a system-wide place to set a list of apps holding a
> privilege by default (so xfce4-screenshooter can take screenshots by
> default); I would recommend distributors to remove from that list any app
> that exposes a public API, and any app that only occasionally requires a
> permission rather than make sense only with the permission (for instance
> it's very debatable whether Skype should be able to record your screen 24/7
> since most users never use screen sharing)

I agree.

> - users should be given a UI to configure/override those default apps, and
> the UI should store their settings somewhere where userland apps cannot
> access (that's where we assume we have a process isolation mechanism). You
> can be absolutely sure that every DE will want their own phrasing and
> positioning of buttons (though there should be a default UI). the UI could
> be somewhat shared with the Preferred Apps UI and XDG Spec a Preferred
> Virtual Keyboard should of course hold the Virtual Keyboard capability
> - 90% of authorisation use cases should be managed by the default lists...
> How often do you change your screenshot/capture app, Audio/Video IM app,

I use multiple IM clients depending on what the other person uses. I
use different tools for screenshots and screen recording (video), so a
single "preferred app" setting is not practical. Permissions should be
stored on a per-app basis, and the permissions UI should reflect this,
at least in the reference implementation.

> virtual keyboard, clipboard manager, etc. compared to how often you use
> their features? Hence the authorisation UI is seen as being a fallback
> mechanism for situated needs. If expectionally or temporarily a user needs
> their Skype to record the screen or want to try out a new Virtual
> Chinese/Korean keyboard app, they should be able to do so 1) without
> remembering in which settings UI to fiddle to authorise the apps and 2)
> risking to forget they added the apps to their authorised lists and leaving
> some no-longer-necessary permissions to potentially harmful apps

I agree. It should be possible for apps to pop up a request when they
need some functionality. However, the popup should offer the following
options: "Never", "Not this time", "Just this time", "Always". Again
this dialog should be replaceable by the DE, so only the reference
implementation would need to show all the options. The "never" option
is of course there to prevent annoying apps from spamming requests.

> - Because some DEs or distributors may have different concerns about the
> trustworthiness of various apps, they should be able to ship their own
> security logic on top of system-wide lists. So basically what we're still
> brainstorming is an idea of Wayland Security Modules, which would be linked
> to compositors. If XFCE had a daemon acting as a compositor, then it could
> for instance replace the system-wide whitelist by a XFCE whitelist and
> prevent another virtual keyboard from being enabled by default (though it'd
> be strongly advised that this WSM respects the users' customisations of the
> white list)

I don't like the sound of "modules" and "linking" - this sounds like
compiled-in defaults to me, but maybe I'm taking the terms too
literally. I am slightly worried at the prospect of DEs using this
feature to force use of their own core apps. As long as the user's
settings always take priority over anything else I don't mind.

>> DEs should be able but not required to provide their own configuration
>> UI - this should be a reusable component like any other, and it should
>> work in any compositor regardless of which toolkit it uses.
>
> This is what happened for authentication with polkit as far as I remember,
> and there are Qt/GTK versions of the UI but I think XFCE and GNOME share the
> same one. Ubuntu later modified some of those UIs (possibly because they
> have passwordless root). In fact as I said in the post I'd rather extend
> Polkit to finally support capabilities without (annoying and
> spoofing-habituating) authentication rather than reinvent the wheel.

Yes, the most important part about this is that it doesn't drive the
user insane. If it does they (I) will just carry on using X.


-- 
Alistair Buxton
a.j.buxton at gmail.com