Created attachment 844619 [details] AVC spew from journal Description of problem: Recent Rawhide kernels are producing AVCs for key system components for execmem/execstack. Has there been a change in how the kernel is handling this.... ? Attaching spew from journal. For example: #============= abrt_t ============== allow abrt_t self:process { execstack execmem }; #============= auditd_t ============== allow auditd_t self:process { execstack execmem }; #============= cupsd_t ============== allow cupsd_t self:process { execstack execmem }; #============= devicekit_power_t ============== allow devicekit_power_t self:process { execstack execmem }; #============= rpcbind_t ============== allow rpcbind_t self:process { execstack execmem }; #============= sshd_t ============== allow sshd_t self:process { execstack execmem }; #============= telepathy_msn_t ============== allow telepathy_msn_t self:process { execstack execmem }; Version-Release number of selected component (if applicable): How reproducible: Every boot Steps to Reproduce: 1. boot 2. 3. Actual results: Expected results: Additional info:
Not sure if this is a kernel issue or a glibc/gcc issue. Lots of domains in Rawhide now need execmem and execstack to be allowed to run.
Could be caused by kerberos libraries? # find /usr/lib64 -name libk5\* -exec execstack {} \; X /usr/lib64/libk5crypto.so.3 X /usr/lib64/libk5crypto.so.3.1 X /usr/lib64/libk5crypto.so
On the glibc side we haven't purposely changed anything that should impact execmem/execstack.
krb5-1.12-6.fc21 added a buildrequires on the relevant arches which enabled use of assembly to get AES-NI support. I'm untagging it now.
*** This bug has been marked as a duplicate of bug 1045699 ***