> On March 29, 2014, 1: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? > > Thomas Lübking wrote: > > 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.
> you'll see a one-liner that unlocks the screen, right? this shouldn't be, and is clearly a bug. Will be the first thing I look into on Monday. > will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` > that triggers this behaviour? That doesn't increase security. If you want such a functionality it must go into logind IMHO. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 ----------------------------------------------------------- On March 29, 2014, 12:58 p.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, 12:58 p.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 > >
