RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1656814 - [VMware][RHEL 7.6][open-vm-tools]vmtools is not able to execute the sudo command rapidly
Summary: [VMware][RHEL 7.6][open-vm-tools]vmtools is not able to execute the sudo comm...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Bo Yang
URL:
Whiteboard:
: 1609683 (view as bug list)
Depends On:
Blocks: 1649160 1667016
TreeView+ depends on / blocked
 
Reported: 2018-12-06 11:47 UTC by Renaud Métrich
Modified: 2022-08-02 08:07 UTC (History)
16 users (show)

Fixed In Version: selinux-policy-3.13.1-243.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1667016 (view as bug list)
Environment:
Last Closed: 2019-08-06 12:52:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3748481 0 None None None 2018-12-11 09:44:56 UTC
Red Hat Knowledge Base (Solution) 3814531 0 None None None 2019-01-17 14:05:33 UTC
Red Hat Product Errata RHBA-2019:2127 0 None None None 2019-08-06 12:53:18 UTC

Description Renaud Métrich 2018-12-06 11:47:39 UTC
Description of problem:

With RHEL7.6, sudo now uses PAM even for NOPASSWD entries (see BZ1547974).
When executing sudo command on the guest using open-vm-tools facility, the command takes 25 seconds to complete due to systemd-logind (called through PAM) not being able to send back the answer to vmtools service, causing a 25 seconds (d-bus timeout) delay.

----
time->Thu Dec  6 12:31:38 2018
type=USER_AVC msg=audit(1544095898.500:159): pid=7088 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.27 spid=7073 tpid=16969 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=?'


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

selinux-policy-3.13.1-229.el7_6.6.noarch


How reproducible:

Always

Steps to Reproduce:

1. Download and run VMware-Player-14.1.2-8497320.x86_64.bundle (https://softwareupdate.vmware.com/cds/vmw-desktop/player/14.1.2/8497320/linux/core/VMware-Player-14.1.2-8497320.x86_64.bundle.tar)

2. Download and install VMware-VIX-1.15.8-5528349.x86_64.bundle (https://my.vmware.com/web/vmware/details?productId=535&downloadGroup=PLAYER-1200-VIX1150)

3. Verify VIX configuration

  # cat /lib/vmware-vix/vixwrapper-config.txt
  [...]
  # Workstation and Player 14.1.2
  ws        19  vmdb  14.1.2 Workstation-14.0.0
  player    19  vmdb  14.1.2 Workstation-14.0.0

  # cd /lib/vmware-vix && ln -s Workstation-12.0.0 Workstation-14.0.0

4. Install a RHEL7.6 using VMPlayer (user/pass: root/admin)

5. Run "vmrun"

  $ vmrun -T player -gu root -gp admin runProgramInGuest "/home/rmetrich/vmware/Red Hat Enterprise Linux 7 64-bit/Red Hat Enterprise Linux 7 64-bit.vmx" /bin/sudo ls

Actual results:

- returns after 25 seconds

Expected results:

- returns almost immediately


Suggested rule:

# cat my-vmtools.te 

module my-vmtools 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;

Comment 4 Bo Yang 2018-12-27 05:28:54 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

Comment 5 Yaju Cao 2018-12-27 07:36:38 UTC
I am not sure. You can try with Invoke-VMScript on ESXi

Comment 6 Bo Yang 2019-01-10 06:36:10 UTC
WW02.4 UPDATE:


@Renaud
Any update for this BZ?
 
For comment 4, is this new rule enough for the SELINUX security?


BR,
BO

Comment 7 Renaud Métrich 2019-01-10 09:32:10 UTC
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.

Comment 8 Renaud Métrich 2019-01-10 12:14:40 UTC
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< --------

Comment 9 Renaud Métrich 2019-01-10 12:31:40 UTC
*** Bug 1609683 has been marked as a duplicate of this bug. ***

Comment 10 Ravindra Kumar 2019-01-10 19:52:54 UTC
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!

Comment 11 Renaud Métrich 2019-01-11 09:33:03 UTC
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.

Comment 12 Renaud Métrich 2019-01-17 09:05:13 UTC
Applies to RHEL8 also: https://bugzilla.redhat.com/show_bug.cgi?id=1667016

Comment 21 Bo Yang 2019-03-20 05:24:13 UTC
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

Comment 25 Bo Yang 2019-03-20 09:27:03 UTC
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

Comment 26 Bo Yang 2019-03-20 09:56:56 UTC
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

Comment 27 Renaud Métrich 2019-03-21 09:37:04 UTC
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.

Comment 28 Bo Yang 2019-03-22 11:08:11 UTC
(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

Comment 31 Bo Yang 2019-03-26 03:26:26 UTC
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

Comment 32 Bo Yang 2019-03-26 03:32:20 UTC
(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

Comment 33 Renaud Métrich 2019-03-26 08:25:34 UTC
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< --------

Comment 34 Lukas Vrabec 2019-03-26 14:35:24 UTC
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.

Comment 36 Bo Yang 2019-04-09 08:04:25 UTC
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

Comment 37 Dariusz Wojewódzki 2019-05-31 12:50:14 UTC
Hello Guys,

Is there any update about the fix (timeframe or package version) that I could share with Customer?

Thanks

Comment 39 Bo Yang 2019-06-03 05:36:13 UTC
Hi Lukas,


Could you please fill this flag of "Fixed In Version" with correct package version? :)


Thanks.


BR,
BO

Comment 43 errata-xmlrpc 2019-08-06 12:52:54 UTC
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


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