[Bug 171616] New: System of applications autorisation in kwallet

Kamil Neczaj kneczaj at gmail.com
Wed Sep 24 21:32:54 BST 2008


http://bugs.kde.org/show_bug.cgi?id=171616

           Summary: System of applications autorisation in kwallet
           Product: kdelibs
           Version: 4.1
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: kwallet
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: kneczaj at gmail.com


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


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Unassigned-bugs mailing list