Make it possible for KeePassXC to be used as the default secret service provider in distributions

[ArrayBolt3]

Summary

KeePassXC currently has functionality that allows it to act as a "secret service" for a user session. Applications that need to store small amounts of data securely can call the secret service provider in the current session, regardless of which provider that may be, and then store information in it. Usually this information is passwords or something along those lines.

While this is useful, currently it requires explicit configuration by the end user to enable this. If starting from scratch, a user must:

• Create a database and assign it a password
• Create a dedicated "group" within that database for storage of secrets
• Enable KeePassXC's Secret Service feature
• Select a database and a group within that database to use for secret storage
• Unlock the database any time an application attempts to save or load secrets from secret storage

While this is useful as it is, it makes KeePassXC an "aftermarket" secret service provider, as it requires much user configuration to set up.

As part of my work with the Kicksecure and Whonix projects, I investigated how practical it would be for a distro to automate most of these steps, and came up with something roughly along these lines:

• Ship a configuration file somewhere system-wide that enables KeePassXC's secret service support by default
• Every time a new user is created (either at installation time or when a person using the system chooses to create a new user account):
  • Create a new random key file
  • Create a password database encrypted with that key file
  • Inside that database, create a group
  • In the database itself, configure that group as the group to be used for secret storage
  • In the database itself, enable using that database for secret storage
• Ensure KeePassXC is configured to start automatically when the user logs in, pointing it at the appropriate password database and key file

There are three main issues with doing this using KeePassXC's current implementation:

• As far as I can tell, keepassxc-cli does not support the advanced database modifications needed to enable secret storage for a dataabase. One can change the contents of the database, and authentication info on the database, and that's about it. Other settings are not exposed. This makes any automated creation of databases for secret storage impossible.
• Without explicit support for initializing a "default" secret storage database like this, creating a new secret storage database at user creation time requires installing hooks of some sort into the user creation process. Under Debian and its derivatives this can be done in a rather hacky manner by shipping a /usr/local/sbin/adduser.local file (which breaks Debian packaging policy since no package is ever supposed to ship files under /usr/local), on other distros I'm not sure if it's possible at all.
• Even with the use of a key file, this is insecure. Ideally a user should have to choose a password for the secret database the first time it is used, or KeePassXC should somehow obtain the user password from the login manager and automatically use that as the password. (KWallet does both of these things depending on the situation, and while the implementation isn't ideal in my opinion, it's still decent.)

My suggestion is to add an --agent or similar argument to KeePassXC's command line interface. This would inform KeePassXC that it is being used as the default secret service for this user account. This would trigger it to enable the secret service feature, automatically create a properly secured secret storage database if necessary, and then stay running so that it can provide secret management features (and also work as a password manager if the user desires). If the user configured a group in some other database as the group to use for secret storage, KeePassXC would respect that feature, but if the user had no secret storage database configured, it would automatically fall back to the default one created on first user login.

Examples

If implemented, distros could make KeePassXC act as the default secret service provider by simply shipping a .desktop file under $XDG_CONFIG_DIRS/autostart/ that would launch KeePassXC with the --agent option. KeePassXC would then automatically prompt the user for a master password for secret protection (or obtain the user password from the login manager), create the secret storage database, etc. This would allow KeePassXC to act as a total replacement for existing secret service implementations like KWallet or gnome-keyring. Kicksecure is one distro that is interested in this sort of functionality.

Context

Kicksecure ships KeePassXC by default, but currently is having to use gnome-keyring as the default secret service because we weren't able to make KeePassXC act as the default secret service provider without resorting to very hacky solutions that would be potentially insecure. See https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/2.

[michaelk83]

• Create a new random key file
• Create a password database encrypted with that key file
• Inside that database, create a group
• In the database itself, configure that group as the group to be used for secret storage
• In the database itself, enable using that database for secret storage
• Ensure KeePassXC is configured to start automatically when the user logs in, pointing it at the appropriate password database and key file

Other than the settings, this can be automated with an external script via keepassxc-cli. As of #11321 (next release), it will be possible to manually export/import (some?) settings. Perhaps a function can be added to keepassxc-cli to export/import settings, or create a DB with settings taken from a file. But that should be a separate issue.

Barring that, you can provide an empty pre-configured database for Secret Service, and instruct the user to change its credentials as they like (link to the user guide). If some of the relevant settings are application settings (not per-database), I think those are stored in a separate .ini file?

For the actual registration as default Secret Service provider, see #6274. It actually doesn't need auto-start at login, just need to register for DBus auto-start. That can be handled by the same setup script, but it's up to the distro to make sure that Gnome Keyring doesn't get in the way (or preferably is not installed).

Probably the user will still need to unlock the database when needed. This can be made a little easier with QuickUnlock, but that still needs some more work on Linux. At the least, you'd need to install a PolKit file to make it work. That can be done by the same setup script.

Ideally a user should have to choose a password for the secret database the first time it is used, or KeePassXC should somehow obtain the user password from the login manager and automatically use that as the password.

If this setup is triggered by user action (which is perhaps the better approach), the script can prompt the user for credentials. For login manager integration, see the discussion in #6055. It would be convenient, but not ideal from a security standpoint.

[droidmonkey]

This is extremely far outside our scope. If distros want to place keepassxc as an optional secret service provider, then they need to make it much easier to disable the current one. GNOME is the worst. It is almost impossible to disable gnome keyring.

All this said, we are not going to implement a scheme to auto create databases for use with secret service. It's a somewhat niche feature already that is a couple of clicks to setup in keepassxc. We need documentation for it, if anything.

This feature was never meant to be an OS default setting, nor should it be the default. We just want it to be easier to switch to keepassxc if the user wants to.