Linux: gnome-keyring setup as Freedesktop SecretService

By | 02/26/2020
 

Currently, I’m using KeePass as passwords, RSA-keys, and as the Freedesktop SecretService, see the KeePass: an MFA TOTP codes, a browser’s passwords, SSH keys passwords storage configuration and Secret Service integration post.

The first issue I faced with during such a setup is the fact that KeePass’ database is synced between my computers (it’s database just stored in a Dropbox folder), and KeePass rewrites some passwords, for example – Chromium creates its own key named “Chromium Safe Storage” for its local SQLite database encryption, and it must be different on each PC, but as the database is synced – I got an issue here.

The second inconvenience is that KeePass is started with a locked database, and applications can not start using it until I’ll not unlock it.

This can be automated for example by using the -pw option (see KeePass options), or by using a GPG key, but in this way I’m losing the whole data encryption idea as all access credentials will be stored on the same filesystem in a plaintext.

Thus – let try to use gnome-keyring for local applications as a SecretService, and leave everything other for the KeePass.

GNOME Keyring install

Check the D-Bus org.freedesktop.secrets service now:

[simterm]

$ ps aux  |grep  $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets)
setevoy     1534  0.0  0.6 705436 102524 tty1    SLl  Jan09   0:03 keepassxc

[/simterm]

Disable SecretService support in the KeePass, install gnome-keyring:

[simterm]

$ sudo pacman -S gnome-keyring

[/simterm]

Check the SecretService again:

[simterm]

$ ps aux  |grep  $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets)
setevoy   829496  0.0  0.0 236292  8528 ?        SLl  13:19   0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

[/simterm]

Started, working, options – --start --foreground --components=secrets – correct, all good here.

GNOME Keyring unlock on Log In

Now, need to add storage decryption during login to the Operating system, see the Arch Wiki and GNOME Manual documentation.

Check libs:

[simterm]

$ ll /usr/lib/security/ | grep gnome
-rwxr-xr-x 1 root root  46768 Oct 29 11:38 pam_gnome_keyring.so

[/simterm]

Edit  /etc/pam.d/login, add to the auth and session the following strings:

...
auth       optional     pam_gnome_keyring.so
...
session    optional     pam_gnome_keyring.so auto_start
...

To update keyring’s password during changing a user’s password in the system – add the following line to the /etc/pam.d/passwd:

...
password  optional     pam_gnome_keyring.so

The documentation says it’s necessary to add the eval $(/usr/bin/gnome-keyring-daemon --start --components=secrets) execution to the ~/.xinitrc (or, for example,  ~/.config/openbox/environment), but in my case, everything is already working (Arch Linux + Openbox DE with manual X-server start via startx).

Reboot the PC and check D-Bus again:

[simterm]

$ ps aux  |grep  $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets)
setevoy     1338  0.0  0.0 236376  6932 ?        Sl   14:35   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

[/simterm]

gnome-keyring processes:

[simterm]

$ ps aux | grep gnome                             
setevoy     1351  0.1  0.0 236288  6776 ?        Sl   16:32   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 
setevoy     1874  0.0  0.0 235988  7244 ?        Sl   16:33   0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

[/simterm]

The Login and Default keyrings

After installation, we just checked the service and it looked like:

[simterm]

$ ps aux  |grep  $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets)
setevoy   829496  0.0  0.0 236292  8528 ?        SLl  13:19   0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

[/simterm]

But on my home laptop “something went wrong” and the gnome-keyring-daemon service was started with the --daemonize --login only, without --components=secrets:

[simterm]

$ ps aux  |grep  $(qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets)
setevoy      666  0.0  0.0 380756  7280 ?        Sl   21:19   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

[/simterm]

And in the Seahorse (see the Seahorse — GUI for gnome-keyring part below) I had an empty Login keyring, and Default – wich was even impossible to unlock:

Check keyrings files:

[simterm]

$ ll .local/share/keyrings/.
total 16
-rw------- 1 setevoy setevoy 2689 Dec  8 09:38 Default_keyring.keyring
-rw-r--r-- 1 setevoy setevoy   15 Dec  6 08:51 default

[/simterm]

Remove (moved to a Backups dir actually) the Default_keyring.keyring and default files, re-login – and it’s working now.

Seahorse – GUI for the gnome-keyring

Install the Seahorse:

[simterm]

$ sudo pacman -S seahorse

[/simterm]

Run a browser, for example, Brave, and check the Login keyring (must be created by the gnome-keyring after the first login to the system):

The Brave Safe Storage record appeared, thus – Brave is using gnome-keyring, SecretService works, all good.

Database files:

[simterm]

$ ll .local/share/keyrings/
total 8
-rw------- 1 setevoy setevoy 2480 Jan 10 14:38 login.keyring
-rw------- 1 setevoy setevoy  207 Jan 10 13:41 user.keystore

[/simterm]

No such secret collection at path: /

Sometimes during creating a new keyring Seahorse may return an error with the “No such secret collection at path: /” message:

The solution is to update environment variables for the D-Bus:

[simterm]

$ source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh

[/simterm]

Done.