If you're not entering a password at some point, then they're in memory and available to all anyway. If no system prompts or notifies you access is happening, then it's irrelevant what software machinations might be governing this.
iOS and macOS combine sandboxing with their Secure Element. Android uses TEE or a secure element-like piece of hardware. Windows uses a hypervisor + the (f)TPM.
Nothing Linux can't do, it's basically glueing together a small early boot KVM VM + TPM + secure boot together with an API. Setting up your own secure boot keys to make it run relatively seamless is a pain on many consumer devices, though.
The secrets in the keyring of my secure boot protected, full disk encrypted laptop are exactly as secure until I boot it up and unlock the keyring for Dbus.
On Windows the application can specify some extra entropy/salt, and the secret is not decryptable without it[1]. So it's a tad more difficult to exfiltrate than simply asking for it.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf...
What are people not getting about this? The point of a shared keyring is to enable applications to share secrets. My git tokens are shared between git, my IDE, various scripts etc.
This discussion highlights the exact issue: people don't even understand what problem or use case they are actually solving.
Yes, you want a system that allows sharing of those tokens between various tools, but you also want the user to be in control of which tools can share them.
There are secrets I cannot export from my system keychain without disabling SIP on my Mac.
Windows' Credential Guard (https://learn.microsoft.com/en-us/windows/security/identity-...) is explicitly designed against the "dump all secrets while the system is running" approach.
Even Mimikatz requires exploiting design vulnerabilities and requires administrator access.
If you can break the kernel and all the safeguards the kernel has against secret exfiltration, you may be able to decrypt data from other applications, but it's not like on Linux enviroments where any application running as any standard user can dump the entire credential database by just asking.
They entered a password to log in probably. And Linux had a setting to restrict ptrace since years.
Imagine if it worked that way for browsers, and every website with a saved-password got to see all the other saved passwords...
> Why is your banking app entering a secret to your keyring?
What is any "keyring" for if not to carry things you keep secret and exclusive?
The problem here is leakage between purposes. I don't care if the banking app is just storing my logon name for convenience, even that should never be scrapeable by Linux BonziBuddy. [0]
> That would be like writing your safe code in a paper and let it hang onto a physical keyring.
Why even put any regular keys onto such a horribly flawed keyring either? There's no real difference between (A) seeing combination-lock numbers versus (B) seeing the shape of a key that is trivial to reconstruct. [1]
In fact, I was attempting that kind of thing just this week, namely trying to run Spotify (distributed as a snap) as separate user in a visible window. Maybe it's possible, but it's certainly not trivial or turnkey.