Bug 474494 - selinux targeted policy does not work in vmware
selinux targeted policy does not work in vmware
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
: Desktop, SELinux
Depends On:
  Show dependency treegraph
Reported: 2008-12-03 21:15 EST by d. johnson
Modified: 2009-11-18 08:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-18 08:04:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from sealert -l (43.05 KB, text/plain)
2008-12-03 21:15 EST, d. johnson
no flags Details
output from audit2allow -aM (2.54 KB, text/plain)
2008-12-03 21:16 EST, d. johnson
no flags Details
New alert messages after upgrading selinux-policy-targeted (27.23 KB, text/plain)
2008-12-04 17:23 EST, d. johnson
no flags Details
3rd setroubleshooter browser output (20.09 KB, text/plain)
2008-12-05 18:58 EST, d. johnson
no flags Details
Ran s-c-printer, generated more avc: denied messages (3.13 KB, text/plain)
2008-12-05 20:47 EST, d. johnson
no flags Details
selinux AVCs after new policy applied (11.28 KB, text/plain)
2008-12-11 16:45 EST, d. johnson
no flags Details
After selinux-policy-targeted-3.5.13-38.fc10.noarch (17.21 KB, text/plain)
2009-01-09 23:02 EST, d. johnson
no flags Details
compressed audit log (572.64 KB, application/octet-stream)
2009-03-10 09:58 EDT, d. johnson
no flags Details
AVCs from a vmware suspend (6.14 KB, text/plain)
2009-03-25 23:37 EDT, d. johnson
no flags Details
New AVC from sshd (9.30 KB, text/plain)
2009-03-26 00:51 EDT, d. johnson
no flags Details

  None (edit)
Description d. johnson 2008-12-03 21:15:35 EST
Created attachment 325624 [details]
output from sealert -l

Description of problem:

Selinux default policy denies activities that are needed by VMware.

Version-Release number of selected component (if applicable):

Fedora 10
VMware Fusion 2.0.1 / vmware-tools

selinux-policy-targeted 3.5.13-18

How reproducible:

Steps to Reproduce:
1.  Install F10 into VMware.
2.  "yum install kernel-devel make gcc; yum update"
3.  Install VMware tools package
4.  "touch /.autorelabel"
5.  Change selinux to "Permissive"
6.  Reboot.
7.  Try out VMware items like suspend/resume, obtain a dhcp lease, add printer to cups, mount host volume, reboot etc..
8.  "sealert -l \*" and review.
9.  "audit2allow -aM vmware-issues" and review.  Apply if you feel brave.
10.  Change selinux to "Enforcing" and verify steps above resolved issue.
Actual results:

audit2allow generates an 87 line "fix" to the policy.

Expected results:

sealert should not generate messages about DHCP failing, or CUPS unable to start.  Instead, they should actually work.

Additional info:

"setsebool -P allow_mount_anyfile=1" is required to make host mount work.
Comment 1 d. johnson 2008-12-03 21:16:49 EST
Created attachment 325625 [details]
output from audit2allow -aM
Comment 2 Daniel Walsh 2008-12-04 08:50:49 EST
Eric looking at this policy, it seems the kernel running under vmware is generating some weird access violations.

Lots of confined domains suddenly needing 
 { sys_rawio sys_resource sys_admin } capability?

D.  Johnson, Updating to policy 26 will fix some of these.

Seems like you have something weird running as cupsd?

/usr/lib/vmware-tools/sbin32/vmware-hgfsmounter  is labeled incorrectly?
Comment 3 Eric Paris 2008-12-04 08:55:56 EST
What's in vmware tools, does it load a kernel module?
Comment 4 d. johnson 2008-12-04 16:31:25 EST
I've upgraded to selinux-policy-targeted-3.5.13-26.fc10.noarch so I'll see what it did.

VMwareTools-7.9.3-128865.tar.gz does not come packaged up in RPM format, so it may not have the correct label.  What label should things under /usr/lib/vmware-tools have?

Yes, it does have a set of kernel modules:

# lsmod |grep vm
vmsync                  7964  0 
vmblock                15780  3 
vmmemctl               11380  0 
vmhgfs                 38528  1 
vmxnet                 17920  0 
vmci                   27884  1 vsock
Comment 5 d. johnson 2008-12-04 17:22:40 EST
Here's a rundown of what I did to generate more AVC denied messages.

