5 ms·

What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus (2019)

100 points by 3np 5y ago

ayende 5y ago
A really annoying aspect of keyrings in Linux is that if you are writing a generic Linux service (runs in the background, should support all distributions), there is no real option without 3rd party components. On Windows, there is the Data Protection API, which allows you to encrypt a secret tied to a user's login or a machine's key. That is managed by the OS and allows you to lean on the built-in facilities.
- paulfurtado 5y ago
  Are you aware of the kernel keyring and the keyctl API? I've always been curious why more programs don't use it, I guess it's not the most ergonomic API and doesn't have many language bindings. https://man7.org/linux/man-pages/man2/keyctl.2.html https://man7.org/linux/man-pages/man2/keyctl.2.html
  - toyg 5y ago
    I considered it but, iirc, it's Linux-specific and I wanted something that could run on BSDs too.
    - tremon 5y ago
      That's nice, but you're moving the OP's goalposts here. The OP only mentioned Linux.
  - GoblinSlayer 5y ago
    That's a big manpage, but it tells nothing about what it is and does, you already need to know everything about it, but only want to refresh details.
    - danuker 5y ago
      Probably the kernel keyring one is a better intro: https://man7.org/linux/man-pages/man7/keyrings.7.html https://man7.org/linux/man-pages/man7/keyrings.7.html
  - hawski 5y ago
    AFAIU from the post itself it seems the main problem is, that the kernel keyring API doesn't implement persistence, so it can be used to implement high level key-rings, but it is not enough by itself.
- Nextgrid 5y ago
  Someone above mentioned systemd-creds: https://www.freedesktop.org/software/systemd/man/systemd-creds.html# https://www.freedesktop.org/software/systemd/man/systemd-cre...
  - krageon 5y ago
    systemd is not linux.
    - RobertMiller 5y ago
      Neither is your shell. You may as well complain that there is no way to use Linux at all without some form of 3rd party software one way or the other. It's a silly complaint; this is why distros exist.
- yrro 5y ago
  A requirement I'd like to see for such a Linux service would be to not rely on the user's password. When my users change their AD password, they have a nasty time unlocking their GNOME keyring...
  - sp1rit 5y ago
    What alternative to a users passwords do you have in mind? The only other potential cryptographically secure alternative might be a TPM chip, if a machine has this. However since a TPM stores secrets system wide, keyrings for each user seam unfeasible and it's likely less secure since you could just boot into single user mode and get the TPM secrets. Additionally I tend to not trust the TPM (esp. on Linux), because if one firmware update somehow fails to apply properly, I'll have a far more nastier time (since all secrets are gone) than GNOME Shell promoting me to insert my old password.
    - yrro 5y ago
      I really don't know, to be honest. TPM is one option. They should be pretty reliable--if not then you'd have Windows users kissing their encrypted disks goodbye, right? Another option (in my case) would be using FreeIPA's vault service to stash the key. It would be pretty easy for malware to grab the key though. Perhaps some setup where both a key owned by the user and a key owned by the host, with access mediated by sssd could be designed... (And admittedly for AD users it's no good since they can't use the vault service...) It feels like AD is missing some kind of secret storage service for users to make use of.
  - WhyNotHugo 5y ago
    It's also annoying on single user laptos, where I type a disk decryption password at startup, but then the have autologin set up (since it's pointless to prompt for a user password at that point).
- richardwhiuk 5y ago
  What's a third party component in this context?
laktak 5y ago
I'd really like systemd to implement a keyring/keychain like service that could be used for all secrets (gpg, ssh, passwords, etc.) even when you do not have a UI.
- arccy 5y ago
  systemd-creds gets you part of the way there
- Nextgrid 5y ago
  Ideally something that could use the TPM or whatever other secure element is in the machine.
  - zaik 5y ago
    Checkout the LoadCredentialEncrypted= option.
