attacks [LWN.net]

attacks

Posted Dec 19, 2011 22:59 UTC (Mon) by rqosa (subscriber, #24136)
In reply to: attacks by Cyberax
Parent article: Razor-qt 0.4 released

> For example, alecs1 had opened a bug about accelerators in KDE that I've mentioned: https://bugs.kde.org/show_bug.cgi?id=286375 with the expected RESOLVED:WONTFIX resolution.

Was his bug report really about the same issue that you had discussed here? I don't think so. It looks to me like what he was asking for in that Bugzilla entry (which was "more of a feature request" than a bug report, according to him) was for KDE4's SystemSettings to be able to display the global shortcuts registered by non-KDE4 applications (specifically Amarok 1.4, a KDE3 application). I doubt that KDE's shortcuts configuration applet has ever been able to show shortcuts for non-KDE apps (including apps for earlier versions of KDE than the version the shortcuts applet belongs to). Whereas, the way I understand it, the bug you reported here was that KDE4's Klipper registers Ctrl+Shift+Insert as a global shortcut, but that shortcut doesn't show up in the "Settings and Gestures" module in System Settings. So, what he reported in KDE's Bugzilla was completely different than what you reported here.

For what it's worth, I can't reproduce the bug as you described it on my KDE installation. You said that pressing Ctrl+Shift+Insert would "show the clipboard ring", but nothing popped up when I press that key combination. I tried it in a GTK3 application (Audacious), in a GTK2 application (gxine), in KDE4 Konqueror with WebKit, and on the desktop (i.e. with all windows minimized); in the GTK apps, it does nothing, whereas in Konqueror/WebKit it did nothing except for when typing in a textarea, in which case it appeared to treat it identically to Shift+Insert and performed a "paste".

(Log in to post comments)

attacks

Posted Dec 20, 2011 17:35 UTC (Tue) by alecs1 (guest, #46699) [Link]

Yes, the two things are a bit different, the bug I reported has a broader scope. Maybe a more specific bug would be useful and easier to get some fix implemented.

My request came from the more general concept is that there should always be an utterly powerful application that consistently handles control of keyboard and mouse, which I'l explain here since this is news about a DE:

1) Ctrl+Alt+Del (or another combination) should always be intercepted by a part of the DE and instantly acted upon (because maybe you want to kill that application that has taken control of your keyboard and now is thrashing the HDD and never replying, thus blocking everything). Alt+Tab should have almost as much power. Needles to say, this doesn't happen in KDE at least.

2) Dialogues requiring passwords should uniquely capture the focus at all times. I've seen the GTK implementation of these dialogues (PolicyKit I believe is called this authorization framework) telling me that it could not get total control over the keyboard focus. The KDE counterpart just crashed in the same situation. If not for the exaggerated intrusiveness, my experience with Windows Vista would have been delightful (those always got total focus, with messages I understood and even the transition animation worked). Compare this to: https://bugs.kde.org/show_bug.cgi?id=271147, which is just as bad a joke as the "lost+found" thing in the SystemSettings.

3) The DE should know where keyboard shortcuts go. If they go through a KDE3 daemon to Amarok through whatever library, then that daemon should be listed.

In my experience Linux looses badly when compared to Windows when managing misbehaving GUI applications, or taking control over input. In Windows I have Ctrl+Alt+Del for whatever full-screen and custom resolution app. missbehaves; in Linux I pray that it doesn't misbehave because it can: leave Xorg,KWin,Plasma panels in some sorts of corrupted states, because there's no Ctrl+Alt+Del instantly respected (but Ctrl+Alt+F1 seems to generally manager to bring me to a console). Fortunately, over the years at least Xorg and video drivers got their bugs fixed (I think KMS also helps), so at least Xorg doesn't crash that easily.

Alex

attacks

Posted Dec 20, 2011 17:45 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Peter Hutterer from Red Hat is fixing a entire class of such problems.

https://fedoraproject.org/wiki/Features/Grab_override

Will be in upstream Xorg and DE's can take advantage of this.

attacks

Posted Dec 20, 2011 18:59 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

it can be really annoying for a dialog window to grab the focus and not let it go when you want to do something other than respond to that dialog window.

using your example of something that asks for a password, what if you want to access your password safe to get that password?

attacks

Posted Dec 20, 2011 19:31 UTC (Tue) by alecs1 (guest, #46699) [Link]

I stand corrected, I didn't express myself very well and I only meant the root password and own password for sudo.

I'm not insisting that all password requests should acquire total focus, but those that try to implement such a thing should be consistent and stable. I didn't do an analysis of what needs passwords and what not, but I think all system configuration triggered by GUI and which requires additional privileges should do this grab. The password safe should implement some extra security itself too.

attacks

Posted Dec 20, 2011 19:39 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

The dialog doesn't need to be system-modal. It just needs to ensure exclusive access to the keyboard as long as it has the focus so that nothing else can observe your password.

Note that you're still vulnerable to impersonation attacks, since any other program can pretend to be the system dialog and capture your password that way. A reserved, unblockable shortcut key helps, but doesn't entirely eliminate the issue. To block this sort of attack you need some form of secure channel (like a dedicated LED) with which to indicate that the system dialog has successfully reserved the keyboard focus.

attacks

Posted Dec 20, 2011 20:15 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> The DE should know where keyboard shortcuts go. If they go through a KDE3 daemon to Amarok through whatever library, then that daemon should be listed.

But, even assuming it's possible for some applet to get a list of keyboard shortcuts for all currently-running X clients from the X server, then that applet wouldn't be able to change the shortcuts because it's up to each individual X client to determine its own shortcuts. The "Shortcuts and Gestures" module in System Settings is supposed to be able to (permanently) change the shortcuts, and there's no way to do that in general for all X clients, so it only deals with shortcuts belonging to KDE apps.

(Another potential problem with trying to display and/or change shortcuts for all X clients is that the client that receives the key event may not be the same as the application that acts on it — for example, (if I understand correctly) KDE 4 has a daemon called "kglobalaccel" for receiving global shortcut keypress events, because KDE 4 also supports Mac OS X and "for OSX you have to have an app running to catch events at the global level".)