Red Hat Bugzilla – Bug 816251
SELinux blocks /bin/ping from read access to dhclient.suspend file on resume from hibernate
Last modified: 2013-02-21 03:35:20 EST
Description of problem: SELinux is preventing /bin/ping from read access on the file /var/run/pm-utils/network/dhclient.suspend. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that ping should be allowed read access on the dhclient.suspend file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ping /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ping_t:s0-s0:c0.c1023 Target Context system_u:object_r:hald_var_run_t:s0 Target Objects /var/run/pm-utils/network/dhclient.suspend [ file ] Source ping Source Path /bin/ping Port <Unknown> Host zorak.local Source RPM Packages iputils-20071127-16.el6 Target RPM Packages Policy RPM selinux-policy-3.7.19-126.el6_2.10 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name zorak.local Platform Linux zorak.local 2.6.32-220.7.1.el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 Alert Count 7 First Seen Wed 14 Mar 2012 09:10:20 PM CDT Last Seen Wed 25 Apr 2012 08:37:24 AM CDT Local ID 37efa722-4372-4d8a-af8e-7adeb58355a2 Raw Audit Messages type=AVC msg=audit(1335361044.213:3396): avc: denied { read } for pid=19326 comm="ping" path="/var/run/pm-utils/network/dhclient.suspend" dev=dm-0 ino=1966089 scontext=system_u:system_r:ping_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1335361044.213:3396): arch=x86_64 syscall=execve success=yes exit=0 a0=12d8a90 a1=1300aa0 a2=1307b70 a3=50 items=0 ppid=19314 pid=19326 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ping exe=/bin/ping subj=system_u:system_r:ping_t:s0-s0:c0.c1023 key=(null) Hash: ping,ping_t,hald_var_run_t,file,read audit2allow #============= ping_t ============== allow ping_t hald_var_run_t:file read; audit2allow -R #============= ping_t ============== allow ping_t hald_var_run_t:file read; Version-Release number of selected component (if applicable): [root@zorak tmp]# rpm -q selinux-policy selinux-policy-3.7.19-126.el6_2.10.noarch How reproducible: All the time. Steps to Reproduce: 1. Hibernate 2. Resume 3. Get AVC msg (after a few moments) Actual results: Get the AVC message Expected results: No errors, network resumes Additional info:
This is a leaked file descriptor but should be dontaudited.
In the meantime, any objection to me generating the local policy to avoid the message? I can unload it to collect any additional data or to reproduce if needed. Something does eventually clean up the file (maybe dhclient itself after resuming?). By the time I get a shell opened and try to to look at dhclient.suspend, it is gone.
After my previous post, I realized I likely misunderstood Dan's comment #2. So, to clarify: - Rather than an using an "allow ...." rule, the correct way is to create a "dontaudit ..." rule. - The "leaked file descriptor" indicates that it is not selinux misbehaving, but rather revealing poor file behaviour of some other application. (I suspected this was the case.)
After some digging to find out how to create a local.pp policy package to avoid the error and AVC message on my system, here is what I did. Please advise if this is not correct or is likely to cause other undesired side-effects. I created a local.pp policy based on a local.te file containing: module local 1.0; require { type hald_var_run_t; type ping_t; class file read; } #============= ping_t ============== dontaudit ping_t hald_var_run_t:file read; It also appears that an selinux "interface" already exists to handle this scenario. Would this short form also achieve the same result?: module local 1.1; require { type ping_t; } #============= ping_t ============== hal_dontaudit_read_pid_files(ping_t)
Yes, we need to add hal_dontaudit_read_pid_files(ping_t)
I don't really think this matters. dontaudit would be better but this access only allows ping to read a leaked file from hald, which probably contains its pid.
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. http://rhn.redhat.com/errata/RHBA-2013-0314.html