Description of problem: SELinux is preventing NetworkManager (NetworkManager_t) "search" to ./dhclient (dhcpc_state_t). Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.12.svn4326.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. Install VMware-Workstation 6.5 rpm 2. 3. Actual results: AVC Expected results: No AVC Additional info: Raw Audit Messages : node=valkyrie.localdomain type=AVC msg=audit(1228274374.721:13): avc: denied { search } for pid=3530 comm="NetworkManager" name="dhclient" dev=dm-0 ino=354110 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dhcpc_state_t:s0 tclass=dir node=valkyrie.localdomain type=SYSCALL msg=audit(1228274374.721:13): arch=c000003e syscall=87 success=no exit=-13 a0=2676790 a1=21d32c8 a2=31 a3=7fffc462e390 items=0 ppid=1 pid=3530 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="NetworkManager" exe="/usr/sbin/NetworkManager" subj=system_u:system_r:NetworkManager_t:s0 key=(null)
Also, selinux-policy-3.5.13-26.fc10.noarch
rpm -q selinux-policy-targeted
(In reply to comment #2) > rpm -q selinux-policy-targeted Sorry, that's what I meant to do: $ rpm -q selinux-policy-targeted selinux-policy-targeted-3.5.13-26.fc10.noarch
Something is strange here. NetworkManager is supposed to transition to dhcpc_t when running dhclient. Which would be allowed to read this dir. Is dhclient labeled correctly? ls -lZ /sbin/dhc* -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient-script -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient-script~ -rwxr-x--- root root system_u:object_r:bin_t:s0 /sbin/dhcp6c
(In reply to comment #4) > Something is strange here. > > NetworkManager is supposed to transition to dhcpc_t when running dhclient. > > Which would be allowed to read this dir. > > Is dhclient labeled correctly? > > ls -lZ /sbin/dhc* > -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient > -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient-script > -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient-script~ > -rwxr-x--- root root system_u:object_r:bin_t:s0 /sbin/dhcp6c Looks like it is: $ ls -lZ /sbin/dhc* -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient -rwxr-xr-x root root system_u:object_r:dhcpc_exec_t:s0 /sbin/dhclient-script -rwxr-x--- root root system_u:object_r:bin_t:s0 /sbin/dhcp6c
As Dan noted ... something is strange here, because this problem should be fixed in this version of the policy. Could you put output of the command: # sesearch --allow | grep NetworkManager_t | grep dhcpc_state_t My output: allow NetworkManager_t dhcpc_state_t : file { ioctl read getattr lock unlink } ; allow NetworkManager_t dhcpc_state_t : dir { ioctl write getattr lock remove_name search } ; ... or you can try to update the selinux-policy.
(In reply to comment #6) > As Dan noted ... something is strange here, because this problem should be > fixed in this version of the policy. > > Could you put output of the command: > > # sesearch --allow | grep NetworkManager_t | grep dhcpc_state_t > # sesearch --allow | grep NetworkManager_t | grep dhcpc_state_t WARNING: This policy contained disabled aliases; they have been removed. allow NetworkManager_t dhcpc_state_t : file { ioctl read getattr lock unlink } ; allow NetworkManager_t dhcpc_state_t : dir { ioctl write getattr lock remove_name search } ; > ... or you can try to update the selinux-policy. The above output is with: # rpm -q selinux-policy-targeted selinux-policy-targeted-3.5.13-34.fc10.noarch With the updated selinux-policy-targeted, I re-installed VMware-Workstation and got a different set of AVCs. The above NM ones did not occur, but these did instead: node=valkyrie.localdomain type=AVC msg=audit(1229648898.869:37): avc: denied { write } for pid=6323 comm="cupsd" path="pipe:[48890]" dev=pipefs ino=48890 scontext=unconfined_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:rpm_script_t:s0 tclass=fifo_file node=valkyrie.localdomain type=AVC msg=audit(1229648898.869:37): avc: denied { write } for pid=6323 comm="cupsd" path="pipe:[48891]" dev=pipefs ino=48891 scontext=unconfined_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:rpm_script_t:s0 tclass=fifo_file node=valkyrie.localdomain type=SYSCALL msg=audit(1229648898.869:37): arch=c000003e syscall=59 success=yes exit=0 a0=209edc0 a1=209d870 a2=209d8c0 a3=7fff21f80b50 items=0 ppid=6322 pid=6323 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="cupsd" exe="/usr/sbin/cupsd" subj=unconfined_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) So now it appears to be a cupsd issue. Strange...
Do you have a process that is running as rpm_script_t? ps -eZ | grep rpm_script_t if not, you can probably ignore these avcs since they will not happen in normal running of the system. The vmware workstation rpm probably did a service cupsd restart with the stdout set to a fifo file in the rpm. This will cause the avc, but it is really not a problem.
(In reply to comment #8) > Do you have a process that is running as rpm_script_t? > > ps -eZ | grep rpm_script_t Apparently not. > > if not, you can probably ignore these avcs since they will not happen in normal > running of the system. > > The vmware workstation rpm probably did a service cupsd restart with the stdout > set to a fifo file in the rpm. This will cause the avc, but it is really not a > problem. That's reassuring, but it would be nicer not to see the AVC at all. I suppose that's a VMware issue, though...
Agreed.