Implications of disabling KWallet when using full disk encryption

Summary:

Does disabling the KWallet service whilst using full disk encryption reduce the security of the system?

Full:

Hello everyone,

I am using LUKS to secure my OS drive, I have enabled auto login to avoid having to enter my password twice after boot.

When opening certain applications, I am prompted to enter my password to decrypt the KWallet keystore. I have noticed that these applications function correctly whether I enter my password or avoid doing so by attempting to close the prompt a few times.

To avoid this prompt, I would like to disable the KWallet service, however I am not aware of the implications of doing so, my understanding is that since the drive is already encrypted, encrypting the keystore is redundant and does not improve security.

To the best of my knowledge, KWallet does not provide any security beyond encrypting the keystore, as soon as the keystore is decrypted any application can query it for any credentials; there does not appear to be any access control that restricts access based on application or user.

Is my understanding correct, or is there any merit to leaving KWallet enabled, perhaps for the sake of compatibility for certain applications?

Hello everyone,

In case anyone stumbles on to this post in the future, I have disabled the KWallet subsystem and have yet to run into any issues on my system, I will update this comment if any problems arise.

Thanks for the comments on your experience!

I’ve actually been experimenting using keepassxc as the secret provider, and it’s been a bit annoyingly broken as it’s causing applications to hang for like a good 30-60 seconds on each start as things seem somewhat hardcoded in kde since 6.5 to force them toward kwalletd6 or ksecretd. I was able to fix some by forcing them to use gnome-libsecret in ~/.config/*-flags.conf file, but it’s not working for everything, and particularly electron apps seem bugged by this on start, but then work normally after.

Hopefully this fleshes out that kde handles this better for 3rd party secret providers in the future, I know there’s work on this. The implementation changed entirely from using gnome-keyring in 6.4 still to removing that for 6.5, which was surprising as I’d just upgraded and researched doing this while still on 6.4, so I had to change up my approach to trying to kill ksecretd for keepassxc instead taking over the socket, which still doesn’t exactly work for me trying to use systemd user scripts to override it.

I’d be interested to know what you’re doing instead there, as sounds like probably we have something in common. I hadn’t hard disabled the kwallet system as I wasn’t sure how bad it would break kde, but I have since reading this with a bit more confidence now, so again thanks for that.

Hello Mikus,

Thank you for detailing your experience, I haven’t experienced any applications hanging after disabling the KWallet subsystem, however I believe I have run into some of the other side effects of hardcoding KWallet, namely Dolphin File Manager prompts me for credentials every time I open it to be able to access network shares and Unity Hub (Unofficial, Flatpak) appears to sign me out every time it is closed (although this could be default behaviour since it is an unofficial application and I have not tested it before disabling KWallet).

I cannot comment on the effects of disabling the sockets manually, as I disabled the KWallet subsystem via the settings menu (System Settings > KDE Wallet > Enable the KDE wallet subsystem); it could be possible that our different approaches have different results.

Furthermore, most of my applications are installed via Flatpak, I am not sure if you have adopted the same approach but if you haven’t, there is a chance that natively packaged applications are more susceptible to problems from disabling KWallet. I suspect this is the case as Dolphin is one of the only application that is giving me issues and is natively installed, which leads me to believe Flatpaks have some sort of fallback for storing application secrets which perhaps must be enabled explicitly or with knowledge of the underlying code (Unity Hub is proprietary software) since Unity Hub is the only Flatpak causing issues, all others including electron applications work fine.