Description of problem: * the beah policy module needs to be improved Version-Release number of selected component (if applicable): beah-0.7.9-2.el7.noarch How reproducible: * always Steps to Reproduce: 1. clone this job https://beaker.engineering.redhat.com/jobs/1386417 2. log into the machine before /distribution/errata/prepare starts 3. while true ; do sleep 1 ; ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i ; done Actual results: ---- type=PROCTITLE msg=audit(06/29/2016 08:49:15.927:118) : proctitle=runcon -u unconfined_u -r unconfined_r -t unconfined_t -l s0-s0:c0.c1023 -- /var/lib/beah/tortilla/wrappers.d/initgroups type=SYSCALL msg=audit(06/29/2016 08:49:15.927:118) : arch=aarch64 syscall=execve success=no exit=-13(Permission denied) a0=0x3ffdde3f67a a1=0x3ffdde3a338 a2=0x3ffdde3a348 a3=0x2f items=0 ppid=25118 pid=25162 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=runcon exe=/usr/bin/runcon subj=system_u:system_r:unconfined_service_t:s0 key=(null) type=AVC msg=audit(06/29/2016 08:49:15.927:118) : avc: denied { entrypoint } for pid=25162 comm=runcon path=/var/lib/beah/tortilla/wrappers.d/initgroups dev="dm-0" ino=135546556 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 ---- Expected results: * no SELinux denials
Your job installed selinux-policy-3.13.1-82.el7, it's possible that something has changed in the policy to cause this new denial.
selinux-policy together with other SELinux related packages were rebased in RHEL-7.3.
The beah policy is fine. The problem is after the yum transaction which upgrades selinux-policy, /var/lib/beah/tortilla/wrappers.d/unconfined gets mislabelled. It ends up as var_lib_t, but it should be unconfined_exec_t. Doing restorecon -R /var/lib/beah after the yum upgrade works around the problem. Seems like it must be a bug with the fixfiles invocation in selinux-policy-targeted %post scriptlet.
I manually tested upgrading from selinux-policy-targeted-3.13.1-60.el7.noarch to selinux-policy-targeted-3.13.1-82.el7.noarch by hand with rpm --noscripts, and confirmed that /var/lib/beah/tortilla/wrappers.d/unconfined remains correctly labelled unconfined_exec_t after everything is installed. To simulate what the fixfiles step in the selinux-policy-targeted %post scriptlet would do, I saved /etc/selinux/targeted/contexts/files/file_contexts as file_contexts.pre before the upgrade, and after the upgrade I ran: fixfiles -v -C file_contexts.pre check and it does indeed show (amongst a whole pile of other context changes): /sbin/restorecon reset /var/lib/beah/tortilla/wrappers.d/unconfined context system_u:object_r:unconfined_exec_t:s0->system_u:object_r:var_lib_t:s0
(In reply to Dan Callaghan from comment #4) > I manually tested upgrading from > selinux-policy-targeted-3.13.1-60.el7.noarch to > selinux-policy-targeted-3.13.1-82.el7.noarch by hand with rpm --noscripts, Not actually sure if this test was valid since it means I also missed the semanage -R step to reload the policy. I somehow ended up with the beah policy module not loaded. Need to test further.
So the fixfiles invocation itself isn't really defective, but it's setting the wrong context on /var/lib/beah/tortilla/wrappers.d/unconfined because at the time fixfiles runs in the yum transaction, the beah policy module is not loaded. However at the end of the transaction the beah policy module *is* magically loaded again somehow. Which is why running restorecon afterwards is a valid workaround. I'm still not sure why the beah module is being unloaded and then loaded again. I wonder if it's something to do with the shuffling from /etc/selinux/targeted/modules/active/modules/ to /etc/selinux/targeted/active/modules/400/. But I can't find where that shuffling is actually being handled...
I'm convinced this is a real SELinux bug which will need to be fixed in RHEL7.3 since it will affect any installations using custom selinux policy modules, it's nothing specific to Beaker. So I've filed bug 1361000 against RHEL7 selinux-policy.
(In reply to Dan Callaghan from comment #6) > However at the end of the transaction the beah policy module *is* magically > loaded again somehow. The magic was a trigger, I didn't notice it because I forgot triggers exist and was just looking at rpm -q --scripts.
Closing this as NOTABUG since I don't think there is anything else we can do on the beah side about it, it needs to be fixed in the selinux-policy packaging (bug 1361000). As noted in comment 3 above, a workaround is to run: restorecon -R /var/lib/beah, after upgrading selinux-policy higher than -66 (and before the next task starts).