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!
You must log in or register to comment.
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.
Does KeepassXC work under Wayland yet without having to use the clipboard to paste passwords?
Since in most cases the keyring is unlocked on login, this seems like a small hurdle to overcome, right? I am trying to figure out if there is something I fundamentally misunderstand about the keyring or if it’s that trivial (and insecure).
KDE requires giving permissions to an app that wants to access kwallet also. I’m sure gnome does something similar.
Giving permission from the user? That would be points for KDE actually. On GNOME I have never been asked, so I doubt it has it.
Yeah - I’ve been asked “application nextcloud wants to access wallet
kdewallet” or something. I think it remembers the app for future requests though.
is something I fundamentally misunderstand about the keyring…
Keyrings like GNOME Keyring support setting it to auto-lock after a timeout. That would be the way to use it, IMO.
I see, this would eliminate random apps from just grabbing the passwords anytime (though they can still poll if they are open). If I choose the auto-lock, I will have to enter password to the keyring often (depending on the time and how many apps need a password). Isn’t then more convenient AND more secure to use a password manager anyway? Apps can’t access my password from the password manager like they do from the keyring, so I could set longer auto-lock delay than the keyring and still be more secure and more convenient, right? Am I oversimplyfying too much? 😀
There are many options to consider. You could use a very short timeout and optimize for low friction unlock, such as with a thumb reader.
My advice, if you have an app you want to use that requires the keyring then use the keyring with it. In general, I say use a password manager.
The fact is, I am trying to determine what do I want to implement for my application. I am introducing database encryption and was thinking about doing what Signal is doing and not bothering the user and saving the key to the keyring, but now I am not sure if that is a good idea and maybe I will just ask user for a password…
I think you understand correctly.
Your setup seems quite insecure considering your keyring seems to be always open and that you use a password that is already used to login.
On the other hand a keyring can be unlocked only when used and could also have it’s own dedicated password for it. Security is more a gradient than something binary.
Also if you store keys that are particularly sensitive in it they are as vulnerable as the container that stores them.
Not blaming you of anything of course, I think you are asking the right questions. 👍
That is the default behavior though. On most mainstream distros at least. The password matches the one that you login with and the keyring is unlocked automatically. And I get it, if I was handling this manually, I may as well just use my password manager right? I was just hoping, that maybe the apps would see only their password. Maybe some dedicated keyring space per app, you know what I mean. I didn’t expect there to be one giant pile of passwords for anybody to grab 😀
If you’re using flatpaks and apps are not configured to skip sandboxing, each app get their own keyring and can’t access others’.
Interesting, and if they are configured to skip sandboxing I could still change it in flatseal right?
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.
Ideally there would be an advanced mode where each app is granted access to specific keys, and that interaction is controlled by the user. This would never be the default obviously as the user interaction would be an insane annoyance to people who don’t care.
Thanks for the summary, a few more questions if its ok: What do you mean by untrusted apps? Is it untrusted by system (by what mechanism) or by some central entity? Container apps, you mean flatpaks? And they get selective access, like there is some space for all flatpaks that is separated, or there is actually one space per app and they don’t see anything else?
This has more details: https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ
This seems to be out of date, and there is no info in the GNOME Project handbook… Maybe its still valid?
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.
That is the default behavior on most mainstream distros. And there is no timeout either, it stays unlocked the whole time you are logged in. In most cases users do not even know they have something like this and what is its purpose (seen a lots of confused people on forums asking about it when they start being prompted for password when they get mismatched from the login one for some reason).
I had to recheck the timeout mention, and you are totally correct.
You can set it to timeout but the default for most distros appears to be that it stays unlocked which is crazy.
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. There’s probably a more elegant way, but I’ve yet to find it.
Not sure if this is your problem. But if you use encrypted system partition + autologin, it should use the encryption passphrase to auto unlock the keyring after the autologin. That is probably what is happening when you remove the password, on the next login it sets the enc passphrase again, right? Why do you try to remove the password?
it should use the encryption passphrase to auto unlock the keyring after the autologin
It doesn’t, hence the need to remove the password. Password only comes back every once in a while, rather than every login. Maybe a bad combination of desktop environment/session manager? LightDM with XFCE in my case.
Did you try to set the password the same as your encryption passphrase? But dunno, I have no idea if that works on your combo.