0. "yum update" (as mentioned above)
1. "SELINUX=permissive"
2. "touch /.autorelabel"
3. reboot
4. Run system-config-printer, press "Add", AVC generated.  Additionally, s-c-p hangs and wont exit properly on it's own.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 2548 root      20   0 10656 2692 1928 R 99.2  0.7   0:25.53 cupsd 

5. "sudo /sbin/service cups restart" to fix cupsd.  More AVC fun.
6. Suspend guest.  Refill tea.  Resume guest.
7. Tell NM to "Auto eth0" again (acquire a dhcp address - even though the old lease is still valid).  No AVC on this now.
8. Run "setroubleshoot browser" and save off the results.

I'll add the new sealert messages in a minute.
Comment 6 d. johnson 2008-12-04 17:23:42 EST
Created attachment 325756 [details]
New alert messages after upgrading selinux-policy-targeted
Comment 7 Daniel Walsh 2008-12-05 08:59:46 EST
Ok I can fix the labeling on  /usr/lib/vmware-tools/bin32/vmware-tpvmlp
 to be bin_t, 

You can check this out by executing

# chcon -t bin_t  /usr/lib/vmware-tools/bin32/*

I will add the ability for cups to create and manage lock files.

But the getpgid of initrc_t is a problem.  What process on your machine is running as initrc_t?

ps -eZ | grep initrc_t

Fixes are in selinux-policy-3.5.13-33.fc10
Comment 8 d. johnson 2008-12-05 18:53:11 EST
Here's what the directory looks like prior to any changes:

# pwd

# /bin/ls -lZR
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   configure-gtk.sh
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-hgfsclient
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-toolbox
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-toolbox-gtk
-rwx------  root uucp unconfined_u:object_r:lib_t:s0   vmware-tpvmlp
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-tpvmlpd
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-user
-r-sr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-user-suid-wrapper
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-user-wrapper
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-xferlogs
drwxr-xr-x  root root unconfined_u:object_r:lib_t:s0   xorg71

-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-user
-r-xr-xr-x  root root unconfined_u:object_r:lib_t:s0   vmware-user-wrapper

** For consistency sake, shouldn't the 'bin32' directory also be type bin_t ?

chcon -Rt bin_t  /usr/lib/vmware-tools/bin32

And to answer your other question:

# ps -eZ | grep initrc_t
system_u:system_r:initrc_t:s0    2148 ?        00:00:00 tpvmlp
system_u:system_r:initrc_t:s0    2149 ?        00:00:00 tpvmlp
system_u:system_r:initrc_t:s0    2774 ?        00:00:00 lpinfo

Also, I noticed this (somewhat related, albeit not directly perhaps):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 2776 lp        20   0     0    0    0 Z  0.0  0.0   0:00.00 beh <defunct>      
 2777 root      20   0     0    0    0 Z  0.0  0.0   0:00.00 lpd <defunct>      
 2778 root      20   0     0    0    0 Z  0.0  0.0   0:00.00 http <defunct>     
 2779 lp        20   0     0    0    0 Z  0.0  0.0   0:00.00 snmp <defunct>     
 2780 lp        20   0     0    0    0 Z  0.0  0.0   0:00.00 usb <defunct>      
 3166 dj        20   0     0    0    0 Z  0.0  0.0   0:00.00 Xsession <defunct> 

I'm not sure what all of those are above, but they appear to be related to cupsd.  (Only Xsession remains after I do a 'service cups stop')

I'll restart after I change context types on the vmware-bin directory.  (And upload the new selinux error file)
Comment 9 d. johnson 2008-12-05 18:58:17 EST
Created attachment 325945 [details]
3rd setroubleshooter browser output

After changing security type of bin32/ - rebooted, and generated this file.
Comment 10 d. johnson 2008-12-05 20:47:22 EST
Created attachment 325955 [details]
Ran s-c-printer, generated more avc: denied messages

$ system-config-printer&

Caught non-fatal exception.  Traceback:
File "/usr/share/system-config-printer/system-config-printer.py", line 2507, in save_serversettings
File "/usr/share/system-config-printer/system-config-printer.py", line 2415, in fillServerTab
    self.server_settings = self.cups.adminGetServerSettings()
