Closed Stebalien closed 7 months ago
Agreed, or please provide a detailed justification of why these new permissions are now required. An update asking for those permissions is somewhat alarming.
org.freedesktop.secrets
. Storing the secrets in an encrypted keyring is better from a security perspective because it eliminates the possibility of recovering those secrets from disk via offline attacks or via another user with administrative privileges when the keyring is in a locked state. It's almost never a good idea to store sensitive data in plaintext on disk. I'll admit the org.freedesktop.secrets
interface isn't great, but it does provide valuable protection for application secrets that would otherwise be trivially exposed.org.freedesktop.login1
endpoint by gating them behind interactive authentication. Ref: https://github.com/systemd/systemd/blob/main/src/login/org.freedesktop.login1.policyTo be clear, I'm not concerned about myself. I've already disabled access to these APIs with flatseal. I'm concerned about the insecure defaults.
It's generally good to give applications notice of power state changes so they can perform any cleanup activities needed to write their state to disk.
These are two different problems. Slack needs to know when it's being quit/closed, but that should be handled by intercepting a signal. The fact that I might be shutting down isn't relevant.
I'm also confused because the Chrome flatpak doesn't request access to this D-Bus API. Which means either that flatpak is wrong, this is something specific to electron, or this is something specific to slack (which is worrisome because it means that slack is directly talking to D-Bus from JavaScript, and has direct access to the secret store from JavaScript as well).
Granted, dbus access is (I assume) only available to the node.js process and chrome itself, not content scripts. So that does significantly mitigate the risk (if you trust slack to not snoop).
We do not plan to change this behavior, so I'm closing the issue.
Please consider removing access to these d-bus endpoints. They're way too invasive for a chat app and Slack works just fine without them:
org.freedesktop.secrets
will give slack access to all passwords. The risk of storing the secrets in the apps state is negligible next to that. Remember: Slack is an electron app, the attack surface is massive.org.freedesktop.login1
is less powerful, but still unnecessary (slack really doesn't need to know about suspend events) and can be used to, e.g., unlock a computer remotely.Note: Neither Element nor Signal ask for access to secrets (really, only Chrome does and it actually as a decent reason to do so).