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.
Created attachment 325625 [details] output from audit2allow -aM
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?
What's in vmware tools, does it load a kernel module?
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
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.
Created attachment 325756 [details] New alert messages after upgrading selinux-policy-targeted
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
Here's what the directory looks like prior to any changes: # pwd /usr/lib/vmware-tools/bin32 # /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 ./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)
Created attachment 325945 [details] 3rd setroubleshooter browser output After changing security type of bin32/ - rebooted, and generated this file.
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 self.fillServerTab() 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
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
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.
If you delete /var/lock/LCK..ttyS0 And then try to print does it work?
/var/lock/LCK..ttyS0 does not exist. The printer is remote.
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?
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.
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.
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.
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.
/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.
I think we need policy written for vmware. Did this work around fix your problem?
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.
You can also use restorcond to help solve this problem. But what are the labels changing to?
[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. selinux-policy-targeted-3.5.13-47.fc10 Before I could login and disable audit, I found this: [root@embla ~]# ausearch -m avc -ts today |wc -l 98615 There were zero prior to the reboot.
Please attach a compressed /var/log/audit/audit.log
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 Attached.
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. selinux-policy-targeted-3.5.13-49.fc10.noarch This is a new conflict since -47.
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.
Fixed in selinux-policy-3.5.13-51.fc10
Created attachment 336742 [details] AVCs from a vmware suspend I did a vmware suspend and received the attached AVCs. selinux-policy-targeted-3.5.13-49.fc10.noarch
Applied these two: kernel 2.6.27.21-170.2.56.fc10 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.
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: ssh_rw_tcp_sockets(setfiles_t)
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing as closed in the current release.