Request for comments on security of authentication/authorisation UIs

[Steve Dodier-Lazaro]

Hi,

> Carlos Silva r3pek at r3pek.org via xfce.org
>
> > On Wed, Mar 26, 2014 at 11:07 PM, Alistair Buxton <a.j.buxton at gmail.com>
wrote:
> > 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.
>
> I agree with you. This should really be DE independent. I can see it in
some
> place like kdbus with some interface that if an application shares an API
with
> some requirements, kdbus should enforce them. Compositors/DE's can in
this
> case register some kind of callback to when kdbus need user authorization/
> authentication and then just provide the necessary UI.

Polkit requires that an authentication agent is registered, and it works on
a first-come-first-serve basis, afaik. That means a good session starter
will register its polkit agent before reading up any form of userland
autostart file (.profile, stuff in the XDG AutoStart spec, etc). Otherwise
an attacker may get their own agent registered.

There ought to be a way for the UI and for the security policy to be chosen
when a user's session is started. The Wayland protocol could state that
compositors must provide a "authorisation agent" registration API just like
polkit's, or must rely on polkit's reviewed authorisation and
authentication agents. Then I assume DEs' session files would tell what
compositor they're using and a full path to the UI they'll register (or
they can do however they're already doing for polkit). Because compositors
set quite a lot of how windows are handled I think it's the place where a
UI should be shipped - so it can be made consistent with the experience
provided by the compositor (for instance a tiling compositor may want to
manage dialogs differently from Gnome Shell and from a classic window
manager).




> Alistair Buxton a.j.buxton at gmail.com via xfce.org
>
> > 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.

Yeah, that's where the analogy stops between trusted apps and favourite
apps. There could be a reference UI where users write lists of apps they
trust for a certain task, but then we need to find a good mapping between
each permission and its corresponding task. One could then just make the UI
so that the first item of this list is the preferred app started by
xdg-open. In fact, in my own hypothetical OS I'd possibly restrict
downloads into the user's home directory for trusted "web browsers", "IM
apps" and "download/P2P apps" (though any app could download stuff to its
own sandbox).



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

I think Never and Always are not the most optimal thing to do. From the
user perspective, a spammy app will either be identified as spammy and
removed, or given an Always permission so it finally shuts up. It often
makes sense to give one-time or session-long permissions and having these
options selected by default would avoid users selecting the dangerous
Always option. If users want to make it permanent it's probably better to
include a link to the "Trusted Apps" UI (which is alas missing in my last
drafts on the post).

Never is suboptimal because it's a time setting that would apply to Deny,
while all others apply to Allow. For me it creates a cognitive dissonance,
some users may get confused as to whether to click "Allow" or "Deny" (just
now it took me some thinking to decide what you meant and I'm still not
sure what the semantics of "Never" -> "Allow" would be). If a packaged app
is spammy, distributors should identify and remove it from their repo (not
the user's responsibility to make trust assumptions instead of their distro
community, imo). If an unpackaged app is spammy and asking for something
that was just denied, the "Deny" option should be highlighted and the UI
could write "(recommended)" next to it. If the user installed the app they
should be able to uninstall it as well. A clever authorisation UI might use
distributor-proprietary techniques to point out to the requesting app in an
App Manager, though. This could come among the options of the "Help" link.

One important thing is I'm trying to limit the number of possible
interactions in the UI. The most common use cases of the UI would be
session-long or one-time permissions being granted, and the user should
have easy but indirect access to:
- explanations on what a permission is
- an advanced UI to manage permanent permissions
- an advanced UI to blacklist (possibly same as above) or uninstall apps

In a sense the "Help" and the "Manage permissions" links are already a form
of duplication I need to solve.


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

I don't think most users would have the expertise to replace a LSM (and
likewise a WSM). I don't think either that anybody can manage a Tomoyo,
SELinux, AppArmor and DAC policy and figure out what AC rule caused an
access to be denied when they need to get the job done and bypass AC.
That's why for me there should be a single module doing MAC at any time,
never more. Now of course in the case of Wayland SM, the modules should be
linked to the compositor at the very least, and even better to the session
the user starts (which allows multiple desktop environments and experiences
for a given compositor).

The module is responsible for the "how" security is done. The "what" is
typically an AC policy or other form of security logic, and this should be
accessible and customisable by the user -- though very obviously the
user-customised version of it should sit in one of those directories
protected from common userland apps. Right now it's only safe to ship
system-wide defaults (or to store per-user data outside ~ and provide means
for non-root users to manipulate such data...).


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

The very reason why I'm getting involved in this -- and asking the opinion
of others -- is to help graphic stack devs (not quite your UX experts ;) )
figure out how to best manage security interactions so users don't go mad.
However it's fairly obvious to me at this point that a permission system IS
mandatory to bring the most elementary security to userland.

Thanks,


-- 
Steve Dodier-Lazaro
PhD Student in Information Security
University College London
Free Software Developer
OpenPGP : 1B6B1670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20140327/d45cae39/attachment.html>