Where do you think those secrets are going to be stored otherwise and how are you planning to authenticate to them?
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.
On platforms like Android, iOS, and macOS, secrets are easily stored encrypted with no access to the key unless you exploit the kernel. On Windows, a similar feature is opt-in, but compatibility makes it a little less reliable.
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.
All of that is about protecting secrets at rest on the device. It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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.
> It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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...
Which is still protecting secrets at rest.
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.
From what I read here, the problem is that EVIL.app can read your git tokens, too, without you having anything to say about it.
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.
Android apps can never exfiltrate each other's secrets using the secret manager. Even while the apps are running. Same goes for iOS apps. You can maybe trick them into leaking their session tokens using weird browser exploits, but it's entirely up to the app developer to make that happen.
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.
Keychain access can be limited with ACLs, enforced with code signing signatures as well on iOS and more so on macOS where the “keychain” can still be the older file based type.
There are secrets I cannot export from my system keychain without disabling SIP on my Mac.
You believe any Android or iOS app can exfiltrate all stored secrets?
> If you're not entering a password at some point, then they're in memory and available to all anyway.
They entered a password to log in probably. And Linux had a setting to restrict ptrace since years.
When Important Banking App stores a secret to my "keyring", I would never have expected that the "secret" would be trivially available to all other programs that run.
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? That would be like writing your safe code in a paper and let it hang onto a physical keyring.
The problem isn't what's on the keyring, the (reported) problem is that it can be arbitrarily inspected in full by any program. Doors should not be able to enumerate and copy all the keys that aren't meant for them.
> 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]
[0] https://en.wikipedia.org/wiki/BonziBuddy
[1] https://en.wikipedia.org/wiki/Bitting_(key)
Unix already have a security model for this: User and Groups. You could create a new user called `banking`. And used that exclusively for any banking activities. Especially with the X11 model where you just have to type `startx` and not have to launch a bazillion software to keep a DE happy.
Have you actually tried that approach, with an individual user for all your programs?
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.
That's what Android does. Desktop Linux should make this easier.