mgraesslin at kde.org
Mon Dec 15 08:09:00 GMT 2014
On Sunday 14 December 2014 15:33:27 Thomas Lübking wrote:
> On Sonntag, 14. Dezember 2014 13:52:51 CEST, Jeremy Whiting wrote:
> > Martin, Thomas,
> > Is the implementation of InputGuard at
> > https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1
> > dc1986f with
> > https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be8f
> > 2e8034a complete then?
> "complete"? - Yes.
> "Thomas happy"? - No :-(
> The class grabs the keyboard for the (managed) focused widget in active
> windows (as it should), BUT the only "protection" against malicious losses
> is to regrab the keyboard every 500ms (and make the lineedit white on red
> if that fails)
> Martin suggested to declare X11 setups which allow to break grabbing
> "unsupported", but I'm not entirely happy with that.
> We'd need to figure whether
> a) there's a way for a client to check whether it still holds the grab
> b) or alternatively adding a second client (ie. process) to guard the first
> one otherwise (by trying to grab the keyboard and when that works while
> client #1 is supposed to have the keyboard, sth.'s fishy here)
b) wouldn't work in a case of attack using the "allow break grabbing feature"
1. dialog grabs keyboard
2. attacking process breaks grab and establish grabs
3. control process tries to grab keyboard and will fail as the attacking
process holds a grab.
> > should we copy that into kwidgetsaddons
> I assume kwidgetsaddons should use the KDE palette definitions ("bad"
> color?) - if color indication is sufficient. But that's subject for a
> kwidgetsaddons review.
Yeah, we should get Thomas Pfeiffer on a review as he's an expert on useable
security. Personally I also think that this needs some explanation on why it
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel