I emerged vmware today and noticed that I couldn't start vmware anymore. The vmware and vmware-ping file (both setuid) are lacking go+r. The logfile shows the culprit: sfperms. It seems that this is called by default since a few days (03.08.?). sfperms * >>> SetUID: [chmod go-r] /var/tmp/portage/vmware-workstation-4.5.2.8848-r1/ [ ok ] * >>> SetUID: [chmod go-r] /var/tmp/portage/vmware-workstation-4.5.2.8848-r1/ [ ok ] * >>> SetUID: [chmod go-r] /var/tmp/portage/vmware-workstation-4.5.2.8848-r1/ [ ok
the vmware and vmware-ping files have a+x though and u+r right ?
Exactly. The owner is root:root, so "o" needs the read right on this file to execute it (setuid or not).
The vmware start script ("/opt/bin/vmware") is a shell script and the executor needs read right
no, the only time the executor needs the read bit is when the file is a shell script if it is a normal binary, the perms can be o+rx, go-rw+x, and +s, and everything will work fine
"/opt/vmware/bin/vmware/" *is* a normal shell script and because of the missing read right it's not possible to start vmware. (vmware-ping might be okay because it's a binary).
i know it's a script, i was correcting your logic that 'executers need read rights' in this case, executers do need the read rights because it's a script
I'm sorry... what's sfperms?
Ah... I found it. Adding solar to CC, then. Hopefully he will have an answer for you, though on my system, neither /opt/vmware/bin/vmware nor /opt/vmware/bin/vmware-ping are setuid/setgid on any of my systems, so I am not sure why this is affecting you.
Well thanks for adding me to the CC.. # 'sfperms' feature for security minded people that causes portage to # remove group+other readable bits on setuid files and # remove the other readable bits on setgid files. # I can't really say I like the idea of a suid shell scripts as they can lead to a total compromise of a system. They should never be used. All of spankys comments are perfectly correct. If you want to make the ebuild aware your going to have to save permissions and restore them at postinst. Or restrict the feature. Note: This is the first pkg in gentoo's history that I'm aware of where sfperms has caused a conflict. Also I've asked a few hardened users and nobody else seems to have this problem. I'll merged this pkg and see if I can reproduce it.
This is really strange. I have 2 machines right next to each other, both with vmware-workstation installed. On one machine, vmware and vmware-ping are suid root, and on the other, neither are suid root. I have vmware running on both machines, and I have yet to find anything that is not working. I am sure there must be something obscure that I am missing, but it appears to run fine. The actual binary is under /opt/vmware/lib/bin and it is not suid root.
/usr/bin/vmware: /usr/bin/vmware: Permission denied Runs fine as long as I'm root. The way the feature was written it never took into account the need to RESTRICT= so that probably wont be so easy to work around. My honest opinion is it would be better to just remove the suid bits all together and to 'einfo' in the pkg_postinst() that suggests vmware when used by normal users should be run via sudo. That would atleast reduce the chances of any possible security bugs showing up and biting us in the arse one day.
*** Bug 70269 has been marked as a duplicate of this bug. ***
Hello, I have install sudo to run wmware as solar say's but there is a new problem : bash-2.05b$ sudo vmware Gtk-WARNING **: cannot open display: Why nobody care about this bug ??? Since two weeks no more vmware on my desktop ;) Regards
A recent secure update to sudo made it do an env_reset. You might want to check if this is the case for you. If so you may need to allow your user/group to not env_reset
You just have to love when an update breaks funtionality... heh... vmware is a prime example of this happening. Anyway, there are several simple solutions: 1. FEATURES="-sfperms" emerge vmware-workstation -or- 2. chmod a+r /opt/vmware/bin/vmware -or- 3. "fix" sudo as solar suggested solar: is there any chance we could have sfperms *not* strip the r bit from suid shell scripts? You mentioned restricting the FEATURE. What is the proper RESTRICT for sfperms?
scripts should still never be suid. sudo is not the best work around. I'm not sure what to say here. Maybe try FEATURES=-sfperms or RESTRICT= Can't somebody rewrite this shell script in c? The bash interpeter is just so darn prone to exploition with +s bits on scripts.
*** Bug 73982 has been marked as a duplicate of this bug. ***
How about: chown root:vmware /opt/vmware/bin/vmware chmod 450 /opt/vmware/bin/vmware Is that a security risk?
This has just nabbed me. What seems like the safest option as far as running vmware as a regular user? $ which vmware /usr/bin/vmware $ ls -al /usr/bin/vmware lrwxrwxrwx 1 root root 22 2004-12-25 00:12:26 /usr/bin/vmware -> /opt/vmware/bin/vmware* $ ls -al /opt/vmware/bin/vmware -r-s--x--x 1 root root 4547 2004-12-25 00:12:23 /opt/vmware/bin/vmware* $ vmware /usr/bin/vmware: /usr/bin/vmware: Permission denied
I created a group 'vmware' and assigned my users (in my case just me ;-) to that group. I changed the group of all files in /opt/vmware/bin/ to vmware. $ ls -al /opt/vmware/bin/ insgesamt 4512 drwxr-xr-x 2 root root 616 16. Dez 08:53 . drwxr-xr-x 6 root root 144 10. Dez 08:49 .. -r-xr-xr-x 1 root vmware 6404 16. Dez 08:53 vmnet-bridge -r-xr-xr-x 1 root vmware 110908 16. Dez 08:53 vmnet-dhcpd -r-xr-xr-x 1 root vmware 121676 16. Dez 08:53 vmnet-natd -r-xr-xr-x 1 root vmware 5436 16. Dez 08:53 vmnet-netifup -r-xr-xr-x 1 root vmware 8384 16. Dez 08:53 vmnet-sniffer -r-xr-xr-x 1 root vmware 4223 16. Dez 08:53 vmrun -r-xr-xr-x 1 root vmware 11014 16. Dez 08:53 vm-support -r--r-x--- 1 root vmware 4715 16. Dez 08:53 vmware -r-xr-x--- 1 root vmware 215257 10. Dez 08:49 vmware-config-console.pl -r-xr-xr-x 1 root vmware 236114 16. Dez 08:53 vmware-config.pl -r-xr-x--- 1 root vmware 2421972 10. Dez 08:49 vmware-console -r-xr-xr-x 1 root vmware 540720 16. Dez 08:53 vmware-loop -r-xr-xr-x 1 root vmware 25488 16. Dez 08:53 vmware-mount.pl -r--r-x--- 1 root vmware 10172 16. Dez 08:53 vmware-ping -r-xr-x--- 1 root vmware 84345 10. Dez 08:49 vmware-uninstall-console.pl -r-xr-xr-x 1 root vmware 87637 16. Dez 08:53 vmware-uninstall.pl -r-xr-xr-x 1 root vmware 677544 16. Dez 08:53 vmware-vdiskmanager It works with me, I don't know enough about the associated risks, though.
Good read on setuid shell scripts. http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html
what's the poin in having setuid scripts anyway? Linux ignores them: # echo "#!/bin/cat /etc/shadow" > foo # chmod +x,u+s foo ... $ ./foo bin/cat: /etc/shadow: Permission denied #!/bin/cat /etc/shadow
For what it's worth, VMware seems to work perfectly for me without the setuid bit on /opt/vmware/bin/vmware or vmware-ping. It's needed on vmware-vmx, but that isn't a problem since it's an ELF executable.
Yeah, I had noticed that in my playing, too. I was still a bit concerned about the vmware-ping, though, as I really do not know why it was suid in the first place. There could be some broken functionality that we're both just missing. Anyway, I'm looking at this and another fix or two for the near future, I've just been busy working on release stuff for the moment.
I've removed the suid bits from everything except vmware-vmx and it appears to work. I also had rizzo test it and he got the same results. I've added a newer vmware-workstation ebuild to portage but haven't bumped the revision. However, it is being marked stable, so it should catch most people.
I just upgraded to 5.0_rc2 and the shell script was still suid. As before, removing the suid bit fixes things. Apparently the 5.x stuff never got the fix.
Bad Donnie reopening bugs for a package.masked package! ;] Anyway, this is fixed in the VMware 5 final ebuild.
