GNOME Bugzilla – Bug 786146
Don't ask whether Keyboard settings can capture shortcuts
Last modified: 2017-08-22 10:25:01 UTC
In bug 783342, which was merged for 3.25.90, we would ask the user whether the Keyboard Settings panel was allowed to capture the keyboard shortcuts exclusively. Given that the Settings panel is part of the system, not a third-party application like a VM front-end, or a game, there's no point in adding a layers of trust just for it, and that the keyboard shortcuts panel is completely useless without the feature, I think that gnome-shell should whitelist this application.
(In reply to Bastien Nocera from comment #0) > I think that gnome-shell should whitelist this application. The tricky bit here is to whitelist applications without giving malicious actors a free pass by calling set_app_id() with an appropriate ID.
I think that users implicitly trust the OS, so asking for permission could be quite confusing - a lot of people won't understand why the question is even being asked. Not asking for permission would be better in this case.
(In reply to Allan Day from comment #2) > I think that users implicitly trust the OS, so asking for permission could > be quite confusing - a lot of people won't understand why the question is > even being asked. Not asking for permission would be better in this case. The problem is that "OS" is very vague in this context. Essentially any non-sandboxed process that has access to the display server can pretend to be gnome-control-center if we add a whitelist based on gnome-shell's app matching. That's really not acceptable, given how a saner security model is one of the selling points for wayland. So before we can talk about a whitelist, we need a way to identify system applications which isn't spoofable by random scripts users download from the net ...
This keeps coming up again and again: stuff running outside the sandbox is the system, we just happen to have an awful architecture which can't make the difference between system and really system. Who cares if a non-sandboxed app can spoof stuff. It's not sandboxed. Why would it bother capturing your keystrokes when it can grab your unlocked keyring and send all the passwords to a server in Belarus? The path, as far as I'm concerned, is the same as for location services: - expect unsandboxed applications to be trustworthy (which is really the implied case right now) - slowly but forcefully move apps to the sandbox The unsandboxed app can already run an "eval()" over D-Bus to remove that dialogue, so who are we trying to kid?
*** Bug 786574 has been marked as a duplicate of this bug. ***
(In reply to Bastien Nocera from comment #4) > The path, as far as I'm concerned, is the same as for location services: > - expect unsandboxed applications to be trustworthy (which is really the > implied case right now) > - slowly but forcefully move apps to the sandbox Should we then just give all non-sandboxed apps a free pass? That is, approve all requests from those apps without showing the dialog?
I think it could make sense with a white list for non-sandboxed apps. Not for security, but for user experience. If we'd silently allow keyboard inhibitation to anyone, we could easily end up with hidden application bugs hindering alt-tab and other short cuts because they unexpectedly inhibited them when they shouldn't have (as in how many gtk clients did until recently).
Created attachment 358114 [details] [review] inhibitShortcuts: Whitelist OS components Users already have to trust their OS, so asking whether an OS component should be allowed to perform an OS operation is odd at best, if not confusing. Account for this by allowing system components that require a keyboard grab to work - namely Setting's keyboard shortcuts panel - to do so without triggering the permissions dialog.
Review of attachment 358114 [details] [review]: +1 from me
Review of attachment 358114 [details] [review]: untested, but makes sense
Attachment 358114 [details] pushed as e8a2c06 - inhibitShortcuts: Whitelist OS components