Description of problem: I don't know if this is a Canna bug, a shadow-utils bug, or an selinux-policy bug. Pardon me if I've filed it under the wrong component. The %pre script in Canna searches /etc/passwd for a 'canna' entry and calls userdel if it finds one. This happens on a Canna upgrade. When userdel is invoked, two AVC denials are issued. The setroubleshoot browser reports both as denials against "$SOURCE_NAME", indicating that there is an unexpanded macro somewhere. Summary: SELinux prevented $SOURCE_NAME from reading from the urandom device. Raw audit messages: avc: denied { getattr } for comm="userdel" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/userdel" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="urandom" path="/dev/urandom" pid=1006 scontext=user_u:system_r:useradd_t:s0 sgid=0 subj=user_u:system_r:useradd_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:urandom_device_t:s0 tty=pts1 uid=0 Summary: SELinux prevented $SOURCE_NAME from reading from the urandom device. Raw audit messages: avc: denied { read } for comm="userdel" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/userdel" exit=13 fsgid=0 fsuid=0 gid=0 items=0 name="urandom" pid=1006 scontext=user_u:system_r:useradd_t:s0 sgid=0 subj=user_u:system_r:useradd_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:urandom_device_t:s0 tty=pts1 uid=0 Version-Release number of selected component (if applicable): Canna-3.7p3-18.fc6 shadow-utils-4.0.17-12.fc6 selinux-policy-2.4.6-46.fc6 How reproducible: Always Steps to Reproduce: 1. Install an older version of Canna 2. Upgrade to the latest version Actual results: The avc denials listed above are issued, with setroubleshoot reporting them as denials against $SOURCE_NAME. Expected results: If the denials are proper, they should be reported against userdel, or possibly against Canna. If they are not, they should not be issued. Additional info: I am using selinux-policy-targeted in permissive mode.
This is strange. By any chance were you running ProPolice/SSP stack smashing protection As the troubleshooter suggested? I will fix the troubleshooter to report the correct path.
I thought ProPolice was a compile-time option. I'm using the unmodified upstream RPM, if that's what you mean. Is there some kind of runtime stack protection option? If so, I know nothing about it and have not turned it on for my system.
I have no idea, I was just reading the troubleshoot explanation. I can think of no reason why userdel would need access to the /dev/urandom.
Me neither. However, I see this in /usr/lib/rpm/redhat/macros: %__global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 which seems to mean that EVERY Fedora package is built with ProPolice/SSP stack smashing protection.
I am just going to close this as unreproducable.