File "/usr/share/system-config-printer/authconn.py", line 146, in <lambda>
    return lambda *args, **kwds: self._authloop (fname, fn, *args, **kwds)
File "/usr/share/system-config-printer/authconn.py", line 164, in _authloop
    raise cups.IPPError (cups.IPP_NOT_AUTHORIZED, '')
IPPError: (1027, '')
Continuing anyway..

[1]+  Done                    system-config-printer
Comment 11 Daniel Walsh 2008-12-08 15:31:46 EST
You can allow this for now.

# audit2allow -M mypol -l -i /var/log/audit/audit.log
# semodule -i mypol.pp

Fixed in selinux-policy-3.5.13-33.fc10
Comment 12 d. johnson 2008-12-11 16:45:04 EST
Created attachment 326680 [details]
selinux AVCs after new policy applied

1. Installed selinux-policy-3.5.13-34.fc10 and selinux-policy-targeted-3.5.13-34.fc10
2. "touch /.autorelabel" and reboot.

More AVC's.  Attached.
Comment 13 Daniel Walsh 2008-12-15 11:15:56 EST
If you delete /var/lock/LCK..ttyS0

And then try to print does it work?
Comment 14 d. johnson 2008-12-15 13:55:21 EST
/var/lock/LCK..ttyS0 does not exist.

The printer is remote.
Comment 15 Daniel Walsh 2008-12-18 11:40:43 EST
In that case some process outside of cups is creating the LCK file and cups is trying to read/write it.

What is tpvmlp?  Maybe this should not be running as cupsd?
Comment 16 d. johnson 2008-12-18 13:28:58 EST
It's a symlink: /usr/bin/tpvmlp -> /usr/lib/vmware-tools/bin/vmware-tpvmlp.

Sadly, I'm not sure how it gets called from cups.
Comment 17 d. johnson 2009-01-09 22:59:11 EST
After this latest selinux policy update, a few files were relabeled.

Any chance we can get this applied to the policy?

# chcon -t bin_t  /usr/lib/vmware-tools/bin32/*

By the time I was able to login and apply that, I had 2037 AVC's on it.

Additionally, libGL and sadc generate AVCs now.  I'll attach them in a moment.
Comment 18 d. johnson 2009-01-09 23:02:44 EST
Created attachment 328611 [details]
After selinux-policy-targeted-3.5.13-38.fc10.noarch 

After selinux-policy-targeted-3.5.13-38.fc10.noarch update along with a reboot, the attached set of AVCs were noted in addition.
Comment 19 d. johnson 2009-01-09 23:24:41 EST
More policy fun:

1) Run "hardlink -nv /usr/lib"
2) wait for AVC
3) "sealert -b" and you'll get the libGL AVC in the above attachment.

Not sure if this is specific to vmware or not, but it does not happen on my older box.
Comment 20 Daniel Walsh 2009-01-12 15:49:11 EST
/usr/lib/vmware-tools/bin32 Seems to be labeled bin_t on 38???

libGL.so.1.2 should be labeled textrel_shlib_t

restorcon /usr/lib/libGL.so.1.2

The other AVC's should be solved using audit2allow -M mycups since there seems to be some process running as initrc_t that cups is trying to talk to.
Comment 21 Daniel Walsh 2009-03-02 21:31:38 EST
I think we need policy written for vmware.  Did this work around fix your problem?
Comment 22 d. johnson 2009-03-04 22:02:29 EST
Prelinked files show up as comment 19-20 point out.  This is not something restorecon can resolve.

The original problem is somewhat better.  What happens now is that anytime the kernel changes, labels become incorrectly marked and require this to resolve:

restorecon -rv /etc/tpvmlp.conf /usr/lib/vmware-tools /var/run

This happens only when the new kernel is booted for the first time, but it does happen every time.

The new files that are created from vmware (above) do not get the proper labels assigned.
Comment 23 Daniel Walsh 2009-03-05 10:26:59 EST
You can also use restorcond to help solve this problem.

