Bug 1350957
Summary: | ipa named-pkcs11 failed to enumerate object store | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Poore <spoore> | ||||||||
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | urgent | ||||||||||
Version: | 7.3 | CC: | jgalipea, lvrabec, mgrepl, mmalik, plautrba, pspacek, pvoborni, pvrabec, rcritten, spoore, ssekidde, tdudlak | ||||||||
Target Milestone: | rc | Keywords: | Regression, TestBlocker | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | selinux-policy-3.13.1-91.el7 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2016-11-04 02:33:22 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Scott Poore
2016-06-28 20:15:02 UTC
This appears to be similar to Fedora bug #1333106 Changing component to selinux-policy. *** Bug 1353631 has been marked as a duplicate of this bug. *** *** Bug 1353631 has been marked as a duplicate of this bug. *** OK, I'm seeing IPA install and restart without failure now. I'm now seeing quite a few other AVC denials. I'll post the actual AVCs as an attachment. This is what I see from audit2allow for the failures: [root@rhel7-1 ~]# cat /var/log/audit/audit.log | audit2allow libsepol.sepol_string_to_security_class: unrecognized class (null) #============= certmonger_t ============== allow certmonger_t var_log_t:dir write; #============= ipa_dnskey_t ============== allow ipa_dnskey_t named_cache_t:dir search; allow ipa_dnskey_t proc_t:file read; #============= policykit_t ============== allow policykit_t tuned_t:(null) 0x2; #============= sssd_t ============== allow sssd_t fs_t:filesystem getattr; Created attachment 1179966 [details]
ausearch output after update
This is a listing of the AVC denials I see after ipa-server-install and ipactl stop/start.
selinux-policy-3.13.1-88.el7.noarch
ipa-server-4.4.0-2.1.el7.x86_64
Hi Lukas, I am still seeing most of the AVC denials I saw previously in the attachment. Here are a couple examples: ---- time->Mon Jul 18 08:36:13 2016 type=SYSCALL msg=audit(1468848973.979:169): arch=c000003e syscall=83 success=no exit=-13 a0=19a7140 a1=1ff a2=1 a3=7ffdfb090fd0 items=0 ppid=2689 pid=2725 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1468848973.979:169): avc: denied { write } for pid=2725 comm="dogtag-ipa-ca-r" name="log" dev="dm-0" ino=93 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir ---- time->Mon Jul 18 08:38:58 2016 type=SYSCALL msg=audit(1468849138.745:226): arch=c000003e syscall=2 success=no exit=-13 a0=7fe617122a1d a1=80000 a2=1b6 a3=24 items=0 ppid=4510 pid=4517 auid=4294967295 uid=995 gid=25 euid=995 suid=995 fsuid=995 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:ipa_dnskey_t:s0 key=(null) type=AVC msg=audit(1468849138.745:226): avc: denied { read } for pid=4517 comm="sh" name="meminfo" dev="proc" ino=4026532028 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file ---- These are occurring during ipa-server-install. And are just a couple examples of many that are like the ones from previous attachment. I'll include a new attachment showing the current ones. Can these be addressed as well? Thanks, Scott Created attachment 1181107 [details]
ausearch output after update to 89 release
These are the AVC denials I'm now seeing with this version of selinux-policy:
selinux-policy-3.13.1-89.el7.noarch
Scott, yes, it can be addressed but could you test it in permissive mode to collect all AVCs and attahc them? Then I fix policy. Thank you for testing. Created attachment 1181224 [details]
ausearch output after update to 89 release in permissive mode
This is the list of AVC denials from ipa-server-install with SELinux in permissive mode.
selinux-policy-3.13.1-90.el7.noarch Not sure why we didn't see these until now but, now I'm seeing this: [root@rhel7-4 ~]# ausearch -m avc ---- time->Tue Jul 19 08:57:06 2016 type=SYSCALL msg=audit(1468936626.889:216): arch=c000003e syscall=4 success=no exit=-2 a0=12cd0a0 a1=7ffff4ad7700 a2=7ffff4ad7700 a3=0 items=0 ppid=1 pid=4560 auid=4294967295 uid=995 gid=25 euid=995 suid=995 fsuid=995 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="ipa-dnskeysyncd" exe="/usr/bin/python2.7" subj=system_u:system_r:ipa_dnskey_t:s0 key=(null) type=AVC msg=audit(1468936626.889:216): avc: denied { search } for pid=4560 comm="ipa-dnskeysyncd" name="softhsm" dev="dm-0" ino=8415058 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir ---- time->Tue Jul 19 08:57:08 2016 type=SYSCALL msg=audit(1468936628.858:218): arch=c000003e syscall=2 success=no exit=-2 a0=4eff1c0 a1=0 a2=1b6 a3=24 items=0 ppid=1 pid=4560 auid=4294967295 uid=995 gid=25 euid=995 suid=995 fsuid=995 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="ipa-dnskeysyncd" exe="/usr/bin/python2.7" subj=system_u:system_r:ipa_dnskey_t:s0 key=(null) type=AVC msg=audit(1468936628.858:218): avc: denied { search } for pid=4560 comm="ipa-dnskeysyncd" name="softhsm" dev="dm-0" ino=8415058 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir Could you please test it in permissive mode? We need to catch all AVCs. Thank you. Hi Lukas, In my test from comment #22, that was in permissive mode: [root@rhel7-4 ~]# getenforce Permissive I'm not sure what changed that this wasn't caught before but, that's what we're seeing now. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2283.html |