5 ms·

> However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked >> The GNOME project disagrees with this vulne

by ghusto 10mo ago

> However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked >> 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. I'd like to point out for anyone on the fence that yes, Gnome is run by clowns in full sized clown shoes.

Asooka 10mo ago
Fortunately today with AI everyone CAN actually audit all the code for all the software running on their machine themselves by sending it to a black box cloud service, thereby running only software they KNOW they can trust! /s
tocariimaa 10mo ago
"works as intended wontfix conversation locked"
skydhash 10mo ago
I always thought as the secret for things that should not be saved non-encrypted on disk, not for things that should be kept hidden from other applications. And if that is your threat model, you should look into virtual machines.
- k4rnaj1k 10mo ago
  [dead]
- WD-42 10mo ago
  That’s exactly what it’s for. Parent is just being rude for no reason.
- rnhmjoj 10mo ago
  There are no excuses, this protocol is just terrible: it could have been made much much more secure without any kind of virtualisation or sandboxing. For example, the kernel could be used[1] to store the secrets in memory and only authorize the userspace process that created it to read it; other processes could request access to a secret and only be given if you accept. [1]: https://docs.kernel.org/security/keys/core.html https://docs.kernel.org/security/keys/core.html
rcxdude 10mo ago
This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")
- rnhmjoj 10mo ago
  Yes, it's 100% a security theatre. Programs aren't even allowd to set their own icon because it's not considered secure, I'm not joking. The reasoning goes something like: what if a malicious program set its name to "firefox" and uses the firefox icon and then prompts you for the gmail password, eh? At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
  - preisschild 10mo ago
    > At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid. Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
    - rnhmjoj 10mo ago
      Sandboxing on the Linux desktop is far from common and the flatpak security is kind of a joke [1] [2], unless something changed recently. For starters, it's the application that has to ask to be sandboxed, so if I were to make a malicious flatpak I will just ask for full file system access or d-bus. [1]: https://flatkill.org/ https://flatkill.org/ [2]: https://hanako.codeberg.page/ https://hanako.codeberg.page/
      - preisschild 10mo ago
        https://tesk.page/2021/02/11/response-to-flatkill-org/ https://tesk.page/2021/02/11/response-to-flatkill-org/
      - 10mo ago
Spivak 10mo ago
Program running as user can read data owned by user. If this is a vulnerability then the entire linux userspace is compromised. Can you believe that applications I run can execute gpg2 and steal all my secrets? The dbus process is run by and owned by your user. The only people that can access it is you and root. There is a system-wide bus but your secret manager isn't using that one. It's just this: https://xkcd.com/1200/ https://xkcd.com/1200/
- wpm 10mo ago
  It’s almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.
  - Spivak 10mo ago
    Zero disagreement but GNOME I don't think is the one in a position to fix this as I'm not aware of any implementation of the better application level security model that doesn't require a lot of kernel support.
    - yxhuvud 10mo ago
      For some reason the OS can manage to ask me about what windows I want to screen share, but not about if i want to share secrets between apps or not? I don't see how this require kernel support - it just needs people recognising it as a problem that is wanting to spend the time actually solving it.
      - Spivak 10mo ago
        I mean kinda yeah. Literally any program running as your user can connect to dbus, grab your secrets and slurp your home directory. Flatpak 'solves' this issue by putting the program in a sandbox that can't talk directly to dbus and proxies the messages with a filter. The thing you need the kernel for is to attach meaningful identities to programs and restrict them without needing to sandbox them. And there is a ready made solution to this, one that dbus is already aware of and can use natively. But on systems where it's available a lot of users immediately disable it—SELinux.

by ghusto 10mo ago

Asooka 10mo ago

Fortunately today with AI everyone CAN actually audit all the code for all the software running on their machine themselves by sending it to a black box cloud service, thereby running only software they KNOW they can trust! /s

tocariimaa 10mo ago

"works as intended wontfix conversation locked"

skydhash 10mo ago

I always thought as the secret for things that should not be saved non-encrypted on disk, not for things that should be kept hidden from other applications. And if that is your threat model, you should look into virtual machines.

k4rnaj1k 10mo ago
[dead]
WD-42 10mo ago
That’s exactly what it’s for. Parent is just being rude for no reason.
rnhmjoj 10mo ago
There are no excuses, this protocol is just terrible: it could have been made much much more secure without any kind of virtualisation or sandboxing. For example, the kernel could be used[1] to store the secrets in memory and only authorize the userspace process that created it to read it; other processes could request access to a secret and only be given if you accept. [1]: https://docs.kernel.org/security/keys/core.html https://docs.kernel.org/security/keys/core.html

rcxdude 10mo ago

This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")

rnhmjoj 10mo ago
Yes, it's 100% a security theatre. Programs aren't even allowd to set their own icon because it's not considered secure, I'm not joking. The reasoning goes something like: what if a malicious program set its name to "firefox" and uses the firefox icon and then prompts you for the gmail password, eh? At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
- preisschild 10mo ago
  > At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid. Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
  - rnhmjoj 10mo ago
    Sandboxing on the Linux desktop is far from common and the flatpak security is kind of a joke [1] [2], unless something changed recently. For starters, it's the application that has to ask to be sandboxed, so if I were to make a malicious flatpak I will just ask for full file system access or d-bus. [1]: https://flatkill.org/ https://flatkill.org/ [2]: https://hanako.codeberg.page/ https://hanako.codeberg.page/
    - preisschild 10mo ago
      https://tesk.page/2021/02/11/response-to-flatkill-org/ https://tesk.page/2021/02/11/response-to-flatkill-org/
    - 10mo ago

Spivak 10mo ago

Program running as user can read data owned by user. If this is a vulnerability then the entire linux userspace is compromised. Can you believe that applications I run can execute gpg2 and steal all my secrets? The dbus process is run by and owned by your user. The only people that can access it is you and root. There is a system-wide bus but your secret manager isn't using that one. It's just this: https://xkcd.com/1200/ https://xkcd.com/1200/

wpm 10mo ago
It’s almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.
- Spivak 10mo ago
  Zero disagreement but GNOME I don't think is the one in a position to fix this as I'm not aware of any implementation of the better application level security model that doesn't require a lot of kernel support.
  - yxhuvud 10mo ago
    For some reason the OS can manage to ask me about what windows I want to screen share, but not about if i want to share secrets between apps or not? I don't see how this require kernel support - it just needs people recognising it as a problem that is wanting to spend the time actually solving it.
    - Spivak 10mo ago
      I mean kinda yeah. Literally any program running as your user can connect to dbus, grab your secrets and slurp your home directory. Flatpak 'solves' this issue by putting the program in a sandbox that can't talk directly to dbus and proxies the messages with a filter. The thing you need the kernel for is to attach meaningful identities to programs and restrict them without needing to sandbox them. And there is a ready made solution to this, one that dbus is already aware of and can use natively. But on systems where it's available a lot of users immediately disable it—SELinux.