Bug 171616 - System of applications autorisation in kwallet
Summary: System of applications autorisation in kwallet
Status: RESOLVED DUPLICATE of bug 432713
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kwallet (show other bugs)
Version: 4.1
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 171614 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-09-24 22:32 UTC by Kamil Neczaj
Modified: 2022-09-06 17:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kamil Neczaj 2008-09-24 22:32:51 UTC
Version:            (using KDE 4.1.1)
OS:                Linux
Installed from:    Unlisted Binary Package

There are applications in kde such as kopete, kmail, knetworkmanager, all of them require kwallet to be opened. Let's assume that the user uses only kde applications. He starts KDE, after a while Kopete or KNetworkManager wants to open kwallet. These applications are running through whole KDE session so the wallet is always opened. It's really unsecure now. Most of applications store their passwords in the default wallet. Prepared application which imitate one of applications installed can read all passwords from default wallet. 
Egzample: User has downloaded precompiled program. He run the egzecutable file. There is prepared binary "kopete" hidden somewere in it's directory. The main program egzecutes the prepared one after 30s. The message: "Do you permit 'kopete' to access 'default' wallet?" (or something similar) appears. The user involuntarily clicks 'Permit allways' and if only kwallet is opened all passwords from default wallet may be sent to the author of prepared program.
Such a prepared application (but not remote) already exists in kde. It's kwalletmanager ( bug 171608 )!!! This application shows the essential of security hole introduced by me. If only kwalletmanager have had function of remote control it would have been using to steal all passwords via internet.

Every application should have it's own wallet and have permissions only to this one. Autorization of applications should be also implemented. Every application's specific properity is the path and name of executable file so the autorization can be made by checking path to the application which want to get access to its wallet. All wallet's of the same user could be encrypted by one password (something like meta-wallet) so the user would be authorised only once (maybe by pam plugin - bug 92845 ).
Following KISS rule the wallets could be called according to scheme: "1001:/path/to/application/filename", where 1001 is user's UID and name of the meta-wallet.

For egzample if application "/usr/bin/kopete" run by user with 1001 UID tries get a password, kwallet give it access only to "1001:/usr/bin/kopete" wallet. It's really good solution. Even if someone prepare application to steal kopete password he must place it in the proper place which needs root access.

There is also another problem. KDE is installed in different places sometimes in /usr, sometimes in /opt. Sometimes distribution maintainers decide to move kde for egzample from /opt/kde to /usr. If this happen, all of wallets cannot be used so
there should be possibility to delete unused wallets by package manager. Renaming wallets shouldn't be implemented, because a wallet name is the key to autorisation. It's better to delete passwords than to create security hole.

I'm proposing to redesign kwallet to run it as system-wide deamon and use dbus to comunicate with client applications (provide them asked resources). Only this solution really increases security. There are many advantages of it:
1. KWallet cannot be killed by common user.
2. System of applications' autorisation may be implemented without problems with deleting unused wallets by package manager. Egzample: Removing kopete also delete kopete's wallets of all users. What is the aim of storing passwords which are not used?
3. Few MB less memory using when there are many users logged on the same system.
4. When new kwallet would be designed with cooperation with freedesktop.org there is huge chance that it would be approved by other desktop environments - gnome and xfce. All paswords would be as secure as in kde :D
Comment 1 Kamil Neczaj 2008-09-24 22:39:54 UTC
*** Bug 171614 has been marked as a duplicate of this bug. ***
Comment 2 Michael Leupold 2008-10-28 09:23:14 UTC
I agree with quite some of the things you mentioned:
Currently kwalletd is pretty insecure once it's opened. Also with most installations of dbus the communication between kwalletd and applications using it can be spyed upon (if eavesdropping is enabled for the session bus).

I don't see a solution in providing a system-wide kwalletd or having a per-application wallet though because even like that the problem of "authenticating" an application remains.

I've also come to the believe that dbus might not be the best way to provide an interface for managing sensitive data due to aforementioned problems with how it's currently deployed. There's also the problem that there's no guarantee if dbus is running using local sockets (in which case kwalletd is able to find out which PID is sending the request) or some other transport mechanism (like local TCP sockets in which case there's no way to find out who's requesting the password). A solution to this might be resorting to socket-only communication...

I do however value your concerns and I'm thinking of ways to implement this properly (and on as many operating systems as possible).
Comment 3 michaelk83 2022-09-06 17:31:05 UTC
Duplicate primarily of Bug 432713, and also of Bug 228308 (different aspects).
I've commented on those two bugs why this is problematic to implement.

*** This bug has been marked as a duplicate of bug 432713 ***