- tga 5y ago
  I'm genuinely curious, why would you like this to be a part of systemd instead of an independent system service?
  - throwaway984393 5y ago
    Know how companies love to create "microservices" that all share the same database? I think the same reason for that is why people like shoving more stuff into systemd. It might be a bad design but it's convenient. It's sad that more and more applications are unusable without systemd.
  - yoyohello13 5y ago
    As much as people hate on systemd. It’s pretty easy to use and having a bunch of system services designed to interop nicely is great. I use systemd-boot, systemd-networkd, systemd-timers (instead of cron), logind and I’m interested in checking out systemd-homed at some point. Having a systemd component to manage creds would be nice.
3np 5y ago
I wish there were more providers for org.freedesktop.secrets.service (which a lot of existing software depends on) apart from gnome-keyring and keepassxc. Here is one early attempt, backed by gnupass: https://github.com/mdellweg/pass_secret_service https://github.com/mdellweg/pass_secret_service With some more contributors we should be able to get there!
- WhyNotHugo 5y ago
  I'd love to see one where one has to tap a fingerprint-reader or a yubikey to allow applications to read secrets (or even just confirm in a pop-up that says "hey, firefox wants to read secret XYZ from the secret store". The big issue is that the protocol is synchronous (rather than async), so backends must reply immediately to the client, and can't wait too long for user input (otherwise the D-Bus request times out). The protocol seems to have been designed with a bit of an "everyone can ready everything" model. It would also be great to see some browser integration with this protocol too -- so website passwords can also be saved in a `org.freedesktop.secrets.service` backend. The big difference with current browser password managers being, rather than the DB exist INSIDE the browser's sandbox, it exist in another service, and only passwords which one explicitly authorises are shared with the browser. I believe the spec allows for this last item, but if there's no way to authorise individual items, I wouldn't be comfortable using it, since any browser security issue would allow access to ALL passwords in the system DB.
- mikewhy 5y ago
  Support is coming to kwallet: https://invent.kde.org/frameworks/kwallet/-/merge_requests/11 https://invent.kde.org/frameworks/kwallet/-/merge_requests/1...

100 points by 3np 5y ago

A really annoying aspect of keyrings in Linux is that if you are writing a generic Linux service (runs in the background, should support all distributions), there is no real option without 3rd party components. On Windows, there is the Data Protection API, which allows you to encrypt a secret tied to a user's login or a machine's key. That is managed by the OS and allows you to lean on the built-in facilities.

paulfurtado 5y ago
Are you aware of the kernel keyring and the keyctl API? I've always been curious why more programs don't use it, I guess it's not the most ergonomic API and doesn't have many language bindings. https://man7.org/linux/man-pages/man2/keyctl.2.html https://man7.org/linux/man-pages/man2/keyctl.2.html
- toyg 5y ago
  I considered it but, iirc, it's Linux-specific and I wanted something that could run on BSDs too.
  - tremon 5y ago
    That's nice, but you're moving the OP's goalposts here. The OP only mentioned Linux.
- GoblinSlayer 5y ago
  That's a big manpage, but it tells nothing about what it is and does, you already need to know everything about it, but only want to refresh details.
  - danuker 5y ago
    Probably the kernel keyring one is a better intro: https://man7.org/linux/man-pages/man7/keyrings.7.html https://man7.org/linux/man-pages/man7/keyrings.7.html
- hawski 5y ago
  AFAIU from the post itself it seems the main problem is, that the kernel keyring API doesn't implement persistence, so it can be used to implement high level key-rings, but it is not enough by itself.
Nextgrid 5y ago
Someone above mentioned systemd-creds: https://www.freedesktop.org/software/systemd/man/systemd-creds.html# https://www.freedesktop.org/software/systemd/man/systemd-cre...
- krageon 5y ago
  systemd is not linux.
  - RobertMiller 5y ago
    Neither is your shell. You may as well complain that there is no way to use Linux at all without some form of 3rd party software one way or the other. It's a silly complaint; this is why distros exist.
