Description of problem: SELinux generates a denial when shutting down a wireless i-f manually. I'm not certain wpa_supplicant is a requirement for the recipe, but I use it to supply the key for WPA2-PSK. Also I manually start (or don't start) my wireless connection rather than use NetworkManager, since I sometimes go places that send the discouragement squad after you if you're found with an emitting radio. Version-Release number of selected component (if applicable): selinux-policy-3.6.12-39.fc11.noarch How reproducible: Always Steps to Reproduce: 1. /etc/init.d/wpa_supplicant start 2. ifup wlan0 3. ifdown wlan0 Actual results: AVC denial (see below) on ifdown wlan0 Expected results: No AVC denial Additional info: node=ack607 type=AVC msg=audit(1243562288.160:26453): avc: denied { sys_ptrace } for pid=3123 comm="ps" capability=19 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=capability
Even easier than wireless: the same thing happens on wired interfaces that get their addresses via dhclient 1. ifup eth0 2. ifdown eth0 -> AVC denial
I take it everything works ok? Steve and Eric, I thought the ps command would not need sys_ptrace command any longer for looking at /proc?
Can we see the SYSCALL audit record for the same event? Access /proc/pid/mem will still trigger a ptrace check as that exposes all process memory. Other /proc/pid files though should not. kernel version?
Daniel: I had SELinux in permissive mode at first. I just tried enforcing mode. The denial doesn't show up then, so I guess there's a dontaudit preceding it. Nothing appears to break. Hmm... NOTABUG? Stephen: Here's a new wired event. node=ack607 type=AVC msg=audit(1243624750.605:16): avc: denied { sys_ptrace } for pid=2404 comm="ps" capability=19 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=capability node=ack607 type=SYSCALL msg=audit(1243624750.605:16): arch=40000003 syscall=3 success=yes exit=136 a0=5 a1=b65a20 a2=3ff a3=b659c0 items=0 ppid=2403 pid=2404 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ps" exe="/bin/ps" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) Kernel is 2.6.29.4-167.fc11.i686.PAE So is there a different bug here, or should I withdraw this report?
Replicated via: setenforce 0 autrace /usr/bin/runcon unconfined_u:system_r:dhcpc_t:s0 ps -el Then I ran the ausearch command shown by autrace, and saw that the sys_ptrace capability denial happened on an attempt to read descriptor 5, which was opened in the prior audit record and was an open of /proc/2/stat. On second thought, this is expected behavior - when trying to read a sensitive /proc/pid file of a process that has a different uid, the kernel checks CAP_SYS_PTRACE, and this triggers a SELinux sys_ptrace capability check. That didn't change. Dan, what you are thinking of is how we changed SELinux so that it doesn't apply a :process ptrace check in these cases, only a :file read check. But the sys_ptrace capability check is still triggered by the core kernel's check.
Ok so I can probably dontaudit this.
Fixed in selinux-policy-3.6.12-44.fc11.src.rpm
3.6.12-44 (or later) hasn't hit any yum repository yet, so I snagged it out of koji. Fix confirmed. I'll close this report once a package hits, well, wherever it's going to hit (updates, probably).
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
selinux-policy-3.6.12-45.fc11.noarch was available as of 16 Jun. Closing.