When implementing bug 1496560, applications that use NSS defaults will create differently named files. Today, NSS by default will create files named cert8.db, key3.db, secmod.db After the change, it will use files named cert9.dn, key4.db, pkcs11.txt Thanks to Hubert, who discovered that mod_nss apparently needs an adjustment to selinux rules. I suggest to search the existing selinux policies, and for each application that is allowed to access the old filenames, please allow the new filenames, too. I suggest to add (not replace), in case an application needs to explicitly choose to continue to use the old filenames by configuration.
Kai, Could you provide some list of renamed files? Thanks, Lukas.
Lukas, the information from my initial comment is all I have. Could you just search through the lists of files your policy already has? In my opinion, you shouldn't wait for someone to report these files. I think it would be better if you're proactive and handle all existing scenarios that match my description.
FYI, I'd like to make the change to NSS next week.
Kai, Are you able to create scratch build and test it with current selinux-policy in rawhide and attach here AVCs? Thanks, Lukas.
(In reply to Lukas Vrabec from comment #4) > Are you able to create scratch build and test it with current selinux-policy > in rawhide and attach here AVCs? I cannot provide any Fedora failures yet. Why can't we simply search the existing policies for these filenames, as I suggested in my initial comment?
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I think this can probably be closed. The issue was related to migration from a DBM to sqlite NSS database(s). mod_nss will detect what is there and not try to automatically migrate so I don't think this will every cause SELinux issues. I don't recall any user reports of issues in the F28 life cycle.
DBM format will be deprecated in NSS and it will cause NSS to automatically migrate the files to the new format, so no, SELinux needs to be updated
Hubert, What exactly should be fixed on SELinux side? If you point me to some SELinux denials that would be great. Thanks, Lukas.
I don't have SELinux denials, but I can tell you that all SELinux references to files cert8.db, key3.db and secmod.db will need to be updated to include cert9.db, key4.db and pkcs11.txt, in addition. Given the bug is still in ASSIGNED, my understanding is that it still hasn't happened. If this has already happened, this can be closed and sorry for the noise.
Hi Hubert, Using latest Fedora Rawhide compose I see files cert9.db, pkcs11.txt and key4.db in directory "/etc/pki/nssdb": # ls -Z /etc/pki/nssdb/ system_u:object_r:cert_t:s0 cert8.db system_u:object_r:cert_t:s0 key4.db system_u:object_r:cert_t:s0 cert9.db system_u:object_r:cert_t:s0 pkcs11.txt system_u:object_r:cert_t:s0 key3.db system_u:object_r:cert_t:s0 secmod.db Labels for files you mentioned is cert_t, which is correct from my POV. I think this issue is already fixed.
and all applications that use nss have permission to *write* cert_t files?
Hubert, If I provide scratch build, will you test it with some common apps using nss? Thanks, Lukas.
sorry, no, I won't
After discussion with Hubert, we agreed to close this BZ because we don't have real example to test it. If anyone hit this issue with reproducer feel free to re-open this bug.