Red Hat Bugzilla – Bug 502302
selinux avc on vpnc connect
Last modified: 2010-09-28 01:38:01 EDT
Description of problem: Summary: I get the following when I use vpnc to connect to the RH vpn from a RHEL 5.2 Server VM. I get a vpn connection ok, but I don't know if it's a "complete" connection. i.e., is this avc preventing a fully operational vpn connection? SELinux is preventing ip (ifconfig_t) "read write" to socket (vpnc_t). Detailed Description: SELinux denied access requested by ip. It is not expected that this access is required by ip and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context user_u:system_r:ifconfig_t Target Context user_u:system_r:vpnc_t Target Objects socket [ udp_socket ] Source ifconfig Source Path /sbin/ifconfig Port <Unknown> Host alexandria.australia.com Source RPM Packages iproute-2.6.18-9.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-203.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name alexandria.australia.com Platform Linux alexandria.australia.com 2.6.18-128.1.10.el5 #1 SMP Wed Apr 29 13:55:17 EDT 2009 i686 i686 Alert Count 90 First Seen Thu 12 Jun 2008 05:11:42 AM EST Last Seen Sun 24 May 2009 08:14:26 PM EST Local ID c6eb2189-1084-4f88-a2c3-5920cfb2480a Line Numbers Raw Audit Messages host=alexandria.australia.com type=AVC msg=audit(1243160066.982:107): avc: denied { read write } for pid=3138 comm="ip" path="socket:[18966]" dev=sockfs ino=18966 scontext=user_u:system_r:ifconfig_t:s0 tcontext=user_u:system_r:vpnc_t:s0 tclass=udp_socket host=alexandria.australia.com type=SYSCALL msg=audit(1243160066.982:107): arch=40000003 syscall=11 success=yes exit=0 a0=91d72c0 a1=91d7168 a2=91c94a8 a3=0 items=0 ppid=3116 pid=3138 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="ip" exe="/sbin/ip" subj=user_u:system_r:ifconfig_t:s0 key=(null) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is a leaked file descriptor in vpnc. vpnc should call fcntl(socket, F_SETFD, FD_CLOEXEC) On all open file descriptors before executing any jobs. You can allow this for now by executing # grep vpnc /var/log/audit/audit.log | audit2allow -M myvpnc # semodule -i myvpnc.pp This will build a custom policy module and install it allowing the access, and eliminate the AVC.
Thanks Dan. New module works fine. David
Hi, https://admin.fedoraproject.org/updates/vpnc-0.5.3-6.el5 Can you test this and let me know if it clears the selinux errors.
I'd like to, but... - I no longer have RHEL 5.2 installed, only 5.4 - I checked the epel repo and there doesn't seem to be any updates there - The vpnc build that I have is 0.4.0-2.el5 (quite old) Any other volunteers for testing (me not being very technical)? Sorry.
Hi David, You dont need 5.2 , 5.4 will do just fine. You can go the link i posted and download the rpm and test if you want :) Thanks.
David, For reference, at that point the update was in the testing repository. "yum update --enablerepo=epel-testing vpnc" would have allowed you to install the updated version. vpnc-0.5.3-6.el5 is now in the stable repository, any chance you could confirm that this bug has been fixed?
Hi Mark I'm currently using: vpnc-0.5.3-8.el5 rhel 5.4 with 2.6.18-164.11.1.el5 and I'm not getting any of the avc denials I was seeing before. (This is on a physical box, btw, not the VM I was using before.) thanks
Thanks David, in that case I'll close this ticket off. The VM/Physical box shouldn't make a difference if it's the guest that gave the AVC last time.