Request for comments on security of authentication/authorisation UIs

Thu Mar 27 02:30:59 CET 2014

> I can only speak for myself here (I am not a core dev), but I do agree
> that this type of security is needed.
>
> It should be implemented in such a way that once an application has
> been marked as "trusted" for a certain API, it can use that API in any
> compositor. So for example if you "trust" the screenshot tool, then it
> should work in Mutter or Kwin or Weston. This requires that both the
> security model and also the API it is protecting be standardized and
> therefore independent of any particular DE.

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

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

Thanks,

2014-03-27 0:07 GMT+00:00 Alistair Buxton <a.j.buxton at gmail.com>:

> I can only speak for myself here (I am not a core dev), but I do agree
> that this type of security is needed.
>
> It should be implemented in such a way that once an application has
> been marked as "trusted" for a certain API, it can use that API in any
> compositor. So for example if you "trust" the screenshot tool, then it
> should work in Mutter or Kwin or Weston. This requires that both the
> security model and also the API it is protecting be standardized and
> therefore independent of any particular DE.
>
> 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.
>
>
> On 26 March 2014 22:39, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:
> > Hi Alistair,
> >
> > I'm quite aware that the core Xfce apps (panels, desktop, etc.) don't
> run on
> > Wayland and so I'm not really questioning the development agenda of Xfce
> and
> > whether there is any interest in switching over to Wayland -- that's a
> bit
> > off topic.
> >
> > By "the XFCE way of doing things" I mean the emphasis on flexibility, as
> > XFCE is quite specific about ensuring that each and every of its core
> > components can be used standalone. Given that (and setting aside all the
> > compositor/libwnck issues), do core XFCE devs agree with Martin and I
> that
> > there should be some form of restriction to interfaces like using video
> and
> > audio devices, impersonating input devices, capturing other windows'
> > content, etc?
> >
> > If they do, how would they get around doing that on a XFCE ecosystem?
> Would
> > they want a LSM to take care of that completely independently of the DE,
> or
> > would they write their own UI for managing privileged clients and a
> daemon
> > in charge of distributing permissions? I think my questions are more in
> > those lines.
> >
> > Thanks,
> >
> >
> > 2014-03-26 20:56 GMT+00:00 Alistair Buxton <a.j.buxton at gmail.com>:
> >
> >> Hi,
> >>
> >> Xfce is fundamentally incompatible with Wayland due to the restrictive
> >> nature of the API. This means none of the Xfce shell can function
> >> inside any Wayland compositor without being completely rewritten.
> >> Specifically this is because there is no way to make libwnck function
> >> inside any Wayland compositor and no way for Wayland clients to manage
> >> windows (either their own or others). As such the question of how
> >> authorization dialogs function is completely irrelevant at this time.
> >> I don't really understand what you are even asking when you say "what
> >> would fit within the XFCE way of doing things?" - the answer is
> >> currently "anything that involves Wayland will not fit."
> >>
> >> On 26 March 2014 14:29, Steve Dodier-Lazaro <sidnioulz at gmail.com>
> 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
> >> > (including of course XFCE :) ) 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. In XFCE so far we haven't had any need for
> >> > authorisation
> >> > UIs, and been pretty much using polkit for any auth need as far as I
> can
> >> > tell. Given the proposals I made (which really are ideas that need
> >> > experimentation and refinement), what would fit within the XFCE way of
> >> > doing
> >> > things? How would you guys implement auth{orisation,entication}
> dialogs
> >> > in
> >> > XFCE if you had to do it? Can you spot any missing technical
> >> > 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
> >> > Free Software Developer
> >> > OpenPGP : 1B6B1670
> >> >
> >> > _______________________________________________
> >> > Xfce4-dev mailing list
> >> > Xfce4-dev at xfce.org
> >> > https://mail.xfce.org/mailman/listinfo/xfce4-dev
> >>
> >>
> >>
> >> --
> >> Alistair Buxton
> >> a.j.buxton at gmail.com
> >> _______________________________________________
> >> Xfce4-dev mailing list
> >> Xfce4-dev at xfce.org
> >> https://mail.xfce.org/mailman/listinfo/xfce4-dev
> >
> >
> >
> >
> > --
> > Steve Dodier-Lazaro
> > PhD Student in Information Security
> > University College London
> > Free Software Developer
> > OpenPGP : 1B6B1670
> >
> > _______________________________________________
> > Xfce4-dev mailing list
> > Xfce4-dev at xfce.org
> > https://mail.xfce.org/mailman/listinfo/xfce4-dev
>
>
>
> --
> Alistair Buxton
> a.j.buxton at gmail.com
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>

-- 
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/887ca436/attachment.html>