Is using a keyring an unsecure thing to do?

2026-06-13 15:52 UTC

I have a hard time understanding the benefits of the keyring (e.g. GNOME keyring). I get the convenience parts - I don’t have to enter password for something every time I want to use it (e.g. mounted encrypted drive) and I don’t have to create a secret for some background stuff (applications keys). But the problem is, if I understand it correctly, that every application has the same access to my keyring, so, in theory, a malicious application can just read my Signal key and they can just read all my Signal messages right? Is there a point, then, in encrypting e.g. local database (like Signal) if the key to that database is readily available anyway? Any input is welcome. thanks!

Replies (6)

@monovergent@lemmy.ml 2026-06-13 16:10

Meanwhile, I’m fighting to get rid of the password on the keyring each time it comes back by itself. For context, my root partition is encrypted, so it’s not a huge deal if the keyring stored on it doesn’t have its own password, I think. I set up autologin to avoid a duplicate password, but since the session manager no longer unlocks the keyring, the keyring must have no password else I get a password prompt all over again.

Open ##3310186
@CallMeAl@piefed.zip 2026-06-13 16:12

A keyring is better than a plain text file (apps can only access the keyring when its unlocked) but not as secure as password keeper like KeepassXC.

Open ##3310223
@Mordikan@kbin.earth 2026-06-13 16:16

I believe that if your login password and gnome keyring password are the same, then the keyring will automatically unlock during login as well. That's something to consider as I'm sure people commonly reuse their password for both. The gnome keyring would sit unlocked until timeout occurs on every login.

Open ##3310251
@just_another_person@lemmy.world 2026-06-13 16:22

The security model skews towards convenience versus absolute security, meaning automation is it’s goal, not perfect security. They use a reasonable amount of security to protect unauthorized access, meaning untrusted apps can’t access keys by default, and container apps only have selective access. AppArmor is supposed to be handling some DBUS interactions in the background to prevent any old app from grabbing everything, but again, automation is the purpose here. If you don’t have a reasonably trusted system, then sure, it’s about as secure as any other password manager. I remember reading some time ago there was a plan to make a global framework for trusted application.accessnto things like this, but it was shot down for being “oppressive” in the same way as Microsoft’s trust app mess.

Open ##3310295
@alastel@lemmy.ml 2026-06-13 16:31

If you’re using flatpaks and apps are not configured to skip sandboxing, each app get their own keyring and can’t access others’.

Open ##3310355
@IanTwenty@piefed.social 2026-06-13 22:48

I think you are absolutely right to examine whether your system defaults to too much convenience versus security for your threat model. For GNOME keyring: Any application can easily read any secret if the keyring is unlocked. And, if a user is logged in, then the login/default collection is unlocked. Available D-Bus protection mechanisms (involving the busconfig and policy XML elements) are not used by default and would be easy to bypass anyway. The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service. Applications sandboxed via Flatpak only have filtered access to the session bus. https://wiki.archlinux.org/title/GNOME/Keyring#Security So while flatpaks that play the game are ok everything else is on trust. For the average user perhaps this is the right balance, though your Signal example suggests it’s too lax for anyone nowadays. I would like to see system secrets protected however they are accessed, not just for flatpaks.

Open ##3313531