Description of problem: open-vm-tools-desktop executes vmtoolsd (via vmware-user-suid-wrapper) on graphical login from /etc/xdg/autostart/vmware-user.desktop. With the vmtools policy added in 39132ed6, that is not allowed from the user_t domain. As a result, all of the user/graphical features of open-vm-tools fail, including resolution changes. It seems like some functionality might be missing from the policy for the system-wide daemon as well (see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1057488). Audit log showed quite a few entries. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.12.1-119.fc20.noarch open-vm-tools-9.4.0-1.fc20.x86_64 open-vm-tools-desktop-9.4.0-1.fc20.x86_64 Steps to Reproduce: 1. Install open-vm-tools{,-desktop} inside guest VM 2. Confine an account to selinux user_u 3. Login and observe that resolution does not change when resizing, 'ps ax | grep vmtools' shows no '-n vmusr' process. 4. Run /usr/bin/vmware-user-suid-wrapper manually Actual results: /usr/bin/vmtoolsd permission denied, graphical features aren't available. Expected results: The same functionality as after running 'chcon system_u:object_r:bin_t /usr/bin/vmtoolsd'
John, any chance you could re-test in permisive mode and paste AVC msgs which you are getting? Thank you,
Permissive mode with dontaudit disabled: type=AVC msg=audit(1390967608.703:826): avc: denied { execute } for pid=7807 comm="vmware-user-sui" name="vmtoolsd" dev="dm-1" ino=1756271 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:vmtools_exec_t:s0 tclass=file type=AVC msg=audit(1390967608.703:826): avc: denied { read open } for pid=7807 comm="vmware-user-sui" path="/usr/bin/vmtoolsd" dev="dm-1" ino=1756271 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:vmtools_exec_t:s0 tclass=file type=AVC msg=audit(1390967608.703:826): avc: denied { execute_no_trans } for pid=7807 comm="vmware-user-sui" path="/usr/bin/vmtoolsd" dev="dm-1" ino=1756271 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:vmtools_exec_t:s0 tclass=file Thanks.
So /usr/bin/vmware-user-suid-wrapper is supposed to be executed directly?
(In reply to Miroslav Grepl from comment #3) > So /usr/bin/vmware-user-suid-wrapper is supposed to be executed directly? It's run automatically as part of the graphical environment: % cat /etc/xdg/autostart/vmware-user.desktop [Desktop Entry] Type=Application Exec=/usr/bin/vmware-user-suid-wrapper Name=VMware User Agent .. That process is necessary for resolution changes and copy&paste, at least. I haven't seen any AVC when it runs under user_u:user_r:user_t in my configuration, but I don't know what exactly it needs to do.
Sorry, I was unclear with my last comment. At the moment, even read/open/execute_no_trans are denied on /usr/bin/vmtoolsd. It cannot execute at all for a login in user_u:user_r:user_t, and that breaks functionality. That is a bug, and that's what the AVC messages above show. What I meant with my last comment was: As far as I can tell, the user role/domain is sufficient for that vmtoolsd process. It doesn't seem to need any privileges above that (i.e. execute_no_trans works), but I expect it would still be a good idea to transition to vmtools_t? Reopened under the assumption that you didn't have some other reason to say NOTABUG.
John, could you try to test http://fpaste.org/73035/ solution? Thank you very much.
Created attachment 860029 [details] audit.log from user_u login with vmtools_helper_t module (In reply to Miroslav Grepl from comment #6) > John, > could you try to test > > http://fpaste.org/73035/ > > solution? Thank you very much. Sorry for the delay. That does not solve the problem, and my selinux skills aren't good enough to speculate on why. I've attached the relevant audit.log during user_u graphical login with dontaudit disabled and permissive mode. In enforcing mode, it fails on: type=SELINUX_ERR msg=audit(1391671442.666:4447): security_compute_sid: invalid context user_u:user_r:vmtools_t:s0 for scontext=user_u:user_r:vmtools_helper_t:s0 tcontext=system_u:object_r:vmtools_exec_t:s0 tclass=process type=SYSCALL msg=audit(1391671442.666:4447): arch=c000003e syscall=59 success=no exit=-13 a0=7fff485eb170 a1=7fff485eb130 a2=7fff485ec2a8 a3=ffffffff items=0 ppid=1 pid=24743 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 ses=143 tty=(none) comm="vmware-user-sui" exe="/usr/bin/vmware-user-suid-wrapper" subj=user_u:user_r:vmtools_helper_t:s0 key=(null) It should be easily reproduced by any standard fedora install under vmware with a user_u login. I'm happy to test solutions too, of course.
Ok, thank you for testing. role vmtools_helper_roles types vmtools_t; needs to be added to myvmtools.te and re-run # make -f /usr/share/selinux/devel/Makefile myvmtools.pp # semodule -i myvmtools.pp # chcon -t vmtools_helper_exec_t /usr/bin/vmware-user-suid-wrapper
(In reply to Miroslav Grepl from comment #8) > role vmtools_helper_roles types vmtools_t; > > needs to be added to myvmtools.te and re-run It now executes correctly as user_u:user_r:vmtools_t:s0, and seems to basically work (resolution changes). Here are the remaining AVC entries (after a semodule -B to re-enable dontaudit rules): type=AVC msg=audit(1391678809.817:5012): avc: denied { connectto } for pid=31578 comm="vmtoolsd" path=002F746D702F2E5831312D756E69782F5830 scontext=user_u:user_r:vmtools_t:s0 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_stream_socket type=AVC msg=audit(1391678809.817:5013): avc: denied { read } for pid=31578 comm="vmtoolsd" name="database" dev="tmpfs" ino=466612 scontext=user_u:user_r:vmtools_t:s0 tcontext=system_u:object_r:xdm_var_run_t:s0 tclass=file type=AVC msg=audit(1391678809.817:5014): avc: denied { open } for pid=31578 comm="vmtoolsd" path="/run/gdm/auth-for-restricted-jTr7IH/database" dev="tmpfs" ino=466612 scontext=user_u:user_r:vmtools_t:s0 tcontext=system_u:object_r:xdm_var_run_t:s0 tclass=file type=AVC msg=audit(1391678809.817:5015): avc: denied { getattr } for pid=31578 comm="vmtoolsd" path="/run/gdm/auth-for-restricted-jTr7IH/database" dev="tmpfs" ino=466612 scontext=user_u:user_r:vmtools_t:s0 tcontext=system_u:object_r:xdm_var_run_t:s0 tclass=file type=AVC msg=audit(1391678809.842:5016): avc: denied { search } for pid=31578 comm="vmtoolsd" name="restricted" dev="dm-1" ino=548889 scontext=user_u:user_r:vmtools_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir I'm not sure what, if any, impact they have on functionality. Thanks.
Do you know where "restricted" directory comes from? What is a path to this directory in your homedir?
John, could you paste your actual local policy?
commit 61bc70fc1f6c167e8ea4366ef7c3564b5d429102 Author: Miroslav Grepl <mgrepl> Date: Tue Feb 18 13:46:08 2014 +0100 Add vmtools_helper_t for helper scripts. Allow vmtools shutdonw a host and run ifconfig.
selinux-policy-3.12.1-126.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-126.fc20
Package selinux-policy-3.12.1-126.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-126.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2801/selinux-policy-3.12.1-126.fc20 then log in and leave karma (feedback).
Package selinux-policy-3.12.1-127.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-127.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2801/selinux-policy-3.12.1-127.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-127.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.