Review Request 117157: Unlock session via DBus

[Thomas Lübking]

> On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote:
> > I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication.
> 
> Kirill Elagin wrote:
>     You have to authenticate anyway to access the DBus session bus.
> 
> Martin Gräßlin wrote:
>     and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately).
> 
> Thomas Lübking wrote:
>     you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking)
>     
>     this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special "knowwhatido" key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself)
> 
> Kirill Elagin wrote:
>     If you've installed your evil software you already have a thousand of ways of accessing the system.
>     My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter.
> 
> Martin Gräßlin wrote:
>     no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed.
> 
> Kirill Elagin wrote:
>     It seems to me that it's not secure actually. If you have a look at the bug I mentioned, you'll see a one-liner that unlocks the screen, right?
>     Unfortunately I'm not really familiar with KDE internals, but I don't see any way to avoid this. (I should point out that, still, I don't see this as a security issue;
>     once an $evilagent got your shell, you already lost, because now he can _modify memory_ of any of your processes, including ksmserver.)
>     
>     But if you still don't agree… well, will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour?

> It seems to me that it's not secure actually.
As pointed out in the very first comment, i consider this a serious bug and security issue - yes.

FTR:
There's a difference between the ability to poke memory on the one hand and have a nice GUI access to your money accounts, an open ssl session or root shell of a running system.

Accessing random shells/client conections of the current session is the pot. privilegue escalation here, open to an attacker how could eg. not manipulate the software stack.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117157/#review54538
-----------------------------------------------------------


On March 29, 2014, 11:58 a.m., Kirill Elagin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117157/
> -----------------------------------------------------------
> 
> (Updated March 29, 2014, 11:58 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Bugs: 314989
>     http://bugs.kde.org/show_bug.cgi?id=314989
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> -------
> 
> Unlock session via DBus
> 
> Make org.freedesktop.ScreenSaver.SetActive(false) unlock session.
> 
> 
> Diffs
> -----
> 
>   plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b 
>   plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d 
>   plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 
> 
> Diff: https://git.reviewboard.kde.org/r/117157/diff/
> 
> 
> Testing
> -------
> 
> I've tested this with KDE 4.11.5 which I'm currently running.
> Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master.
> 
> 
> Thanks,
> 
> Kirill Elagin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140329/4de5658f/attachment.htm>