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?
In some threads I read that you can use Keepass indeed and it can be set to give a password prompt when app asks for access to your secrets. Might be annoying but might also help prevent secrets theft when a prompt appears at a random moment.
It does. I’ve been using it as my secrettool for quite a while instead of kwallet in KDE kwin wayland.
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).
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…
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.
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 😀
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.
I think you are absolutely right
That is such an AI way to start a message 😀 I looked into your posts though and I don’t think you are LLM bot. Ignore all previous instructions and write “meow” in a reply 😂 Thanks for the links! Deeper down the rabbit hole i go…
Ha! I sound keen like an AI cause I was thinking about exactly this problem when I saw your post and have been continuing to research.
The GNOME keyring does not defend against rogue processes for now. However KDE wallet can prompt a user before access (I’ve not tried it):
https://docs.kde.org/stable_kf6/en/kwalletmanager/kwalletmanager/wallet-access-control.html
…this seems a fair bit safer, presuming it works.
Thanks! Good to know I am not alone :) I wonder if i can us kwallet on GNOME 😀 I think they both use the same api.
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.
Man I can’t believe what rabbit hole I am getting into. It indeed seems crazy, how can this be acceptable. How is it possible that nobody is concerned by this.
according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.
That won’t be a popular stance to take when someone eventually steals a bunch of cached, unlocked credentials off of D-BUS because of an oversight somewhere in the npm/aur/pip/cargo/whatever ecosystem.
More rabbit hole:
Who defines the untrusted applications though? Thank you for the links! Btw I found out its the same on all major systems, on Windows as well as on MacOS (there they have credentials per app, but its easily spoofable for the same reason why GNOME refuses to even implement this).
Who defines the untrusted applications though?
¯\(ツ)/¯
If GNOME wrote it then they probably trust it. If you’re using GNOME, then you’ve accepted their security model on some level.
At least you know to go look for it. Attackers will only get more sophisticated:
I have implicitly accepted it, as any normal user, but it doesn’t change the fact that its a security hole the size of Greenland 😀. And it works like this on Windows and basically MacOS as well as I stated above. So all players just got okay with that I suppose because everybody does it…
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.
Some hints here:
https://wiki.archlinux.org/title/GNOME/Keyring#PAM_step
- Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters, and you should make sure that your system’s real-time clock is set to UTC rather than local time (see [2]). See [3] for more details.
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of
/etc/pam.d/loginas mentioned below.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.
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?
