Review Request 117157: Unlock session via DBus

[Thiago Macieira]

Em seg 31 mar 2014, às 01:43:22, Thomas Lübking escreveu:
> On Montag, 31. März 2014 00:36:29 CEST, Thiago Macieira wrote:
> > They can already access all of the other applications
> 
> depends on whether they actively suppress such.
> 
> > and the user's files.
> 
> true.
> 
> > They can attach gdb to any of the user processes.
> 
> "depends on whether they actively suppress such."

We've already established that the default is allowing ptracing.

> > They can listen to all messages on D-Bus.
> > They can attach to any IPC mechanism the user has access
> > to.
> 
> True.
> Question is whether applications expose secrets or access to other
> shells/services via dbus. Ie. can you highjack an open ssl connection,
> control banking software etc.

Yes, given the use of kioslaves, it's very easy to make extra requests via KIO 
and get the banking details. KWallet passwords and cookies are transferred 
over D-Bus, not to mention that the wallet and the cookie jar will be open and 
ready for requests.

> > They can also launch [...] a keylogger
> 
> True and if you enter a password into anything that does not grab the
> keyboard, this is a general issue of X11 (and if you've physical access to
> the machine, that doesn't matter either, because you can add a
> cronjob/service to track the device nodes)

Agreed. But we won't get that fixed until Wayland. Neither KWallet nor the KDE 
password dialogs (including those from the polkit agent) nor website passwords 
grab the keyboard. In fact, the only tool I know that does that is pinentry 
(gpg-agent).

> Leaving access to an open shell is certainly bad enough - beyond question.
> The question is whether gaining direct access to a running session and
> random open clients (and leaving the stage untraced) is more valuable and
> thus worth pretection.

We're assuming that the attacker already gained access to the session at this 
point. For example, if you've left a logged in shell in a virtual console. At 
that point, it's already game over.

Since that is so, let's stop trying to cover the sun with a sieve. Instead, 
let's make the life of developers and helpgivers easier: let there be an 
unlock command via D-Bus, without transiting the password again.

> > And, oh, the attacker can change the user's password!
> 
> Errhemmm... Without providing the present one?
> /That/ trick you gotta show me. =)

Right, it does ask for the current password.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358