Bug 474576 - AVC from NetworkManager when installing VMware
AVC from NetworkManager when installing VMware
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-04 10:05 EST by Matthew Saltzman
Modified: 2008-12-22 12:01 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-22 12:01:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Saltzman 2008-12-04 10:05:55 EST
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)
Comment 1 Matthew Saltzman 2008-12-04 11:18:23 EST
Also,

selinux-policy-3.5.13-26.fc10.noarch
Comment 2 Daniel Walsh 2008-12-04 13:50:15 EST
rpm -q selinux-policy-targeted
Comment 3 Matthew Saltzman 2008-12-04 15:53:42 EST
(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
Comment 4 Daniel Walsh 2008-12-08 15:34:17 EST
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
Comment 5 Matthew Saltzman 2008-12-08 17:26:21 EST
(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
Comment 6 Miroslav Grepl 2008-12-18 07:51:42 EST
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.
Comment 7 Matthew Saltzman 2008-12-18 20:14:11 EST
(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...
Comment 8 Daniel Walsh 2008-12-19 16:14:14 EST
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.
Comment 9 Matthew Saltzman 2008-12-19 17:02:21 EST
(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...
Comment 10 Daniel Walsh 2008-12-22 12:01:30 EST
Agreed.

Note You need to log in before you can comment on or make changes to this bug.