Just stopping by to update, I’ll be running the tests on Tuesday July 3rd. My apologies. This is quite involved too 
1 Like
I’m curious how your testing went. I’m also interested in having everything managed by KeePassXC across my Fedora installs but… am also not (yet) brave enough to jump in.
2 Likes
I can sum it up with needs more testing, and I have not gotten back to it. Thanks for bringing this back up though, It somehow fell off my list.
Create a Custom PAM Configuration
Override Autostart Configurations
Override the D-Bus Service
2 Likes
This will be really worth the effort though. KeepassXC has passkey support, which is huge.
Do you know how secure gnome-keyring is? I am currently giving GNOME another chance. KDE kwallet is a total Xorg-like security mess.
KeepassXC is going so well, that maybe they could simply replace the DE ones.
Do you know what COSMIC uses? Probably gnome-keyring.
Not at all. Once you sign in, your keyring is completely unlocked and a trivial command (such as the one below) can be used to dump whatever passwords it has harvested. The below command requires that you have libsecret installed, but there are other (trivial) ways to query the dbus API.
$ for p in https smb; do secret-tool search --all protocol $p; done
What really annoys me is how these programs essentially behave like keycapture malware and record the passwords and private keys you use without notifying you that they are doing so. 
Putting a password/key into a system that will automatically regurgitate it whenever anyone asks should be something that the user manually decides they want to do. That sort of thing should not be automated.
2 Likes
So gnome-keyring is just like kwallet in the Xorg style “apps get whatever they want”.
Is KeepassXC better here in its secret service implementation?
I’m not a KeepassXC user. I’m not a fan of any of these systems really. The best system IMHO, is probably Kerberos SSO type system that Fedora uses for some of their sites and services (or security keys like YubiKey that don’t allow the private key to be exported). But being “better” than gnome-keyring is a pretty low bar, so I would have to guess that KeepassXC probably is “better”.
1 Like
@glb Being legendary as usual. 
I use KeepassXC HEAVILY. Especially since moving my key-files, gpg/ssh keys to it. So I’m glad to learn this. Now I really gotta up this on the priority list then.
Is this something that should be raised with the Gnome team? They do tend to the security side of things I believe.
So SELinux context for
unconfined_u:object_r:gpg_secret_t:s0unconfined_u:object_r:ssh_home_t:s0
Doesn’t really mean much, as it’s s0 being a low sensitivity. . .
I cannot image that they are not aware of the issue. But I haven’t personally asked anyone on that team about it.
That, and because the dbus has access (it has to by design) and I think pretty much anything can query dbus. I’m not completely sure about what security measures dbus implements though. It is possible that it isn’t quite as bad as I think it is.
1 Like
A quick google search turns up this quote:
Excerpted from stackexchange.com – d-bus-authentication …:
The D-Bus daemon is using your kernel-verified user ID to verify your identity.
So apparently as long as a process is running under your/the-correct $UID, it can probably access the keyring without any further authentication requirement. (But that is just my quick read of the situation, I’m not really knowledgeable about its workings.)
1 Like
So using KeepassXc and locking the vault would be better?
Designing a “secure” system is not a trivial task. I like the way Kerberos tickets a) expire after a short time and b) are tied to the system they are created on (the IP address of the client system, among other things is hashed into the Kerberos ticket in such a way that even if an attacker were able to intercept or copy your Kerberos ticket, they would not be able to use it remotely from another system).
Security keys are a good way to store SSH private keys because they implement a system where the private key cannot be exported from the hardware device. A “stub” file is stored under ~/.ssh in place of your private key. Newer versions of OpenSSH will deference the private key stub and forward the (initial) data to be decrypted to the hardware security key.[1][2]
Excerpted from developers.yubico.com – Securing SSH Authentication with FIDO2:
About Using FIDO2 Security Keys for SSH
Why use FIDO2?
Enhanced Security: The private key is securely generated and stored on the YubiKey and cannot be exported.
As long as some user interaction is required to access the vault (i.e., it is locked most of the time), KeepassXC is surely better than gnome-keyring.
Only a small amount of data that is part of the “handshake” needs to be decrypted by the hardware key. After that, new, session-specific encryption keys that are agreed upon between the client and server are used for encrypting and decrypting the remainder of the data stream. ↩︎
1 Like
Psst… TPM integration…
1 Like