Hide Forgot
Description of problem: I tried to connect to a vpnc managed vpn through the network manager "applet" under gnome-3 SELinux is preventing /usr/sbin/vpnc from 'search' accesses on the directory vpnc. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that vpnc should be allowed search access on the vpnc directory 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 vpnc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:vpnc_var_run_t:s0 Target Objects vpnc [ dir ] Source vpnc Source Path /usr/sbin/vpnc Port <Unknown> Host (removed) Source RPM Packages vpnc-0.5.3-18.svn457.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-72.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.0-0.rc6.git2.1.fc20.x86_64 #1 SMP Thu Aug 22 21:36:09 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-08-25 11:10:40 CEST Last Seen 2013-08-25 11:10:40 CEST Local ID 482e64ab-c909-4682-97a1-789c00afbcbf Raw Audit Messages type=AVC msg=audit(1377421840.2:450): avc: denied { search } for pid=2689 comm="vpnc" name="vpnc" dev="tmpfs" ino=14623 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:vpnc_var_run_t:s0 tclass=dir type=SYSCALL msg=audit(1377421840.2:450): arch=x86_64 syscall=open success=no exit=EACCES a0=7f822bff8b17 a1=241 a2=1b6 a3=7fff7d8c1ac0 items=0 ppid=2678 pid=2689 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=vpnc exe=/usr/sbin/vpnc subj=system_u:system_r:NetworkManager_t:s0 key=(null) Hash: vpnc,NetworkManager_t,vpnc_var_run_t,dir,search Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.11.0-0.rc6.git2.1.fc20.x86_64 type: libreport
This is with a fully up2date F-20 system.
I'm running in permissive mode for now, and this has yielded me a second denial: Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:vpnc_var_run_t:s0 Target Objects /run/vpnc/pid [ file ] Source vpnc Source Path /usr/sbin/vpnc Port <Unknown> Host (removed) Source RPM Packages vpnc-0.5.3-18.svn457.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-72.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.11.0-0.rc6.git4.1.fc20.x86_64 #1 SMP Fri Aug 23 19:58:46 UTC 2013 x86_64 x86_64 Alert Count 2 First Seen 2013-08-25 12:43:58 CEST Last Seen 2013-08-26 08:00:36 CEST Local ID 65529c03-66cc-4028-987b-05efc4d807c9 Raw Audit Messages type=AVC msg=audit(1377496836.70:448): avc: denied { getattr } for pid=2817 comm="vpnc" path="/run/vpnc/pid" dev="tmpfs" ino=39728 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:vpnc_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1377496836.70:448): arch=x86_64 syscall=fstat success=yes exit=0 a0=7 a1=7fff6ee418a0 a2=7fff6ee418a0 a3=0 items=0 ppid=2808 pid=2817 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=vpnc exe=/usr/sbin/vpnc subj=system_u:system_r:NetworkManager_t:s0 key=(null) Hash: vpnc,NetworkManager_t,vpnc_var_run_t,file,getattr
ls -lZ /usr/sbin/vpnc -rwxr-xr-x. root root system_u:object_r:vpnc_exec_t:s0 /usr/sbin/vpnc It looks to me like NetworkManager_t did not transition to vpnc_t like it should have. Is vpnc labeled correctly?
Could you try to run # restorecon -R -v /usr/sbin
(In reply to Miroslav Grepl from comment #4) > Could you try to run > > # restorecon -R -v /usr/sbin Ah, yes that fixes a lot of labels. Seems somehow the re-labelling when doing a yum distro-sync from F-19 -> F-20 did not happen properly. I should have known better and done a "touch /.autorelabel && reboot" when I was having selinux troubles after the upgrade, sorry about the noise.
Well this should not happen. It looks like some kind of yum/fedup/rpm bug which is not putting labels down properly.
(In reply to Daniel Walsh from comment #6) > Well this should not happen. It looks like some kind of yum/fedup/rpm bug > which is not putting labels down properly. I agree :) Note fedup was not involved, I basically followed the steps outlined here: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum
Not sure if this is a yum or rpm problem. Seems like rpm labeling is being turned off.
Hard to say for sure with this info, but my guess is that this is simply due to much of the distro-sync transaction occurring with the F19 selinux policy in place. Rpm does reload the contexts if the policy changes mid-transaction but it does not relabel the files installed earlier in the transaction.
For the reasons Panu stated in comment 9, I am closing this.