Re: Review Request 117157: Unlock session via DBus
On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote: Of course if an attacker is running code they'd probably just find it easier to open the .kwl directly and read the folder and key names, since apparently those are stored unencrypted, if the API docs are to be believed. Apparently is is changed with KSS and I frankly would have hoped that only hashes are stored for this test? Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Friday, April 04, 2014 10:08:36 PM Thomas Lübking wrote: On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote: Of course if an attacker is running code they'd probably just find it easier to open the .kwl directly and read the folder and key names, since apparently those are stored unencrypted, if the API docs are to be believed. Apparently is is changed with KSS and I frankly would have hoped that only hashes are stored for this test? Only hashes are stored for this test - see my answer next to this message. Cheers, Thomas -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: In fact the list of folders and keys present in KWallet (though not their values) can be queried without unlocking KWallet, or even causing it to prompt to unlock. AFAIK, all data access operations on KWallet require it to be opened first (KWallet::openWallet). That will surely trigger password prompt for legacy encrypted wallets. The GPG back-end wallets only trigger pin entry the first time, subsequent requests would simply open the wallet, as GPG private key is already unlocked. Could you please elaborate more on the possibility to enumerate the keys without opening the wallet? -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Fri, April 4, 2014 02:20:28 Valentin Rusu wrote: On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: In fact the list of folders and keys present in KWallet (though not their values) can be queried without unlocking KWallet, or even causing it to prompt to unlock. Could you please elaborate more on the possibility to enumerate the keys without opening the wallet? From the KWallet::Wallet API docs: bool Wallet::keyDoesNotExist(...): Determine if an entry in a folder does not exist in a wallet. This does not require decryption of the wallet. This is a handy optimization to avoid prompting the user if your data is certainly not in the wallet. Wallet::folderDoesNotExist() has similar verbiage. enumerating is overstating the case here since there's no direct support for enumerating folders or keys. But all the same, it's not hard at all to brute- force potential folder or key names using the same method used to guess valid Coinbase user identities that just hit the news. Of course if an attacker is running code they'd probably just find it easier to open the .kwl directly and read the folder and key names, since apparently those are stored unencrypted, if the API docs are to be believed. Note that there is a valid use case for this feature: It would be tremendously annoying for a user to have to open their wallet just so an application can verify if it does or does not have an entry stored in the wallet. Instead the application can defer opening the wallet (and forcing the password prompt0 until the value is actually needed. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54849 --- Please see different approach in https://git.reviewboard.kde.org/r/117324/ to use logind as an authority to unlock. - Martin Gräßlin 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
Re: Re: Review Request 117157: Unlock session via DBus
On Sunday 30 March 2014 18:06:52 Thiago Macieira wrote: 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. Personally I have to disagree. To me the graphical login is a an asset which needs to be protected in a stronger way. Access to a tty should not equal access to the graphical system. The fact that X is broken should not result in us adding further insecurities which need to be fixed up once we transit to Wayland. The opposite has to happen: all the small security issues we let in, because X was already broken need to get fixed. This thread turned into a nice TODO list :-) Our default should be to be secure and not to allow to be insecure because developers need to have an easy way to fix their setup. Btw. the greeter theme allows to be changed and the theme does not require authentication. It's up to the greeter theme to decide how to grant access. We even ship one theme for Plasma Active which does not provide any security. For use cases which require to allow quitting the locker through DBus this should be provided through the greeter theme, not through the lock process. If one wants to make the system less secure it should have to be explicitly changed and should require more privs. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
Em seg 31 mar 2014, às 08:55:05, Martin Gräßlin escreveu: Personally I have to disagree. To me the graphical login is a an asset which needs to be protected in a stronger way. Access to a tty should not equal access to the graphical system. The fact that X is broken should not result in us adding further insecurities which need to be fixed up once we transit to Wayland. The opposite has to happen: all the small security issues we let in, because X was already broken need to get fixed. This thread turned into a nice TODO list I'm not asking for it to be insecure. I've already authenticated by logging in to the virtual console. So let me unlock my session via D-Bus. -- 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 signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Sunday 30 March 2014 15:36:29 Thiago Macieira wrote: Em seg 31 mar 2014, às 00:01:13, Thomas Lübking escreveu: If they can gain access to a TTY login we are already screwed leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk They can already access all of the other applications and the user's files. Exactly. And that's why I agree with the people who argue in favor of unlocking the session via DBus. AFAIU the threat model which not providing this feature protects against is that some user locks his KDE session, but forgets to also lock some other local or remote session. IMHO this is a ridiculous threat model. There are so many possible attack vectors if an attacker has full access to the user's files that it doesn't really make any sense to try to protect some other session from the attacker. (In the past, I have already locked my KDE session, but left a TTY session unlocked. Doh! But I also had to kill the screen locker several times to re-gain access to my KDE session because for some reason the screen locker didn't let me unlock the session anymore. So, I've been in both situations and I definitely prefer to have the ability to unlock the KDE session via DBus.) Just my 2 cents. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote: However many distros disable gdb attach to running processes by default; you have to either be root or echo 1 somewhere in /proc (for which you also need to be root). /proc/sys/kernel/yama/ptrace_scope On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
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
Re: Review Request 117157: Unlock session via DBus
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? 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. Martin Gräßlin wrote: 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. Will be the first thing I look into on Monday. *cough* https://git.reviewboard.kde.org/r/117166/ un/locking depending on HW dongles (bluetooth, USB) is certainly a nice feature, but requires some sort of internal support (where you'd just configure the HW id to trigger this) Unlocking via a dbus command is imo very problematic. If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock 9*8+3? 75 Password? $ - 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 -
Re: Review Request 117157: Unlock session via DBus
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? 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. Martin Gräßlin wrote: 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. Thomas Lübking wrote: Will be the first thing I look into on Monday. *cough* https://git.reviewboard.kde.org/r/117166/ un/locking depending on HW dongles (bluetooth, USB) is certainly a nice feature, but requires some sort of internal support (where you'd just configure the HW id to trigger this) Unlocking via a dbus command is imo very problematic. If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock 9*8+3? 75 Password? $ When I was using pam_usb to unlock KDE with a USB drive I had to do two things to login/unlock: insert my USB and hit Enter. This suggests a way to go with HW dongles: we could expose a method “Hit enter” via DBus. Udev (or something else) will “hit enter” when the dongle is plugged and since unlocker goes through PAM, corresponding PAM module will do auth based on HW dongle. This way there can't be any security issues with the unlocker and user is responsible for configuring PAM correctly. - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014,
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 10:12:11, Thomas Lübking escreveu: On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote: However many distros disable gdb attach to running processes by default; you have to either be root or echo 1 somewhere in /proc (for which you also need to be root). /proc/sys/kernel/yama/ptrace_scope I'd never heard of Yama. It stands to reason that most distros do not have it, which in turn means most distros allow attaching. And I guess most developers will enable the tracing feature so they can attach and debug processes. On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Usually, root access and same-user access imply game-over. Which is why I think this feature should be allowed in. -- 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
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu: un/locking depending on HW dongles (bluetooth, USB) is certainly a nice feature, but requires some sort of internal support (where you'd just configure the HW id to trigger this) Unlocking via a dbus command is imo very problematic. I disagree. The user already authenticated via their password before they were able to send the D-Bus command in the first place. So why not allow them to unlock? If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock 9*8+3? 75 Password? $ Please don't invent authentication mechanisms. That's what we have PAM for. -- 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
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 19:14:32 CEST, Thiago Macieira wrote: /proc/sys/kernel/yama/ptrace_scope I'd never heard of Yama. https://www.kernel.org/doc/Documentation/security/Yama.txt Kinda new, but it's a stock kernel feature: http://kernelnewbies.org/Linux_3.4 On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Usually, root access and same-user access imply game-over. Which is why I think this feature should be allowed in. There's actually also prctl(PR_SET_DUMPABLE, ...) that can protect against debugging (more reliable than ptracing oneself and available since 2.3.20 ... ie. ever) - protection against same-uid is lately been taken more seriously and the share of gdb users should be rather low. Also Ubuntu apparently recently set ptrace_scope to one by default lately (apparently caused some help requests on ubuntuforums =) I know that Arch has it set since a couple of month. Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 19:26:21 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu: Unlocking via a dbus command is imo very problematic. I disagree. The user already authenticated via their password I should have been more precise in the first sentence: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] before they were able to send the D-Bus command in the first place. So why not allow them to unlock? Because we protect the session, not the shell. Occasional access will already be stopped by having to use gdb in the first place and even then it's possible to protect the process from manipulation by the same UID. If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock ... Please don't invent authentication mechanisms. I didn't even remotely try - this was still about the password enriched dbus unlock (and how to prevent the PW from ending up on the disk) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: I disagree. The user already authenticated via their password I should have been more precise in the first sentence: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? before they were able to send the D-Bus command in the first place. So why not allow them to unlock? Because we protect the session, not the shell. Occasional access will already be stopped by having to use gdb in the first place and even then it's possible to protect the process from manipulation by the same UID. I maintain that this is not a protection. Unlocking without a password remains possible, but you're making it difficult for those of us who tinker with KDE and sometimes misconfigure the authentication. In the past, I could kill a process when I had improperly installed KDE and the greeter couldn't authenticate via PAM. Now I have to kill ksmserver or cause the session to exit via D-Bus. All processes by the same user should be trusted. -- 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
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? One of the use-cases in the linked bug is to invoke this by pam_usb or some bluetooth script. If the dbus call would require a password, the script could end up looking like qdbus org.kde.kscreenlocker unlock 1ns3cur3 In the past, I could kill a process when I had improperly installed KDE and the greeter couldn't authenticate via PAM. Now I have to kill ksmserver or cause the session to exit via D-Bus. Actually the major reason (afaiu) behind moving the lock to ksmserver is to make crashing the locker process worthless. Iirc it happened after AllowClosedownGrabs was (accidentally) unconditionally turned on in Xorg (but that only qualifies as trigger and you'll have to ask Martin on direct motivations ;-) The development situation is special and actually what i had in mind when saying any way to circumvent authentication to this very session should be guarded by a special knowwhatido key [or require active authentication] I do certainly not think that the absolutely only way to open the lock should be the greeter GUI, but i do think that one should authenticate to the locker, what an open shell does not provide. Since you however implied that broken KDE ./. PAM might be a reason for a side entrance, that side entrace key must not rely on PAM. -- We could check the last login time of the user and compare that to either a) start time of the lock b) 3 minutes and accept an explicit dbus quit request if by this it's clear that the user has just authenticated to the system, implicating authentication to the locker. All processes by the same user should be trusted. Ever forgot an open VT1? Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 21:40:36, Thomas Lübking escreveu: On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? One of the use-cases in the linked bug is to invoke this by pam_usb or some bluetooth script. If the dbus call would require a password, the script could end up looking like qdbus org.kde.kscreenlocker unlock 1ns3cur3 Don't pass the password via D-Bus. The call should just be: qdbus org.kde.kscreenlocker unlock The development situation is special and actually what i had in mind when saying any way to circumvent authentication to this very session should be guarded by a special knowwhatido key [or require active authentication] I've already authenticated by logging in, even if in another terminal. Just unlock the session already. -- 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
Re: Review Request 117157: Unlock session via DBus
On Sat, March 29, 2014 15:25:59 Thiago Macieira wrote: Em sáb 29 mar 2014, às 12:25:48, Martin Gräßlin escreveu: 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. You can attach gdb to ksmserver and make it think that the authentication was successful for whichever password was typed. I'll note I've actually done this before, during the development process for the new QML-based screenlocker. The screenlocker at that time would often simply not show the UI for entering the password for whatever reason and leave me completely locked out of the desktop... talk about lame! ;) With that in mind I'd love to have a more official way to tear down the screenlocker from a separate same-user login. If you think being able to unlock a screenlocker is bad security, wait until you figure out that a same- user login can also copy your KWallet passwords out of your running kwalletd if you have it unlocked (something which can be queried over DBus as well). In fact the list of folders and keys present in KWallet (though not their values) can be queried without unlocking KWallet, or even causing it to prompt to unlock. And remember the threat model: Who are we locking the screen again? A physically-present adversary. If they can gain access to a TTY login we are already screwed, especially if they have enough skill to manually hack the qdbus command line invocations needed. Regards, - Michael Pyne
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 23:25:58 CEST, Michael Pyne wrote: I'll note I've actually done this before, during the development process for the new QML-based screenlocker. Me fixed the issue in the greeter code (while doing multiscreen/input handling), installed the greeter and SIGTERM'd the present one =) Neither is fun, of course. With that in mind I'd love to have a more official way to tear down the screenlocker from a separate same-user login. I don't think there's fundamental disagreement on this (esp. not in the developing context) - just on what challenge is required to this side entrance. Eg. i'd personally not object unlocking if there's a login (of yours) which is more recent than the lock and/or recent enough. wait until you figure [...] KWallet That issue is known (to me at least). In a non trustworthy environment i simply close kwallet before leaving the system unwatched because of this. (If I was more paranoid, i'd keep it on a usb key) However, I'm sure you don't want to justify security issues by other security issues :P If they can gain access to a TTY login we are already screwed leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk ;-) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
Em seg 31 mar 2014, às 00:01:13, Thomas Lübking escreveu: If they can gain access to a TTY login we are already screwed leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk They can already access all of the other applications and the user's files. They can attach gdb to any of the user processes. They can listen to all messages on D-Bus. They can attach to any IPC mechanism the user has access to. They can also launch new X applications. So they may not cause the session to unlock, but they can still launch a keylogger application that will take effect when the legitimate user returns and unlocks the screen. And, oh, the attacker can change the user's password! If it's a matter of unlocking the screen, they can use passwd to change the password, unlock the screen with the new password and then happily use the running session. -- 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
Re: Review Request 117157: Unlock session via DBus
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. 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. 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) 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. And, oh, the attacker can change the user's password! Errhemmm... Without providing the present one? /That/ trick you gotta show me. =) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
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
Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- 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 --- Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
--- 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. Changes --- How I tested it. 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 (updated) --- 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
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:02 p.m., Thomas Lübking wrote: what is the valid (read: not malicious) usecase for this? i'd rather say that if quitting the greeter to exit the lock w/o password, that should be fixed to *not* exit the lock w/o password provision. There are some usecases mentioned in the bug I referenced. I can add another one: imagine that you are hosting, say, a programming competition (like ACM ICPC). You've got a room of PCs, they are locked before the contest. When the contest starts you want to unlock them all simultaneously instead of having contestants enter passwords by hands. - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54536 --- 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
Re: Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- 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. - Martin Gräßlin 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
Re: Review Request 117157: Unlock session via DBus
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. You have to authenticate anyway to access the DBus session bus. - Kirill --- 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
Re: Review Request 117157: Unlock session via DBus
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. 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). - 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
Re: Review Request 117157: Unlock session via DBus
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) 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. - Kirill --- 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
Re: Review Request 117157: Unlock session via DBus
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. 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. - 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
Re: Review Request 117157: Unlock session via DBus
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. 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? - Kirill --- 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
Re: Review Request 117157: Unlock session via DBus
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