But what are the labels changing to?
Comment 24 d. johnson 2009-03-09 23:51:41 EDT
[root@embla ~]# ls -lZ /etc/tpvmlp.conf 
-rw-r--r--  root root system_u:object_r:etc_runtime_t:s0 /etc/tpvmlp.conf
[root@embla ~]# restorecon /etc/tpvmlp.conf 
[root@embla ~]# ls -lZ /etc/tpvmlp.conf 
-rw-r--r--  root root system_u:object_r:etc_t:s0       /etc/tpvmlp.conf

[root@embla ~]# ls -lZ /var/run/vmware-guestd.pid
-rw-r--r--  root root system_u:object_r:initrc_var_run_t:s0 /var/run/vmware-guestd.pid
[root@embla ~]# restorecon /var/run/vmware-guestd.pid
[root@embla ~]# ls -lZ /var/run/vmware-guestd.pid
-rw-r--r--  root root system_u:object_r:vmware_var_run_t:s0 /var/run/vmware-guestd.pid

That's two of them ... Not even a new kernel - just a reboot.


Before I could login and disable audit, I found this:

[root@embla ~]# ausearch -m avc -ts today |wc -l

There were zero prior to the reboot.
Comment 25 Daniel Walsh 2009-03-10 09:20:44 EDT
Please attach a compressed /var/log/audit/audit.log
Comment 26 d. johnson 2009-03-10 09:58:13 EDT
Created attachment 334654 [details]
compressed audit log

# ls -lrt
total 18M
-r-------- 1 root root 5.1M Mar  9 21:54 audit.log.3
-r-------- 1 root root 5.1M Mar  9 22:08 audit.log.2
-r-------- 1 root root 5.1M Mar  9 22:23 audit.log.1
-rw------- 1 root root 2.7M Mar 10 08:50 audit.log

Comment 27 d. johnson 2009-03-21 19:51:49 EDT
Ran "fixfiles check" and saw this:

filespec_add:  conflicting specifications for /etc/sysconfig/networking/profiles/default/ifcfg-eth0 and /etc/sysconfig/networking/devices/ifcfg-eth0, using system_u:object_r:net_conf_t:s0.


This is a new conflict since -47.
Comment 28 Daniel Walsh 2009-03-23 09:45:09 EDT
Miroslav you need to add this labeling

/etc/sysconfig/networking/profiles/default(/.*)?  gen_context(system_u:object_r:net_conf_t,s0)

Might want to actually do it one level higher.  Although I do not know how often system-config-network and these directories are used now.
Comment 29 Miroslav Grepl 2009-03-24 08:39:56 EDT
Fixed in selinux-policy-3.5.13-51.fc10
Comment 30 d. johnson 2009-03-25 23:37:17 EDT
Created attachment 336742 [details]
AVCs from a vmware suspend

I did a vmware suspend and received the attached AVCs.

Comment 31 d. johnson 2009-03-26 00:47:05 EDT
Applied these two:

 selinux-policy-targeted 3.5.13-52.fc10 

And rebooted ...

This problem still exists after upgrading policy:

filespec_add:  conflicting specifications for /etc/sysconfig/networking/devices/ifcfg-eth0 and /etc/sysconfig/network-scripts/ifcfg-eth0, using system_u:object_r:net_conf_t:s0.

Followup from comment 22 -

After a reboot with a full fs relabel and a new kernel:

# fixfiles check /usr/lib/vmware-tools /var/run /etc
/sbin/restorecon reset /usr/lib/vmware-tools/bin context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /usr/lib/vmware-tools/sbin context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /var/run/vmware-guestd.pid context system_u:object_r:initrc_var_run_t:s0->system_u:object_r:vmware_var_run_t:s0
/sbin/restorecon reset /etc/sysconfig/networking/devices/ifcfg-eth0 context system_u:object_r:net_conf_t:s0->system_u:object_r:etc_t:s0
/sbin/restorecon reset /etc/tpvmlp.conf context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0

Looks like it is much closer, but still not quite ideal.
Comment 32 d. johnson 2009-03-26 00:51:24 EDT
Created attachment 336752 [details]
New AVC from sshd

This (attached) AVC is brand new with the policy after bootup.

In theory, it wants this addition to the policy:

Comment 33 Bug Zapper 2009-11-18 05:18:51 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 34 Daniel Walsh 2009-11-18 08:04:35 EST
Closing as closed in the current release.

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