2

I am running debian 10, xfce, gnome-keyring, ssh-agent, LUKS partition.

The reason why I use gnome-keyring is because I don't want to enter ssh key passphrase once upon a reboot. And this is because there are many CCTV cameras around. I am afraid if some kinda secret CCTV camera records what I typed. I always avoid entering passwords and trying to enter as less time as possible.

With the current setup, I need to enter two passwords at least. One for LUKS partition and one for system login in lightdm.

Today, I am thinking to reduce one password requirement and make the system autologin, so no need to enter system user login password anymore. I think this is still in the same security level as before because LUKS parittion encryption is still there. (OR less secure, but still secure with LUKS)

Once I enable autologin, I find out the gnome keyring is no longer unlocked automatically anymore. If I want to unlock it with my current setup, I have to enter unlock password again, that is the second password I want to avoid.

By goolging, I find out I can simply remove the unlock password from gnome keyring in seahorse so make it unlock with autologin.

The above is the detail story of my current situation. So here is the question. I don't know what will really happen in the background if I remove the unlock password from gnome keyring.

The reason why I used gnome keyring is because I don't want any running programs in my system can access the ssh private key directly from the file system ~/.ssh/id_rsa. Some people may argue that programs may still get the keys from memory. I don't really care how that works as long as this improves some kind of security. I am OK as long as the unencrypted ssh-key is not stored in the file system somewhere. I am afraid removing password from gnome-keyring will make unecnrypted files stored in file system in a plain text format. Will removing password from gnome keyring make any difference on the storage (file system) point of view?

I don't really care there is no password to unlock the keyring, because I have LUKS partition encryption and people can not use the keyring unless they know my LUKS password. But I do care if any running programs can access some plain text keys directly from file system if I remove the keyring password.

I hope I have made myself clear in this question and thank you very much for your help.

1 Answer 1

3

I don't know what will really happen in the background if I remove the unlock password from gnome keyring

The keyring's password is not used directly as your SSH keys' password. It is only used to encrypt a single file – the database located at ~/.local/share/keyrings/login.keyring.

All your SSH keys and other files will remain encrypted with their original passphrases.

(Older systems might have two separate keyrings "login" and "default". In this case, you only need to decrypt the "login" keyring, as it also stores passphrases for all other keyrings.)

I don't really care there is no password to unlock the keyring, because I have LUKS partition encryption and people can not use the keyring unless they know my LUKS password. But I do care if any running programs can access some plain text keys directly from file system if I remove the keyring password.

I have two different answers to this, both of which are bad news:

  • The first problem is that your password is the only encryption key source that GNOME Keyring has available to it. If you remove the password, then GNOME Keyring will be forced to store its password database completely unencrypted. (It'll even convert keyrings/login.keyring from binary database to textual format to make this very clear.)

    This does not directly change anything regarding your SSH key files: if they were encrypted before, they will still be encrypted after. But their encryption passphrase, and indeed all other passwords and passphrases (possibly even your GnuPG key passphrase), will be stored inside GNOME Keyring's database in plain text.

    So if your biggest concern is direct filesystem access, then yes, your keys can be stolen – the attacker only needs to steal one additional file now.

  • The second problem is that...the first problem doesn't even matter, because regular apps are not limited to accessing only their own keyring entries. As long as your GNOME Keyring is unlocked, any non-Flatpak program can use the official API to query any entry stored in the keyring and obtain any stored password it wants, without needing to snoop memory or other trickery. Try it out from the CLI:

    secret-tool search --all xdg:schema org.freedesktop.Secret.Generic
    secret-tool search --all xdg:schema org.gnupg.Passphrase
    

    So the keyring passphrase is only useful to protect against offline attacks (and is redundant when LUKS in use) – it was never useful to protect against malicious software on a running system.


Here are some ideas for increasing security (mainly under the assumption that you're guarding against generic exploits/viruses/worms and not against targeted attacks):

  • Install apps via Flatpak if possible. By default they are confined into a container which cannot access your files and cannot access your keyring either.

  • Apps that do not come in Flatpak can be run under a different UID (e.g. via Xvnc or Xephyr to make them show up on your main screen). Some people run Firefox in this way, so there are plenty of tutorials.

  • SSH keys can only be loaded into ssh-agent but not extracted out from it. Together with this fact, it might be possible to configure AppArmor or SELinux in a way that prevents any process except 'ssh-add' from accessing ~/.ssh/id_* files.

  • You could store RSA or ECDSA keys in a dedicated hardware token – e.g. your laptop's TPM chip if it has one. (If it doesn't, then a Yubikey with PIV/OpenPGP support can do the same job differently.) Just like ssh-agent itself, the token will not allow you to get the original key back – it will only provide signing operations.

    (In theory FIDO/U2F tokens work the same way, but they only allow signing data in very specific format, so they cannot be re-used as ordinary SSH keys. The very latest OpenSSH version can use FIDO tokens using the new sk-* key types but all your servers must also be upgraded to support them first.)

  • Lacking hardware support, you could combine ssh-agent with SoftHSM virtual smartcard, which is still software but it's very easy to make it run under a dedicated UID. This way your main UID will not have any access to SoftHSM's database, and only be able to do operations its PKCS#11 module allows.

  • Qubes OS, I guess?

6
  • Thank you very much for the quick reply. I have upvoted it. (1) If I understand correctly, with LUKS encryption, I am OK to remove the gnome keyring password. This makes no real difference actually. (2) How can I avoid malicious software to query/obtain stored passwords from the API (after unlocking gnome-keyring). This looks very insecure to me. There are many apps running and I have no time to read their source code. Especially, there might be closed source apps too. T_T. thanks.
    – sgon00
    Jul 10, 2020 at 8:44
  • Probably the only good answers are a) use Flatpak-based apps, which do not have global keyring access, or b) run closed source apps under a different UID, e.g. via Xvnc or Xephyr. (Many years ago GKR used to have prompts such as "Allow app X to access entry Y? [yes/no]", but this got removed since unsandboxed apps could very easily bypass it... Maybe things would have improved now, but the development focus is on Flatpak anyways.) Jul 10, 2020 at 8:51
  • Or actually I would suggest storing at least your SSH keys in dedicated hardware instead. Some laptops have a TPM chip which can hold RSA2048 keys for you, for others you can get a Yubikey nano with PIV and OpenPGP support. Jul 10, 2020 at 8:54
  • Thank you very much for the detail explanation and answer. I have accepted it as the answer. I got shocked I could get my ssh-key password so easily with secret-tools command line. I thought my password were extremely secure. Now, I feel really bad. haha...
    – sgon00
    Jul 10, 2020 at 8:55
  • 1
    No, the difference between passwords and keys is that the latter do not have to be returned in full. It's actually the same as with ssh-agent: you can only ask it to sign stuff with the key it holds (e.g. it will sign the SSH authentication challenges), but you cannot actually extract the original private key out of it. Likewise a TPM chip or a smartcard will only allow specific operations with the key but will never give you the actual key back. The new FIDO/U2F/Webauthn keys also work using the same idea. Jul 10, 2020 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .