| Summary: | Changes to KDE Wallet configuration does not require password | ||
|---|---|---|---|
| Product: | [Applications] kwalletmanager | Reporter: | Richard Hartmann <richih-kde> |
| Component: | general | Assignee: | Valentin Rusu <valir> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bartotten, chalkerx, faure, korossy, kumaran, lemma, mitchell, MurzNN, security, valir |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kwallet/717f925b77f13c54e92ecd81ea92487f933a1915 | Version Fixed In: | 4.12 |
| Sentry Crash Report: | |||
|
Description
Richard Hartmann
2010-04-02 20:34:04 UTC
I would like to ask if somebody can please update this to be a severe bug instead of a lower priority item. Security issues can seriously compromise the usage of kwallet. Good point; I can raise it. I will need to figure out what severity is applicable as https://bugs.kde.org/page.cgi?id=fields.html#bug_severity does not list security-related classification. CC'ing security@kde.org as per wstephenson's suggestion. (In reply to comment #0) > the victim to leave his/her pc. Changes to these security-relevant settings > should require the wallet's password. The problem is that these are wallet *manager* settings. The manager can be managing multiple wallets -- so if you change the settings, which wallet's password do you ask for? Most likely this should instead require the currently-logged-in-user's password. I've marked this as critical, and CCed the currently-listed maintainer. Michael, can you work on this? In order to make the settings more secure the following needs to be done: - store settings for closing the wallet inside the kwl file - store acl settings inside the kwl file I'm not really sure if I can work on it. Unfortunately my KDE time is currently pretty limited so I have to choose carefully what I want to work on in order to get anything finished. I'm currently spending most of my time on replacing kwallet with something that supports the fd.o spec, has more flexibility and fixes many of the security concerns. I don't think preventing attacks as raised in this bug, #171608 or #208371 was one of the goals of the original kwallet. That's why plumbing a fix for those bugs is often more work than it might initially seem. Michael, Since right now settings are global, not per-wallet (unless the wallet manager tray icon is showing settings for the default wallet as opposed to all wallets) a "quick fix" would be to require the current user's password to change these settings, similar to how some of the systemsettings modules work. Is this something that would be doable? I agree with your assessment of the problems/threats, but it does seem in this case like there may be a quick fix, unless I am mistaking something. I agree. Having to provide the user password would be better than nothing. I think that for any kwalletmanager settings, asking for the user's password is a reasonable quick fix. Please keep in mind that root can simply change the password, but at least the intrusion would then be detectable. It would not, as root can easily change /etc/shadow and reset atime, as well. As per https://bugs.kde.org/show_bug.cgi?id=171608 , local root will always trump kwallet, no matter what we do. LDAP or Kerberos authentication would be more difficult to circumvent, since those might be under the control of a different administrator. However, authconfig can be changed so root would still have access through local authentication. Ultimately, it comes down to how many steps we require root to take before the wallet is compromised. This is a good point. The magic words here would probably be "criminal intent" and "raising of the bar". And now what? *bump* I believe we are now waiting for someone with the time, knowledge, and initiative to fix it. I guess this requires code that uses kcheckpass, similar to krunner/lock/lockprocess.cc Mm. One possible solution: 1) Store the critical settings (for example, «keep open» flag) per-wallet, in the wallet file. Not one global setting, as it is now. 2) Sign the wallet file (if not done already), using the password. 3) Do now allow to open incorrectly signed wallets with kwallet. So changing that setting would require opening the wallet. This method would depend on kwalletmanager not being modified by the attacker (because of #3), but if someone could modify kwalletmanager (for example, local root), he can also just store everything the user types in the password prompt. Local root can even just log all the keypresses, nothing could be done here. Actually, IMHO, all the settings, except default wallet and gui settings, should be stored per-wallet, and should be signed. Most important are «access control» and the «keep open / when to close» blocks. Access control not being signed is also a security issue. Am i right that as it is now, any application could change the access control settings (add itself to [Auto Allow] in ~/.kde4/share/config/kwalletrc)? I don't know for sure, but I think many of these issues might be moot with the introduction of KSecretService in 4.8. > I don't know for sure, but I think many of these issues might be moot with the introduction of KSecretService in 4.8.
1) Does this mean that kwallet would be deprecated soon, and excluded from KDE SC? If yes — good, if no — kwallet still should be fixed.
2) Does this mean that ksecrets manages this in a right way?
Still no info about this? Kde 4.8 was released long ago, kde 4.9 was also released. Still i didn't see KSecretService in action, tbh. And kwallet is still not fixed. It appears that nobody has had the time and/or desire to to so. It's an open-source project...if this is your itch to scratch, feel free to get involved... What is current status of KSecretService development? Did we have any news? Any chance that KSecretService will be added to KDE 4.11 Feature Plan? @Murz: KSecretService will eventually be a KF5-based release feature. However, I think that kwallet is a good point to start and I'll continue to better it, so that KDE4 users continue to benefit it. Taking over the list of kwallet issue I see two kinds of users : - some do not want to re-enter passwords when applications are accessing wallets, - some others request that kwallet systematically enter password when applications open wallets. These two requirements are opposite. Leaving the wallet open for the entire session - to satisfy first user category - will make the other say that the wallet is not secure enough. There are other cases where leaving your computer unattended may lead to abuse. Do you guys are using ssh-agent to store ssh remote keys? That would allow attackers access remote computers on your behalf. I think that the wallet system needs PAM integration and when doing sensible changes, the current user password should be prompted. And event in that case, some users may to have the option to disable that, to prevent too many password prompts. Git commit 717f925b77f13c54e92ecd81ea92487f933a1915 by Valentin Rusu. Committed on 09/09/2013 at 14:17. Pushed by vrusu into branch 'master'. Require user's password when changing configuration The KCM now uses KAuth in order to get user's password when attempting configuration changes. M +10 -0 src/konfigurator/CMakeLists.txt M +27 -0 src/konfigurator/konfigurator.cpp A +9 -0 src/konfigurator/kwallet.actions A +15 -0 src/konfigurator/savehelper.cpp [License: UNKNOWN] * A +15 -0 src/konfigurator/savehelper.h [License: UNKNOWN] * The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. http://commits.kde.org/kwallet/717f925b77f13c54e92ecd81ea92487f933a1915 *** This bug has been confirmed by popular vote. *** |