SELinux is preventing ns-slapd from map access on the file /etc/pkcs11/modules/softhsm2.module. ***** Plugin restorecon (88.2 confidence) suggests ************************ If you want to fix the label. /etc/pkcs11/modules/softhsm2.module default label should be pkcs11_modules_conf_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /etc/pkcs11/modules/softhsm2.module ***** Plugin catchall_boolean (7.51 confidence) suggests ****************** If you want to allow domain to can mmap files Then you must tell SELinux about this by enabling the 'domain_can_mmap_files' boolean. Do setsebool -P domain_can_mmap_files 1 ***** Plugin catchall_labels (4.88 confidence) suggests ******************* If you want to allow ns-slapd to have map access on the softhsm2.module file Then you need to change the label on /etc/pkcs11/modules/softhsm2.module Do # semanage fcontext -a -t FILE_TYPE '/etc/pkcs11/modules/softhsm2.module' where FILE_TYPE is one of the following: abrt_helper_exec_t, chkpwd_exec_t, dirsrv_exec_t, dirsrv_tmp_t, dirsrv_tmpfs_t, dirsrv_var_lib_t, dirsrv_var_run_t, file_context_t, fonts_cache_t, fonts_t, ld_so_cache_t, ld_so_t, lib_t, locale_t, nscd_var_run_t, pam_timestamp_exec_t, passwd_file_t, pkcs11_modules_conf_t, prelink_exec_t, security_t, sssd_public_t, textrel_shlib_t, updpwd_exec_t, usr_t. Then execute: restorecon -v '/etc/pkcs11/modules/softhsm2.module' ***** Plugin catchall (1.37 confidence) suggests ************************** If you believe that ns-slapd should be allowed map access on the softhsm2.module file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'ns-slapd' --raw | audit2allow -M my-nsslapd # semodule -X 300 -i my-nsslapd.pp Additional Information: Source Context system_u:system_r:dirsrv_t:s0 Target Context unconfined_u:object_r:etc_t:s0 Target Objects /etc/pkcs11/modules/softhsm2.module [ file ] Source ns-slapd Source Path ns-slapd Port <Unknown> Host dell-r730-002-guest21.example.test Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-35.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name dell-r730-002-guest21.example.test Platform Linux dell-r730-002-guest21.example.test 5.0.16-300.fc30.x86_64 #1 SMP Tue May 14 19:33:09 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-05-15 10:17:38 EDT Last Seen 2019-05-15 10:17:38 EDT Local ID 06233c6e-ce9f-4503-a85d-6d046b556db8 Raw Audit Messages type=AVC msg=audit(1557929858.956:295): avc: denied { map } for pid=22723 comm="ns-slapd" path="/etc/pkcs11/modules/softhsm2.module" dev="dm-0" ino=8445201 scontext=system_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0 Hash: ns-slapd,dirsrv_t,etc_t,file,map
That file is created by ipa-server but with wrong SELinux file context sh-5.0# ls -lZ /etc/pkcs11/modules/softhsm2.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 94 May 15 10:17 /etc/pkcs11/modules/softhsm2.module sh-5.0# cat /etc/pkcs11/modules/softhsm2.module # created by IPA installer module: /usr/lib64/pkcs11/libsofthsm2.so disable-in: p11-kit-proxy
BTW is there any reason why this file is not owned by any ipa* package ? %ghost should work for this case sh-5.0# rpm -qf /etc/pkcs11/modules/softhsm2.module file /etc/pkcs11/modules/softhsm2.module is not owned by any package
Lukas do you have a reproducer on this? In what context did you see see this? Upgrade, new install? Is this preventing operation or did you just notice the AVCs? Looks like commit 74e09087 didn't call restore_context() on the resulting file.
(In reply to Rob Crittenden from comment #3) > Lukas do you have a reproducer on this? In what context did you see see > this? Upgrade, new install? > install > Is this preventing operation or did you just notice the AVCs? > I have not idea what 389-ds tries to do with pkcs11/softhsm > Looks like commit 74e09087 didn't call restore_context() on the resulting > file. Exactly
(In reply to Lukas Slebodnik from comment #4) > > Is this preventing operation or did you just notice the AVCs? > > > I have not idea what 389-ds tries to do with pkcs11/softhsm I was trying to understand if this blew up the installation or if you noticed any other bad behavior to know what to expect when we try to reproduce it.
We create this file during installation to fix https://pagure.io/freeipa/issue/7810. Unfortunately, a nss update alone cannot handle that as p11-kit team is insisting to enable p11-kit-proxy globally. So the fix on our side would be to add restore_context() and be done with it, right? I think we can use the original ticket (7810) to commit the fix.
I did some investigation in the begining of June but forgot to ad comments here. It was no reproducible on rawhide. Bug was just in f30 The root of the problem was wrong SELiux file context of the directory /etc/pkcs11/modules/ and therefore all files created there inherited wrong label. I cannot reproduce it anymore. sh# matchpathcon /etc/pkcs11/modules/ /etc/pkcs11/modules system_u:object_r:pkcs11_modules_conf_t:s0 sh# ls -ldZ /etc/pkcs11/modules/ drwxr-xr-x. 2 root root system_u:object_r:pkcs11_modules_conf_t:s0 29 Aug 1 06:50 /etc/pkcs11/modules/ sh# ls -ldZ /etc/pkcs11/modules/softhsm2.module -rw-r--r--. 1 root root unconfined_u:object_r:pkcs11_modules_conf_t:s0 94 Aug 1 06:50 /etc/pkcs11/modules/softhsm2.module
openQA sees this on every run of the upgrade_server_domain_controller test for F30 updates lately, since about 4 days ago (not sure what changed then to make this start happening, probably some update that causes it was pushed stable). That test deploys a FreeIPA server on F29, then some other tests enrol as clients against it, then it is upgraded to F30 and we check that it still works (and the client tests also update to F30 and check they still work). The AVCs actually seem to be happening *during the F29 stage*: after the F30 upgrade is complete, we don't see any more. I also just checked the logs from the straight up "FreeIPA server deployment" test (no upgrade involved) for an F29 update, and indeed I see the same AVCs there (but the test doesn't show as a softfail because that test doesn't check for AVCs). So, this seems to be still a problem - and reproducible, by doing an FreeIPA server deployment - on F29.
So, looks like we need to propagate the fix that went into 4.8 into 4.7 branch as well. I added a build with this patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=37067259, however, I'm not entirely sure selinux-policy in F29 actually has all the bits we rely on. It looks like at least the selinux-policy f29 branch on github has initial file contexts.
FEDORA-2019-f3e62b292f has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f3e62b292f
Looks good - I grabbed the logs from the FreeIPA server deployment test for that update and I see no AVCs. Thanks!
freeipa-4.7.3-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f3e62b292f
freeipa-4.7.3-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.