The title says it all but let me expand a bit more:
I'm wondering how the keyring password is protecting my keys. Sure, it encrypts the container file, so no one else can access it. But it is also decrypted after I have provided my keyring password. So in fact, while I'm logged in, the keys could be stolen by some malicious app (at least an app with root permissions should be able to).
Of course, I know, the key file itself is not replaced with a decrypted version after entering the password but it must be decrypted in memory.
The question is: Can malicious apps access data in my keyring while it is decrypted? If so, do I even need a password for my keyring when my disk is already luks encrypted and I'm the only one using my computer?
And, if a password would be more secure, is it possible to have it unlocked automatically, using my account password (or so) after I login?
(I'm not using a login manager, I'm automatically starting i3wm after logging in via TTY, so would be automatic unlocking possible for this setup too?)
Can malicious apps access data in my keyring while it is decrypted?
In practice (currently), yes, they can. The current design (or lack thereof) of user sessions in Linux makes it difficult for gnome-keyring-daemon to determine what program is trying to access it; that's doable to some extent for compiled programs, but e.g. any app written in Python is indistinguishable from any other app written in Python. So although gnome-keyring did at first have an application whitelist, current versions no longer do.
Eventually this should be improved by app container projects such as Snap or Flatpak.
If so, do I even need a password for my keyring when my disk is already luks encrypted and I'm the only one using my computer?
I'd say yes.
As mentioned above, any program can just send a D-Bus message and ask gnome-keyring-daemon for any secret. (In some cases it even works as a feature.)
However, there have been quite a few security holes in which a vulnerable program (e.g. a web browser) could be used to steal your files, although still having no possibility of running commands or sending D-Bus messages. Malware has been known to steal people's unencrypted SSH keys (~/.ssh/id_rsa) or Bitcoin Core wallets.
In the same way, if it is not encrypted, you're leaving ~/.local/share/keyrings/login.keyring at risk of being stolen through web browser exploits and such.
(I'm not using a login manager, I'm automatically starting i3wm after logging in via TTY, so would be automatic unlocking possible for this setup too?)
Automatic unlocking of gnome-keyring is in all cases done through PAM. A module named pam_gnome_keyring.so receives your password as part of the login process, and starts the initial keyring daemon.
The PAM module should be added to /etc/pam.d, wherever your Linux distribution normally adds common modules, or just to the login file (which is specifically for console and telnet logins).
In the auth group (in the "Additional" block in Debian-style common-auth; as the last module otherwise) it will store the password in memory:
[...]
auth optional pam_gnome_keyring.so only_if=login
In the session group (again, "Additional" block for Debian, last module otherwise) it uses the stored password to start gnome-keyring-daemon:
[...]
session optional pam_gnome_keyring.so only_if=login auto_start
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments