Hi,
Strange “issue” happening here. My keyring keeps adding a user.keystore file with a single certificate from MS that expired in 2014. It also keeps setting it’s password back from blank values to my login password. I have never seen this behavior in previous versions - this is 37.
I have deleted the user.keystore file numerous timesas well as linked it to /dev/null, but it reappears randomly.
I always know it is back when my keyring requests to be unlocked upon login.
Any ideas?
TiA
-Greg
I don’t believe so. This is a fresh 37 install on a blank nvme stick.
Also, why would it unlink a symlink and write a new file and also reset the 'login" with a password after I have blanked it?
Keep in mind, it is a MS cert that expired in 2014 that keeps getting populated. All apps are installed directly from RH repos - no 3rd party repos enabled except the 3rd party repos enabled during the Fedora installation.
I cannot find anything in journals or logs related to this. I can say exactly when it happens though - when GDM comes up and does not allow me to log in with a fingerprint, it happens. I cannot find a correlation. Sometimes on cold boot, I can log in with a fingerprint, but when I cannot, this always happens. It seems random, but obviously there is a reason that I haven’t tracked down yet.
This is driving me nuts to say the least. I dropped a script in my initramfs to try and find the process doing this which runs fuser and lsof in tight loops, but no results are returned.
I also tried inotifywatch, but it seems reattaching to the process is required to get the results and running under a screen does not allow me to re-attach after the pivot root for some reason.
Does anyone know of a good way to monitor this file and get the process causing the mayhem on my system that I am overlooking?
TiA!
-Greg
You can monitor access to the file with audit like this:
FILE="${HOME}/.local/share/keyrings/user.keystore"
sudo dnf -y install audit
sudo systemctl start auditd.service
sudo tee /etc/audit/rules.d/custom.rules << EOF > /dev/null
-d never,task
-w ${FILE} -k ${FILE##*/}
EOF
sudo augenrules --check
sudo augenrules --load
touch ${FILE}
journalctl --no-pager -b -g ${FILE##*/} _TRANSPORT=audit
But that file is not supposed to be accessed directly.
It should be managed by gnome-keyring-daemon accepting requests from other apps over RPC/dbus.
To be fair, this is not really a Fedora specific issue, so you’d best ask the GNOME devs:
I understand it is not Fedora specific, and I do thank you for the troubleshooting tips for sure. Our company uses RHEL for it’s offerings, so I use Fedora (for a long time) to know what is coming down the pipe.
I appreciate your help though - I would have never thought to use audit!
I agree it should only be managed by Gnome, but something is definitely locking my keyring back as well as adding that file back in place - it is a strange one to say the least - have not had this issue ever since Gnome 3.x came out. I even removed .local, .cache and .config yesterday and the issue persisted.
I’ll post back what I (eventually) find in hopes to help others in the future possibly.
-Greg
Well,
I am starting to think this device is compromised somehow. The journal is being cleared at every boot, and I made the auditd changes you suggested 2 hours ago, yet, the journal for that entry is being cleared @ each reboot.
[greg@carbonx1-gen10 ~]$ journalctl --no-pager -b -g keyrings_audit
Mar 13 13:57:40 carbonx1-gen10 audit: CONFIG_CHANGE auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="keyrings_audit" list=4 res=1
Mar 13 13:57:49 carbonx1-gen10 audit[1849]: SYSCALL arch=c000003e syscall=257 success=yes exit=10 a0=ffffff9c a1=55669c7f3a70 a2=40 a3=180 items=2 ppid=1 pid=1849 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="gnome-keyring-d" exe="/usr/bin/gnome-keyring-daemon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="keyrings_audit"
[greg@carbonx1-gen10 ~]$ ll .local/share/keyrings/
total 16,384
drwxr-xr-x. 2 greg greg 48 Mar 13 13:57 .
drwx------. 29 greg greg 4,096 Mar 13 11:11 ..
-rw-------. 1 greg greg 6,920 Mar 13 13:55 login.keyring
-rw-------. 1 greg greg 207 Mar 13 13:55 user.keystore
This log was 3 minutes ago… The user.keystore was “re-created” and it was 2 minutes before any journal entry was logged. The journal starts @ 13:09, yet the audit entries for keyring get started over at each restart… Very odd!
Also, I am having some strange fprintd issues at the same time - if GDM does not have the fprint option available (cold reboot randomness), I can press ESC and hit my user again which causes the option to show up, but for the entire user session fprins do not work. I have to restart the computer, not just log out, etc…
This is crazy to say the least :-/
-Greg
This file is created for me at login by gnome-keyring-daemon and it is basically empty.
I can understand an empty file, but like I said mine is populated with an expired MS cert. Other oddities like the fprint settings , etc I mentioned are definitely strange here!
I’ll keep digging - thanks for the helpful ideas.
Check the output:
p11-kit list-modules; p11tool --list-tokens
By default, the tokens are write-protected.
Perhaps you have a writable one.
This is all new to me :-/ I have completely re-installed from scratch f37 using an entirely different user with no files restored. I have only added evolution and evolution-ews for email and seahorse to view the keyrings. I am seeing the same behavior. The MS Root Authority Cert persists, although upon closer inspection, it is not in the user.keystore file and I do not know where it keeps coming from. The cert is:
Microsoft Root Authority
Identity: Microsoft Root Authority
Verified by: Microsoft Root Authority
Expires: 12/31/2020
Subject Name
OU (Organizational Unit): Copyright (c) 1997 Microsoft Corp.
OU (Organizational Unit): Microsoft Corporation
CN (Common Name): Microsoft Root Authority
Issuer Name
OU (Organizational Unit): Copyright (c) 1997 Microsoft Corp.
OU (Organizational Unit): Microsoft Corporation
CN (Common Name): Microsoft Root Authority
Issued Certificate
Version: 3
Serial Number: 00 C1 00 8B 3C 3C 88 11 D1 3E F6 63 EC DF 40
Not Valid Before: 1997-01-10
Not Valid After: 2020-12-31
Certificate Fingerprints
SHA1: A4 34 89 15 9A 52 0F 0D 93 D0 32 CC AF 37 E7 FE 20 A8 B4 19
MD5: 2A 95 4E CA 79 B2 87 45 73 D9 2D 90 BA F9 9F B6
Public Key Info
Key Algorithm: RSA
Key Parameters: 05 00
Key Size: 2048
Key SHA1 Fingerprint: 4A 5C 75 22 AA 46 BF A4 08 9D 39 97 4E BD B4 A3 60 F7 A0 1D
Public Key: 30 82 01 0A 02 82 01 01 00 A9 02 BD C1 70 E6 3B F2 4E 1B 28 9F 97 78 5E 30 EA A2 A9 8D 25 5F F8 FE 95 4C A3 B7 FE 9D A2 20 3E 7C 51 A2 9B A2 8F 60 32 6B D1 42 64 79 EE AC 76 C9 54 DA F2 EB 9C 86 1C 8F 9F 84 66 B3 C5 6B 7A 62 23 D6 1D 3C DE 0F 01 92 E8 96 C4 BF 2D 66 9A 9A 68 26 99 D0 3A 2C BF 0C B5 58 26 C1 46 E7 0A 3E 38 96 2C A9 28 39 A8 EC 49 83 42 E3 84 0F BB 9A 6C 55 61 AC 82 7C A1 60 2D 77 4C E9 99 B4 64 3B 9A 50 1C 31 08 24 14 9F A9 E7 91 2B 18 E6 3D 98 63 14 60 58 05 65 9F 1D 37 52 87 F7 A7 EF 94 02 C6 1B D3 BF 55 45 B3 89 80 BF 3A EC 54 94 4E AE FD A7 7A 6D 74 4E AF 18 CC 96 09 28 21 00 57 90 60 69 37 BB 4B 12 07 3C 56 FF 5B FB A4 66 0A 08 A6 D2 81 56 57 EF B6 3B 5E 16 81 77 04 DA F6 BE AE 80 95 FE B0 CD 7F D6 A7 1A 72 5C 3C CA BC F0 08 A3 22 30 B3 06 85 C9 B3 20 77 13 85 DF 02 03 01 00 01
Extension
Identifier: 2.5.29.1
Value: 30 81 97 80 10 5B D0 70 EF 69 72 9E 23 51 7E 14 B2 4D 8E FF CB A1 72 30 70 31 2B 30 29 06 03 55 04 0B 13 22 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 31 39 39 37 20 4D 69 63 72 6F 73 6F 66 74 20 43 6F 72 70 2E 31 1E 30 1C 06 03 55 04 0B 13 15 4D 69 63 72 6F 73 6F 66 74 20 43 6F 72 70 6F 72 61 74 69 6F 6E 31 21 30 1F 06 03 55 04 03 13 18 4D 69 63 72 6F 73 6F 66 74 20 52 6F 6F 74 20 41 75 74 68 6F 72 69 74 79 82 0F 00 C1 00 8B 3C 3C 88 11 D1 3E F6 63 EC DF 40
Critical: No
Signature
Signature Algorithm: MD5 with RSA
Signature Parameters: 05 00
Signature: 95 E8 0B C0 8D F3 97 18 35 ED B8 01 24 D8 77 11 F3 5C 60 32 9F 9E 0B CB 3E 05 91 88 8F C9 3A E6 21 F2 F0 57 93 2C B5 A0 47 C8 62 EF FC D7 CC 3B 3B 5A A9 36 54 69 FE 24 6D 3F C9 CC AA DE 05 7C DD 31 8D 3D 9F 10 70 6A BB FE 12 4F 18 69 C0 FC D0 43 E3 11 5A 20 4F EA 62 7B AF AA 19 C8 2B 37 25 2D BE 65 A1 12 8A 25 0F 63 A3 F7 54 1C F9 21 C9 D6 15 F3 52 AC 6E 43 32 07 FD 82 17 F8 E5 67 6C 0D 51 F6 BD F1 52 C7 BD E7 C4 30 FC 20 31 09 88 1D 95 29 1A 4D D5 1D 02 A5 F1 80 E0 03 B4 5B F4 B1 DD C8 57 EE 65 49 C7 52 54 B6 B4 03 28 12 FF 90 D6 F0 08 8F 7E B8 97 C5 AB 37 2C E4 7A E4 A8 77 E3 76 A0 00 D0 6A 3F C1 D2 36 8A E0 41 12 A8 35 6A 1B 6A DB 35 E1 D4 1C 04 E4 A8 45 04 C8 5A 33 38 6E 4D 1C 0D 62 B7 0A A2 8C D3 D5 54 3F 46 CD 1C 55 A6 70 DB 12 3A 87 93 75 9F A7 D2 A0
Stuff you asked for:
[greg@carbon-x1-g10 ~]$ p11-kit list-modules; p11tool --list-tokens
p11-kit-trust: p11-kit-trust.so
library-description: PKCS#11 Kit Trust Module
library-manufacturer: PKCS#11 Kit
library-version: 0.24
token: System Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.24
flags:
write-protected
token-initialized
token: Default Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.24
flags:
write-protected
token-initialized
opensc: opensc-pkcs11.so
library-description: OpenSC smartcard framework
library-manufacturer: OpenSC Project
library-version: 0.23
Token 0:
URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Label: System Trust
Type: Trust module
Flags: uPIN uninitialized
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so
Token 1:
URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust
Label: Default Trust
Type: Trust module
Flags: uPIN uninitialized
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so
Just wanted to pitch in, that i have exactly the same issue as Greg. This post made me look for it, and it’s on my F37 main install, a F38 VM installation made today, and on a external usb F37 install.
It’s the exact same Microsoft certificate as the one Greg posted, my output of p11-kit list-modules; p11tool --list-tokens is also the exact same.
Installed seahorse to check, when i open it the certificate is not shown, but when i lock the keyring, the certificate show up under Certificates Default Trust. If i unlocking the keyring again, close and re-open seahorse, it is again not shown under Default Trust.
Can this have something to do with the hardware used, or is that not possible? While digging around i saw something related to smartcard, and my hardware have a 4-in-1 Card Reader.
Actually this certificate is part of the Default Trust PKCS#11 token provided by the ca-certificates package and matches the source on the Fedora package server:
curl -s -L https://src.fedoraproject.org/rpms\
/ca-certificates/raw/rawhide/f/certdata.txt \
| grep -C 8 -e a4:34:89:15:9a:52:0f:0d:93\
:d0:32:cc:af:37:e7:fe:20:a8:b4:19
This is an old Microsoft certificate for code signing, and it has specific legacy attributes that make it stand out, but apart from that, there is nothing wrong.
Thank you for the clarification, good to know that there is nothing wrong.
Yes - that was my mistake. It was 2020 even though I opened with 2014 - something from that year was in my mind I guess.
After some reading on gnutls and also that specific cert and it’s needs in a Windows environment for MS OSes to actually run - expired or not, I guess GNU is shipping it for some reason or another. Just not sure why they would enter it as a “Personal” certificate that cannot be removed in any way shape or form and not add it as a System Certificate in /etc with all of the others.
I think I am going to have to go back to F36 anyway due to the fprintd issues in f37, but that is for another day. ThaNks for all of your time investigating this with me!
The certificate managing apps tend to separate certificates based on their attributes including Key Usage and Extended Key Usage, but they are subjected to specific RFCs which tend to change over time with appearance of new standards and deprecation of old ones, and a certificate issued 25+ years ago may not be the best example of perfectly selected roles.
Thanks all for this discussion, little info on the web about this. I have just noted the same (also first time I mess around with seahorse).
For me, the expired MS cert appears when I right click my Login keyring, select “change password” and then hit escape. Then the cert appears. I close seahorse, re open and it’s gone. I redo change password + esc and it’s back. Just tested in a fresh VM with the same behaviour.
There is a bug report that seems related (and perhaps in the process of being fixed) there: Empty (null) personal certificates in fresh install (#251) · Issues · GNOME / Passwords and Secrets · GitLab
I don’t have a gitlab account to post on that bug report, but perhaps someone else does.