Comment on global shortcuts security

[Pekka Paalanen]

On Wed, 26 Sep 2012 09:14:15 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 25 Sep 2012 18:07:51 +0200
> Piotr Rak <piotr.rak at gmail.com> wrote:
> 
> > Hi,
> > 
> > 2012/9/25 Pekka Paalanen <ppaalanen at gmail.com>:
> > > Hi Piotr,
> > >
> > > it sounds like you make a fundamental assumption on something, that
> > > makes global shortcuts insecure, and so you set out to solve these
> > > problems.
> > >
> > > What is it that you assume?
> > > What is the root of the problems?
> > > What are the problems you are trying to solve?
> > >
> > 
> > I should have state this more clearly, but the problem is - how to do
> > global shortcuts in application in secure way. The issue was raised
> > during XDC. Video of talk can be watched online
> > http://www.youtube.com/watch?v=hJpiJii44oo&feature=relmfu - discussion
> > about wayland input handling starts around 23:30s.
> > 
> > Those are my thoughts/comments after watching it, on one questions
> > that was left open there.
> > 
> > > Sorry, but I just couldn't understand anything you wrote.
> > 
> > Hope that explaination is sufficient.
> 
> Ok, thank you for the pointer. :-)
> I'll listen that through when I find a suitable time.
> 
> My first thought would of course be to define protocol extensions on
> case-by-case basis: mixer controls, playback controls, etc, and allow
> only one client to subscribe to an interface at a time, per seat.
> Anything outside of those would be server configuration for misc
> hotkeys. But I guess these were already raised in the talks, so I
> really better listen to those first.

Hi Piotr!

I have now watched the XDC video on the graphics stack security.

Everyone seems to assume, that there would be a generic interface
to register all kinds of global shortcuts, and no-one brought up
any different ideas. The semantic approach suggested was quite
near, though, but not really tailored to Wayland (how could it be,
yet).

I also realised, that there likely are lots of use cases for global
shortcuts that I cannot even imagine. That undermines my personal
proposal above, but I still stick to it.

Defining case by case protocol extensions is very close to the
semantic approach, if I understood right. I would divide keys into
functional categories, that you could subscribe to by simply
binding to a specific Wayland protocol interface, per seat. Two
examples of such interfaces would be the above mentioned mixer
controls, and playback controls. Each corresponds to a set of keys.

Such interfaces could be used by zero or one client at a time. If
an interface is already taken, the client just receives a "no,
cannot give you that". If an interface is bound, those keys are
never sent anywhere else. If it is not bound, you could send them
to the client in kbd focus, or not, whatever makes sense.

A catch-all misc global shortcuts mechanism would be the server
configuration, which is not exposed to normal clients at all. There
you could assign things like WWW-key for browser, since those
typically launch a new application anyway.

Note, that window management global shortcuts would not use either
of these mechanisms. Since the window manager is *in* the server,
it can hook into the key-combos directly.

The above idea is very simple, and I believe should avoid most
security concerns, but I also fear it is not enough for some use
cases I don't know about. I am knowingly ignoring any possibility
for a normal client to bind a global shotcut like "AltGr+a" on its
own will.

So, take this as just food for thought on what could be done. I
hope this could replace the "printable key combination" and other
complex heuristics with a much simpler scheme, since you do not
need a single generic interface for all ever imaginable shortcuts.


Thanks,
pq