It’s a really long-read post and I wast sure if it’s better to split it into three parts or put them together. On the one side, there are keyrings, from another – D-Bus, and finally, there is a Secret Service.
Eventually, I decided to keep them here together as I googled all it in the same scope and the are related to each other.
So, in this post we will speak about the next:
- what is the keyring at all
- what is the difference between the Linux keyring and GNOME keyring, and do they relate to each other
- what keyring implementations are
- what is the
org.freedesktopSecret Service and how it relates to the GNOME keyring
- what is D-Bus, and how we can use it to see how a keyring service is working
- and a couple of examples with Linux Keyring, GNOME Keyring, KWallet, and KeePass as a keyring backend
This post is absolutely not kind of “tutorial” with “HowTo Configure it” but instead – just an overview of the components mentioned above to try to understand what they are and how they can be used.
- Linux: the Nextcloud client, qtkeychain and the “The name org.freedesktop.secrets was not provided by any .service files” error
- Linux: gnome-keyring setup as Freedesktop SecretService
- KeePass: an MFA TOTP codes, a browser’s passwords, SSH keys passwords storage configuration and Secret Service integration
- Chromium: Linux, keyrings && Secret Service, passwords encryption and store
- KeePass: SSH keys password storage and decryption on Linux
This post was written by a long-long googling, so here will be a lot of links to documents and other materials that were used.
I may confuse something or even understood in a wrong way, so please welcome to the comments, if you’ll see any errors.
The post’s writing process was like this:
What is the Keyring?
To start what the “keyring” word means at all?
Let’s start with Wikipedia – https://en.wikipedia.org/wiki/Keyring_(cryptography):
In cryptography, a keyring stores known encryption keys (and, in some cases, passwords).
Then, let’s proceed with the GNOME project documentation – https://help.gnome.org/users/seahorse/stable/keyring.html.en:
Much like a keyring in real life allows you to keep certain sets of keys together, a keyring in Passwords and Keys allows you to keep passwords and keys in separate groups.
And even let’s take a look at the MySQL documentation – https://dev.mysql.com/doc/refman/5.7/en/keyring-service.html:
a keyring service that enables internal server components and plugins to securely store sensitive information for later retrieval
Finally, take a look at the keyrings(7) man-page – http://man7.org/linux/man-pages/man7/keyrings.7.html:
The Linux key-management facility is primarily a way for various kernel components to retain or cache security data, authentication keys, encryption keys, and other data in the kernel.
So, the keyring concept – it is some mechanism, or facility, or a concrete application, intended to store some confidential data.
Good, let’s go deeper.
Linux keyring vs gnome-keyring
Useful links used:
- KERNEL KEY RETENTION SERVICE
Now, let’s speak about the difference between the Linux kernel keyring and the GNOME Keyring: at first, I was confused as I suggested that GNOME Keyring somehow uses kernel’s keyrings facility, but now – it’s just different things.
Let’s go back to the man 7 Linux keyrings:
keyrings – in-kernel key management and retention facility
I.e. Linux keyrings – it’s is kernel’s mechanism providing the ability to store secret information.
Now, let’s read the
GNOME Keyring is a collection of components in GNOME that store secrets, passwords, keys, certificates and make them available to applications.
So, GNOME Keyring – is a collection of utilities (
gnome-keyring-daemon, libraries, the
seahorse package, etc) to store confidential data. See also GNOME Keyring architecture.
Let’s summarize the key differences between Linux keyrings and GNOME Keyring:
- Linux kernel – is a kernel’s facility for “passwords caching” – it stores them in a computer’s memory during an active user’s/system session
gnome-keyring– is persistent storage with keeping data on a hard disk
- Linux keyring – store in RAM, thus passwords are available only during a session, there is no need to store them always
gnome-keyring– creates a file on a disk, usually, in the
- Linux keyring – via syscalls from the user space into the kernel space
gnome-keyring– via DBus
- applications to access:
- gsheet-keyring – a backend that stores secrets in a Google Sheet. For use with ipython-secrets.
- bitwarden-keyring – a backend that stores secrets in the BitWarden password manager.
And this list is not full.
Also, there a bunch of client applications to be used with those keyrings, again the list is not full:
Passwords interception from the
During googling, found an interesting bug discussion here – https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365
- a client and a service communicates via D-Bus
- a client ask for some data from the Secret Service (
gnome-keyringin this case)
- the service via D-Bus send a confidential data
- another, “bad”, process listens dbus-messages and intercepts a password
What is the Secret Service?
Another one concept I had to google about: what is the “Secret Service”? How it relates to the GNOME Keyring and to the KWallet?
What is it doing in the Linux and how can I touch it?
Well, let’s go to the documentation again – https://specifications.freedesktop.org/secret-service/latest/ch01.html:
The Secret Service API allows client applications to store secrets securely in a service running in the user’s login session.
Aha, i.e. Secret Service – it’s not some particular service or an application, but it’s a specification, kind of an RFC created by the GNOME and KDE projects to determine how this API must be realized for a client which wants to use GNOME Keyring or KWallet to store their secrets.
Also, the Secret Service API supported not only by the GNOME Keyring and KWallet but also for example by the KeePass and other applications.
IMHO, a bit confusing is the Secret Service name itself – “a hidden service”. If it would be called Secrets Service, i.e. “service of a secrets data” – it would be much more clear.
The Secret Service glossary
In short terms:
- secret: a password itself, or any other secret data
- item: each such a secret plus its set of attributes makes up an item
- collection: a set of such items makes a collection (similar to the keyring or wallet concepts)
- collections and items represented by D-Bus objects, each with its unique path
- default collection: client applications without special conditions have to save items to the default collection which has to be accessible via the
Not its time to try to recall with is the D-Bus so often mentioned in the previous parts, and how to deal with it.
So, the D-Bus on of the Linux kernel IPC – Inter-Process Communication – mechanisms, allowing for separate processes inside of an operating system to communicate with each other.
- documentation – https://techbase.kde.org/Development/Tutorials/D-Bus/Introduction
- one more doc: https://dbus.freedesktop.org/doc/dbus-tutorial.html
- about D-Bus transports: https://dbus.freedesktop.org/doc/dbus-specification.html#transports
- D-Bus, quick recap
- Universal standard mapping between D-Bus and URI namespaces
- D-Bus Addresses — D-Bus connection endpoints
And in short about main concepts and terms in D-Bus:
- D-Bus in general: it’s a “bus” for IPC, i.e. if in the previous SSH examples (see the SSH: RSA keys, and ssh-agent for SSH keys and their passwords management post) a UNIX socket was used, this time we are using the bus mechanism, see the https://www.kernel.org/doc/html/latest/driver-api/driver-model/bus.html. In its turn, those buses can be
- a session bus
- a system bus
- private buses
- messages: a base communication unit, data transfer similar to the TCP/IP, just in the D-Bus all data of a message is included to the message and not split over TCP-packets
- when a message is sent usually it leads to some method to be called to execute some actions by an application providing this method
- a message can be sent by an application to itself
- namespaces and addresses:
- as various applications can be placed on the same bus (or “listen to the same bus”) and during that the same application can provide various objects which can accept messages, then need to have some way to address those messages. In D-Bus, such an address consists of an interface name + service + an object name
- a namespace example – org.freedesktop.dbus
- an address example – unix:tmpdir=/tmp/my-app-name
- interface: a set of methods and signals on a particular bus f a particular object. You can think of interfaces as named methods and signals group.
- most of the interfaces will lead to the concrete construction of a language used for an application, for example, it can be a Java interface or a virtual class in С++
- an interface example – org.freedesktop.Introspectable
- service: represents a concrete connection of a particular application to a bus
- under the service here means a bus name (in the origin – “well-known” Bus names), but keep in mind that the “bus name” here implies a particular connection name but not the bus name
- if an application has more then one connection to a bus, or if the application is running in multitype instances – expanded by a PID number, for example, to make it unique
- a service example – org.kde.screensaver
- objects: the same application can provide access to its multiple objects using paths to separate those objects. Each such a path associated with a service represents a dedicated object, for example
/Documents/Doc1. Objects allow access to interfaces and the same object can provide such access to multiple interfaces at the same time
- methods: each object has members of the two types – methods and signals
- methods – ate messages sent to an object to trigger some action in an application, who created this object
- methods can pass data to an application’s input and can return an output with some values from the application
- methods always have a sender and receiver addresses
- are similar to the methods, but are not tied to any specific destination and can be accepted by any application on the same bus
- are generated by an application which exported an interface
qdbus– watch and send messages via D-Bus
dbus-monitor– view a bus activity
dbus-send– send messages via D-Bus
qdbusviewer– view objects and messages, is a part of the
d-feet– D-Bus debugger
bustle– D-Bus message analyzer and profiler
d-feet, install it:
And a few examples of how those backends can be used from a Python or CLI utilities.
As already mentioned, the Linux keyring is a kind of “caching service” in the kernel.
You can use the
keyctl utility from the
To read about:
And from the documentation:
Each process subscribes to three keyrings: a thread-specific keyring, a process-specific keyring, and a session-specific keyring.
Let’s see which keyrings are available for my current session:
Or for my user:
Also, in the
/proc/key-users you can get information about all keyrings and their statistics by each user:
And keys available for reading by our process (the
bash which called the
A user’s keyrings in the current session:
Keys in the current keyring:
Add a key:
Got its ID and now can read its content using this ID:
keyctl utility just executes the
keyctl(2) system call:
In the first call here –
keyctl(KEYCTL_READ, 546850615, NULL, 0) = 12 – we performed the
keyctl() syscall with passing the
KEYCTL_READ operation and a key ID.
Okay – more or less clear here.
Materials used here:
Let’s go to the keyring storages.
Really problematic package, as for me, but still it is most widely used.
Install if not present yet:
Check D-Bus services – look for the
“Aha, here we are” (c)
Now we can get the service description by using the
Or with the
qdbus, fid the service first:
And get the full service’s description:
Actually, I want to see who is listening on the another side of the bus. Let’s use the
GetConnectionUnixProcessID method for this:
Here we did:
- a call to the org.freedesktop.DBus service
- passing the / path
- called the
- and passing the service org.freedesktop.secrets name to the method to get its PID
Check what is the 1278791 PID:
So, now we are knowing that the Secret Service role is played by the
gnome-keyring application. Let’s try to add and remove some data using the
Start with the
In case of errors like (can happen on the first run after installation on Arch Linux, for example):
You need to execute the
And create a new keyring and set a password for it:
Let’s check the
dbus-monitor, to see what’s is going on in the D-Bus:
- sender=:1.576 – find the 1.576 in the D-Bus services list – it’s our Python (
/usr/bin/gnome-keyring-daemon, already seen in the
gnome-keyring storage with the
seahorse utility for example:
Okay, “It works!” (c).
Another way can be to use
Add a new secret:
Check with the Seahorse in the storage:
Check the D-Bus:
Why not the
kwallet, why still the
Try to kill it:
And the service-file is still old:
Okay, fully delete the
And no service file now:
No new service file:
Does D-Bus and Secret Service are supported by the KWallet at all?
Reddit says it’s not:
In brief, there is no longer a secret service implementation for KDE that I am aware of
ksecretsservice documentation is just full of ToDo’s…
It’s a pity. I do like Qt-based KDE applications.
And the more strange is the fact that the Secret Service specification was written by both GNOME and KDE projects together, but it’s supported by the GNOME Keyring only…
Still, we can use KWallet without the Secret Service integration.
Run the KDE’s wallets manager:
Create a wallet:
Set its password:
Obviously, now our Python lib will stop working as no Secret Service now is available:
Add a password:
Check the D-Bus messages:
And the KWallet:
Also, KeePass can act as a keyring backend service using the Secret Storage specification.
gnome-keyring is still running – you’ll get the “Another secret service is running” error from the KeePass:
gnome-keyring, and activate Secret Service:
Check, who is listening to the org.freedesktop.secrets:
Okay – this is our KeePass.
Add something to the database:
Aha, need to configure an internal path in the KeePass database, see this>>> comment.
Add a new group in the database:
Next, go to the Database > Database settings and specify local path to a directory which will be used to store data when acting as a Secret Service storage:
Restart KeePass and check the D-Bus – can see now how the collection was added now:
Add a record:
Check the D-Bus:
And the KeePass itself:
That’s all for now.
keyrings, Secret Service, etc
- GNOME Keyring – GNOME project docs
- GNOME/Keyring – Arch Linux Wiki
- KDE Wallet
- Python Keyring Lib
- Manage Passwords, Encryption Keys, And More With Seahorse
- secret-tool examples
- Using Linux keyring secrets from your scripts
- Secret Service API Draft
- Python bindings to FreeDesktop.org Secret Service API
- Python keyring lib
- Libsecret Library Reference Manual
- Credentials located in gnome-keyring can be compromised easily
- “Please enter password for encrypted keyring” when running Python script on Ubuntu
- Use keyring to store your credentials
- In KDE Plasma, keyring uses gnome-keyring by default – just for fun
- Get started with the Linux key retention service
- D-Bus Tutorial
- D-Bus Specification
- D-Bus API Design Guidelines
- Introspecting D-Bus from the command-line
- Understanding D-Bus
- dbus-python tutorial
- Universal standard mapping between D-Bus and URI namespaces
- D-Bus, quick recap
Also published on Medium.