yrro 5y ago
A requirement I'd like to see for such a Linux service would be to not rely on the user's password. When my users change their AD password, they have a nasty time unlocking their GNOME keyring...
- sp1rit 5y ago
  What alternative to a users passwords do you have in mind? The only other potential cryptographically secure alternative might be a TPM chip, if a machine has this. However since a TPM stores secrets system wide, keyrings for each user seam unfeasible and it's likely less secure since you could just boot into single user mode and get the TPM secrets. Additionally I tend to not trust the TPM (esp. on Linux), because if one firmware update somehow fails to apply properly, I'll have a far more nastier time (since all secrets are gone) than GNOME Shell promoting me to insert my old password.
  - yrro 5y ago
    I really don't know, to be honest. TPM is one option. They should be pretty reliable--if not then you'd have Windows users kissing their encrypted disks goodbye, right? Another option (in my case) would be using FreeIPA's vault service to stash the key. It would be pretty easy for malware to grab the key though. Perhaps some setup where both a key owned by the user and a key owned by the host, with access mediated by sssd could be designed... (And admittedly for AD users it's no good since they can't use the vault service...) It feels like AD is missing some kind of secret storage service for users to make use of.
- WhyNotHugo 5y ago
  It's also annoying on single user laptos, where I type a disk decryption password at startup, but then the have autologin set up (since it's pointless to prompt for a user password at that point).
richardwhiuk 5y ago
What's a third party component in this context?

laktak 5y ago

I'd really like systemd to implement a keyring/keychain like service that could be used for all secrets (gpg, ssh, passwords, etc.) even when you do not have a UI.

arccy 5y ago
systemd-creds gets you part of the way there
Nextgrid 5y ago
Ideally something that could use the TPM or whatever other secure element is in the machine.
- zaik 5y ago
  Checkout the LoadCredentialEncrypted= option.
tga 5y ago
I'm genuinely curious, why would you like this to be a part of systemd instead of an independent system service?
- throwaway984393 5y ago
  Know how companies love to create "microservices" that all share the same database? I think the same reason for that is why people like shoving more stuff into systemd. It might be a bad design but it's convenient. It's sad that more and more applications are unusable without systemd.
- yoyohello13 5y ago
  As much as people hate on systemd. It’s pretty easy to use and having a bunch of system services designed to interop nicely is great. I use systemd-boot, systemd-networkd, systemd-timers (instead of cron), logind and I’m interested in checking out systemd-homed at some point. Having a systemd component to manage creds would be nice.

3np 5y ago

I wish there were more providers for org.freedesktop.secrets.service (which a lot of existing software depends on) apart from gnome-keyring and keepassxc. Here is one early attempt, backed by gnupass: https://github.com/mdellweg/pass_secret_service https://github.com/mdellweg/pass_secret_service With some more contributors we should be able to get there!

WhyNotHugo 5y ago
I'd love to see one where one has to tap a fingerprint-reader or a yubikey to allow applications to read secrets (or even just confirm in a pop-up that says "hey, firefox wants to read secret XYZ from the secret store". The big issue is that the protocol is synchronous (rather than async), so backends must reply immediately to the client, and can't wait too long for user input (otherwise the D-Bus request times out). The protocol seems to have been designed with a bit of an "everyone can ready everything" model. It would also be great to see some browser integration with this protocol too -- so website passwords can also be saved in a `org.freedesktop.secrets.service` backend. The big difference with current browser password managers being, rather than the DB exist INSIDE the browser's sandbox, it exist in another service, and only passwords which one explicitly authorises are shared with the browser. I believe the spec allows for this last item, but if there's no way to authorise individual items, I wouldn't be comfortable using it, since any browser security issue would allow access to ALL passwords in the system DB.
mikewhy 5y ago
Support is coming to kwallet: https://invent.kde.org/frameworks/kwallet/-/merge_requests/11 https://invent.kde.org/frameworks/kwallet/-/merge_requests/1...