Bug 1656814
| Summary: | [VMware][RHEL 7.6][open-vm-tools]vmtools is not able to execute the sudo command rapidly | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Renaud Métrich <rmetrich> | |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> | |
| Status: | CLOSED ERRATA | QA Contact: | Bo Yang <boyang> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.6 | CC: | boyang, cavery, dwojewod, jsavanyo, ldu, lvrabec, mmalik, plautrba, ravindrakumar, ribarry, rmetrich, ssekidde, vmojzis, vmware-gos-qa, yacao, zpytela | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.13.1-243.el7 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1667016 (view as bug list) | Environment: | ||
| Last Closed: | 2019-08-06 12:52:54 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1649160, 1667016 | |||
|
Description
Renaud Métrich
2018-12-06 11:47:39 UTC
WW52.4 UPDATE: Based on the rule Renaud suggested, worked ENV: Host: Workstation 15 Pro Guest: RHEL7.6 Compatibility: Workstation 15 Pro(VM version 16) Steps to Try: 1. Install WS15 and its components like comment 1 2. Check VIX configurationnone 3. Install RHEL7.6 as the Guest in the WS15 4. "vmrun -T player -gu root -gp redhat runProgramInGuest "/home/boyang/vmware/rhel7_20181010.0_bios_ide_iso/rhel7_20181010.0_bios_ide_iso.vmx" /bin/sudo ls" in the terminal of Guest. HERE. Get the audit.log: type=USER_AVC msg=audit(1545901896.732:180): pid=6773 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.32 spid=6761 tpid=8357 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' 5. "cat /var/log/secure" Dec 27 00:57:13 localhost sudo: pam_systemd(sudo:session): Failed to create session: Connection timed out 6. "cat /var/log/aduit.log | audit2allow -m my_vmware > my_vmware.te" to get the new rule module local 1.0; require { type systemd_logind_t; type vmtools_t; class dbus send_msg; } #============= systemd_logind_t ============== allow systemd_logind_t vmtools_t:dbus send_msg; 7. "checkmodule -m -o my_vmware.mod my_vmware.te" to get the TE 8. "semodule_package -o my_vmware.pp -m my_vmware.mod" to compile it 9. "semodule -i my_vmware.pp" to load this new pp 10. "reboot" 11. Try "vmrun -T player -gu root -gp redhat runProgramInGuest "/home/boyang/vmware/rhel7_20181010.0_bios_ide_iso/rhel7_20181010.0_bios_ide_iso.vmx" /bin/sudo ls" 12. Try "cat /var/log/audit.log" and "cat /var/log/secure" Results: 1. After step 11, return back rapidly 2. After step 12, NO "connection time out" @yacao, ldu Need we try it in VMWare ESXI? Not clear the steps to try currently. BR, BO I am not sure. You can try with Invoke-VMScript on ESXi WW02.4 UPDATE: @Renaud Any update for this BZ? For comment 4, is this new rule enough for the SELINUX security? BR, BO Hi BO,
This new rule will be sufficient for the exact bz description, but is not generic enough to handle all issues related to remote executing commands.
For example, if you run the "timedatectl" command remotely, a new AVC will pop up:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ vmrun -T player -gu root -gp redhat runProgramInGuest "/home/rmetrich/vmware/Red Hat Enterprise Linux 7 64-bit/Red Hat Enterprise Linux 7 64-bit.vmx" /bin/timedatectl
... 25 seconds later ...
Guest program exited with non-zero exit code: 1
$
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
AVC:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
type=USER_AVC msg=audit(1547107302.991:164): pid=7116 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.28 spid=17151 tpid=17150 scontext=system_u:system_r:systemd_timedated_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
All this is due to having the remotely executed command run as "system_u:system_r:vmtools_t:s0" instead of the context of the remote shell the user is running as (e.g. "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023" for root if unconfined (the default).
Stracing vmtoolsd, we can see that the remote execution facility uses bash internally to execute the command:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
17253 09:05:50.038592 execve("/bin/bash", ["bash", "-c", "\"/bin/timedatectl\""], ["LANG=en_US.UTF-8", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin", "USER=root", "HOME=/root", "SHELL=/bin/bash"]) = 0 <0.000289>
...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Hence, we may just force a transition to happen from "vmtools_t" to "unconfined_t" upon execution as "shell_exec_t" (context of the /bin/bash executable), as shown below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# cat my-vmtools.te
module my-vmtools 1.0;
require {
type unconfined_t;
type vmtools_t;
type shell_exec_t;
class process transition;
}
type_transition vmtools_t shell_exec_t : process unconfined_t;
allow vmtools_t unconfined_t : process transition;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Compiling the module:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# yum -y install selinux-policy-devel
# checkmodule -M -m -o my-vmtools.mod my-vmtools.te
# semodule_package -o my-vmtools.pp -m my-vmtools.mod
# semodule -i my-vmtools.pp
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
With this in place, remotely executed commands will end up being "system_u:system_r:unconfined_t", which then enables any arbitrary command execution (sudo, timedatectl, etc):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ vmrun -T player -gu root -gp redhat runProgramInGuest "/home/rmetrich/vmware/Red Hat Enterprise Linux 7 64-bit/Red Hat Enterprise Linux 7 64-bit.vmx" /bin/id
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
-->
Jan 10 10:28:32 vmware-rhel75 vmtoolsd[7133]: uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:unconfined_t:s0
This is however not fully optimal since a confined user (e.g. "staff" mapped to "staff_u") will also have the remote command be executed as "unconfined_t":
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# useradd -Z staff_u staff
# echo "staff" | passwd --stdin staff
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ vmrun -T player -gu staff -gp staff runProgramInGuest "/home/rmetrich/vmware/Red Hat Enterprise Linux 7 64-bit/Red Hat Enterprise Linux 7 64-bit.vmx" /bin/id
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
-->
Jan 10 10:29:29 vmware-rhel75 vmtoolsd[7133]: uid=1001(staff) gid=1001(staff) groups=1001(staff) context=system_u:system_r:unconfined_t:s0
I would hence let Lukas validate this proposal.
New proposed SELinux rules, special thanks to lvrabec++:
# cat my-vmtools.te
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
module my-vmtools 1.0;
require {
attribute domain;
class dbus send_msg;
class file entrypoint;
class process transition;
type shell_exec_t;
type vmtools_t;
type vmtools_unconfined_t;
}
# Allow all domains to send back dbus response
allow domain vmtools_unconfined_t : dbus send_msg;
# Allow transitioning from vmtools_t (vmtoolsd) to unconfined
allow vmtools_t vmtools_unconfined_t : process transition;
# Allow transitioning to unconfined when executing a shell
allow vmtools_unconfined_t shell_exec_t : file entrypoint;
# Transition to unconfined upon executing a shell
type_transition vmtools_t shell_exec_t : process vmtools_unconfined_t;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
*** Bug 1609683 has been marked as a duplicate of this bug. *** Renaud, thanks for working out the details for the SELinux change. I'm curious if we need similar SELinux rule in Fedora too? Please see https://bugzilla.redhat.com/show_bug.cgi?id=1598346. If applicable, would you be willing to add this SELinux policy in Fedora too? Thanks! Hi Ravindra, Similar rules need to be integrated into Fedora. I didn't test but checked the current rules and these are definitely needed. I'm no developer but maintenance engineer so I won't fix this myself, but let Lukas do that. Renaud. Applies to RHEL8 also: https://bugzilla.redhat.com/show_bug.cgi?id=1667016 WW12.3 UPDATE:
Verified this BZ in current latest kernel and selinux-policy. Couldn't meet it.
ENV:
0)Host: Fedora 29
1)Guest: RHEL7 with latest kernel in WS15
2)Compatibility: Workstation 15 Pro(VM version 16)
Steps to Try:
0. Install a WS15 and its components in Host of ENV
1. Install a RHEL7 as the Guest in WS15
2. Upgrade selinux-policy and selinux-policy-targeted in Guest of ENV
3. "vmrun -T player -gu root -gp redhat runProgramInGuest "/home/boyang/vmware/rhel7_20181010.0_bios_ide_iso/rhel7_20181010.0_bios_ide_iso.vmx" /bin/sudo ls" in Host terminal
4. "cat /var/log/secure"
5. "cat /var/log/audit/audit.log"
Result:
1. After step 2,
[root@localhost ~]# rpm -qa | grep selinux-policy
selinux-policy-3.13.1-241.el7.noarch
selinux-policy-targeted-3.13.1-241.el7.noarch
2. After step 3, execute command rapidly
3. After step 4 and 5, NO related failure log
Change "Status" to "VERIFIED', if you have any question / requirement, you can change the "Status"
Thanks.
BR,
BO
WW12.3 UPDATE: Based on Comment 22 requirement, tested below CMDs /usr/bin/hostnamectl /usr/bin/machinectl /usr/bin/localectl /usr/bin/timedatectl /usr/bin/loginctl It seemed they can execute CMDs rapidly, from VM Guest /var/log/secure: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Mar 20 10:12:53 localhost polkitd[6790]: Loading rules from directory /etc/polkit-1/rules.d Mar 20 10:12:53 localhost polkitd[6790]: Loading rules from directory /usr/share/polkit-1/rules.d Mar 20 10:12:53 localhost polkitd[6790]: Finished loading, compiling and executing 2 rules Mar 20 10:12:53 localhost polkitd[6790]: Acquired the name org.freedesktop.PolicyKit1 on the system bus Mar 20 10:12:57 localhost sshd[7392]: Server listening on 0.0.0.0 port 22. Mar 20 10:12:57 localhost sshd[7392]: Server listening on :: port 22. Mar 20 10:13:07 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:07 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:08 localhost VGAuth[7919]: [Mar 20 10:13:08.000] [ error] [vmsvc] Unable to execute the ""/bin/sudo" "ls" " shell command: Permission denied. Mar 20 10:13:15 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:15 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:15 localhost VGAuth[7944]: [Mar 20 10:13:15.997] [ error] [vmsvc] Unable to execute the ""/bin/hostnamectl"" shell command: Permission denied. Mar 20 10:13:25 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:25 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:25 localhost VGAuth[7955]: [Mar 20 10:13:25.071] [ error] [vmsvc] Unable to execute the ""/bin/localectl"" shell command: Permission denied. Mar 20 10:13:40 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:40 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:40 localhost VGAuth[7962]: [Mar 20 10:13:40.276] [ error] [vmsvc] Unable to execute the ""/bin/machinectl"" shell command: Permission denied. Mar 20 10:13:51 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:51 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:51 localhost VGAuth[7979]: [Mar 20 10:13:51.226] [ error] [vmsvc] Unable to execute the ""/bin/timedatectl"" shell command: Permission denied. Mar 20 10:13:59 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:59 localhost VGAuth[6797]: vmtoolsd: Username and password successfully validated for 'root'. Mar 20 10:13:59 localhost VGAuth[7986]: [Mar 20 10:13:59.258] [ error] [vmsvc] Unable to execute the ""/bin/loginctl"" shell command: Permission denied. Mar 20 10:14:07 localhost login: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Mar 20 10:14:07 localhost login: ROOT LOGIN ON tty1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ It seemed these CMDs weren't executed as Permission denied. Have you any suggestion? BR, BO Add more AVC info after CMDs were Permission denied.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[root@localhost ~]# ausearch -m AVC
----
time->Wed Mar 20 06:06:28 2019
type=PROCTITLE msg=audit(1553087188.935:36): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553087188.935:36): arch=c000003e syscall=59 success=no exit=-13 a0=7fe7c0645f89 a1=7ffca8832bd0 a2=7ffca8836148 a3=7fe7c3e2eb50 items=0 ppid=6794 pid=6872 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553087188.935:36): avc: denied { entrypoint } for pid=6872 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 06:07:01 2019
type=PROCTITLE msg=audit(1553087221.166:141): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553087221.166:141): arch=c000003e syscall=59 success=no exit=-13 a0=7fe7c39e8e5c a1=7ffca88354e0 a2=55bdc1260210 a3=7fe7c3e2eb50 items=0 ppid=7947 pid=7948 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553087221.166:141): avc: denied { entrypoint } for pid=7948 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:12:53 2019
type=PROCTITLE msg=audit(1553101973.884:36): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553101973.884:36): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a37b2bf89 a1=7ffd2d6e4810 a2=7ffd2d6e7d88 a3=7f2a3b314b50 items=0 ppid=6797 pid=6860 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553101973.884:36): avc: denied { entrypoint } for pid=6860 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:07 2019
type=PROCTITLE msg=audit(1553101987.998:113): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553101987.998:113): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7918 pid=7919 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553101987.998:113): avc: denied { entrypoint } for pid=7919 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:15 2019
type=PROCTITLE msg=audit(1553101995.995:121): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553101995.995:121): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7943 pid=7944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553101995.995:121): avc: denied { entrypoint } for pid=7944 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:25 2019
type=PROCTITLE msg=audit(1553102005.070:130): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553102005.070:130): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7954 pid=7955 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553102005.070:130): avc: denied { entrypoint } for pid=7955 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:40 2019
type=PROCTITLE msg=audit(1553102020.274:138): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553102020.274:138): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7961 pid=7962 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553102020.274:138): avc: denied { entrypoint } for pid=7962 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:51 2019
type=PROCTITLE msg=audit(1553102031.224:146): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553102031.224:146): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7978 pid=7979 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553102031.224:146): avc: denied { entrypoint } for pid=7979 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:13:59 2019
type=PROCTITLE msg=audit(1553102039.257:154): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553102039.257:154): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=7985 pid=7986 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553102039.257:154): avc: denied { entrypoint } for pid=7986 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
----
time->Wed Mar 20 10:18:50 2019
type=PROCTITLE msg=audit(1553102330.884:197): proctitle="/usr/bin/vmtoolsd"
type=SYSCALL msg=audit(1553102330.884:197): arch=c000003e syscall=59 success=no exit=-13 a0=7f2a3aecee5c a1=7ffd2d6e7120 a2=55652e18b8e0 a3=7f2a3b314b50 items=0 ppid=8087 pid=8088 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmtoolsd" exe="/usr/bin/vmtoolsd" subj=system_u:system_r:vmtools_t:s0 key=(null)
type=AVC msg=audit(1553102330.884:197): avc: denied { entrypoint } for pid=8088 comm="vmtoolsd" path="/usr/bin/bash" dev="sda3" ino=50351413 scontext=system_u:system_r:vmtools_unconfined_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Any suggestion or expected result after execution?
BR,
BO
Hello, looks like you have missing rules. With: # Allow transitioning to unconfined when executing a shell allow vmtools_unconfined_t shell_exec_t : file entrypoint; # Transition to unconfined upon executing a shell type_transition vmtools_t shell_exec_t : process vmtools_unconfined_t; It should work. (In reply to Renaud Métrich from comment #27) > Hello, > looks like you have missing rules. > With: > > # Allow transitioning to unconfined when executing a shell > allow vmtools_unconfined_t shell_exec_t : file entrypoint; > > # Transition to unconfined upon executing a shell > type_transition vmtools_t shell_exec_t : process vmtools_unconfined_t; > > It should work. WW12.5 UPDATE: I verified this issue with selinux-policy-3.13.1-241.el7 included above commits in Comment 19. I thought above rules you mentioned weren't included in above commits, right? So, where should "Permission denied" be fixed? Thanks BR, BO WW13.2 UPDATE: Hi Renaud, We have a RHEL7 installed in WS15 Windows Server, we can meet this Permission denied issue. I have sent a mail about "How to access VMware(WS) ENV" to you. Any question, let me know. Thanks BR, BO (In reply to Renaud Métrich from comment #27) > Hello, > looks like you have missing rules. > With: > > # Allow transitioning to unconfined when executing a shell > allow vmtools_unconfined_t shell_exec_t : file entrypoint; > > # Transition to unconfined upon executing a shell > type_transition vmtools_t shell_exec_t : process vmtools_unconfined_t; > > It should work. Hi In comment 19, I found these commits have been included in the latest selinux-policy-3.13.1-241.el7, but when i verified this issue, met Permission denied issue in Comment 25. So, I should add above rules by manual or it should be located in selinux-policy-3.13.1-241.el7 directly? BR, BO Hello BO and Lukas,
For some reason the following rule is missing from the selinux-policy-3.13.1-241.el7 policy:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# Allow transitioning to unconfined when executing a shell
allow vmtools_unconfined_t shell_exec_t : file entrypoint;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
This makes vmtoolsd dump core (because of a bug, not your fault :-) ) upon executing hostnamectl or any bash command for example:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[Mar 26 09:11:12.770] [ error] [vmsvc] Unable to execute the ""/bin/hostnamectl"" shell command: Permission denied.
[Mar 26 09:22:28.749] [ error] [vmsvc] Unable to execute the ""/bin/bash" "-c" "id" "-Z" " shell command: Permission denied.
Process 18832 (vmtoolsd) of user 0 killed by SIGABRT - dumping core
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Custom policy fixing the issue:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
module my-vmtools 1.1;
require {
class file entrypoint;
type shell_exec_t;
type vmtools_unconfined_t;
}
# Allow transitioning to unconfined when executing a shell
allow vmtools_unconfined_t shell_exec_t : file entrypoint;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
commit 7a82e5e2d13281957b76477e4976c0e7c19db02a (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date: Tue Mar 26 15:34:24 2019 +0100
Make shell_exec_t type as entrypoint for vmtools_unconfined_t.
WW15.3 UPDATE:
Verified this BZ in current latest kernel and selinux-policy. Couldn't meet it and "Permission denied" issue.
ENV:
0)Host: Windows Server
1)Guest: RHEL7 with latest kernel in WS15
2)Compatibility: Workstation 15 Pro(VM version 16)
Steps to Try:
0. Install a WS15 and its components in Host of ENV
1. Install a RHEL7 as the Guest in WS15
2. Upgrade selinux-policy and selinux-policy-targeted in Guest of ENV
3. "vmrun -T ws -gu root -gp redhat runProgramInGuest "C:\Users\Administrator\Documents\Virtual Machines\Renaud_BZ1656814\Renaud_BZ1656814.vmx" /usr/bin/hostnamectl" in Host Powershell terminal
4. "cat /var/log/secure"
5. "cat /var/log/audit/audit.log"
6. Try below CMDs again under above steps:
/usr/bin/hostnamectl
/usr/bin/machinectl
/usr/bin/localectl
/usr/bin/timedatectl
/usr/bin/loginctl
Result:
1. After step 2,
[root@localhost ~]# rpm -qa | grep selinux-policy
selinux-policy-3.13.1-243.el7.noarch
selinux-policy-targeted-3.13.1-243.el7.noarch
2. After step 3, execute command rapidly
3. After step 4 and 5, NO related failure log or "Permission denied" issue
Change "Status" to "VERIFIED', if you have any question / requirement, you can change the "Status"
Thanks.
BR,
BO
Hello Guys, Is there any update about the fix (timeframe or package version) that I could share with Customer? Thanks Hi Lukas, Could you please fill this flag of "Fixed In Version" with correct package version? :) Thanks. BR, BO Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2127 |