Bug 1609683

Renaud, 

What rules do you suggest to allow? Do you have any AVCs?

Please move to RHEL 7.7 until we have a more complete picture of the issue.

I already proposed some workaround for their specific issue regarding hostnamectl, but we got no feedback from customer.

Below is the list of systemd "ctl" commands which are failing, because they use dbus internally:

/usr/bin/hostnamectl
/usr/bin/machinectl
/usr/bin/localectl
/usr/bin/timedatectl
/usr/bin/loginctl

# ausearch -m user_avc
----
time->Tue Aug  7 03:07:40 2018
type=USER_AVC msg=audit(1533636460.165:283): pid=640 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.42 spid=10196 tpid=10195 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Tue Aug  7 04:01:09 2018
type=USER_AVC msg=audit(1533639669.677:440): pid=640 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.99 spid=38281 tpid=38280 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=?'
----
time->Tue Aug  7 04:03:43 2018
type=USER_AVC msg=audit(1533639823.102:456): pid=640 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.101 spid=38300 tpid=38299 scontext=system_u:system_r:systemd_localed_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Tue Aug  7 04:07:39 2018
type=USER_AVC msg=audit(1533640059.157:466): pid=640 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.103 spid=38314 tpid=38313 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Tue Aug  7 04:11:50 2018
type=USER_AVC msg=audit(1533640310.658:557): pid=640 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.112 spid=666 tpid=38445 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=?'
----
time->Tue Aug  7 04:12:52 2018
type=USER_AVC msg=audit(1533640372.803:576): pid=640 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.113 spid=666 tpid=38466 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=?'

------------------------------------------------------------------------------------------

The "vmrun" command is used for controlling VMWare VMs.
The interesting command is "runProgramInGuest" which allows to run some command through vmtoolsd service:

$ 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" </path/to/command> [args...]

"-gu" and "-gp" being the user and password in the guest operating system.

The output is not returned but available in the vmtoolsd logs. Only the exit code is transmitted back to the vmrun client.

If we want to support this, then very likely some adaptation must be made for vmtoolsd to run in invoking user's SELinux context (similar to what sshd does).

Doc for reference: https://www.vmware.com/support/developer/vix-api/vix112_vmrun_command.pdf

"vmrun" linux package: https://download3.vmware.com/software/player/file/VMware-VIX-1.15.8-5528349.x86_64.bundle

Wasn't able to run it against CEE BRQ infrastructure but could run it against VMPlayer locally.

Something similar to what is done in sshd should be done in vmtoolsd code:

openbsd-compat/port-linux-sshd.c:

371 /* Set the execution context to the default for the specified user */
372 void
373 sshd_selinux_setup_exec_context(char *pwname)
...

open-vm-tools doesn't have any SELinux specific code and IMO for that particular capability of acting as a shell, it should have.

Quickly checking the open-vm-tools code (both Upstream or RH, pretty similar), when executing a command, we fall into this block:

VixTools_RunProgram()

 1135    if (NULL == userToken) {
 1136       err = VixToolsImpersonateUser(requestMsg, &userToken);
 1137       if (VIX_OK != err) {
 1138          goto abort;
 1139       }
 1140       impersonatingVMWareUser = TRUE;
 1141    }
 1142 
 1143    err = VixToolsRunProgramImpl(requestName,
 1144                                 commandLine,
 1145                                 commandLineArgs,
 1146                                 runProgramRequest->runProgramOptions,
 1147                                 userToken,
 1148                                 eventQueue,
 1149                                 &pid);

I would suggest the SELinux execution context gets set in VixToolsImpersonateUser() if this is appropriate.

WW35 Updates:


In localhost, have setup a VIX(1.14) in a Fedora
In remote, have setup a RHEL7.5 GA guest in a vSphere / ESXi6.0 Host
Link https://www.vmware.com/support/developer/vix-api/VIX-1.14-ReleaseNotes.html explains VIX and vSphere relationship 

Reproduced the issue in above setup.


ENV:
Host: ESXi 6.0.0
Guest: RHEL7.5 / RHEL7.6
Compatibility: ESXi 6.0 and later (VM version 11)
vCPU: 2
Mem: 2G


Steps to Reproduce:
1. In the remote(vSphere / ESXi6.0), install a RHEL7.5 GA as the Guest

2. In the localhost(Fedora), install the VIX

3. In the localhost(Fedora), RUN vmrun -T esx -h https://esxi6.0_ipadd/sdk -u user_esx -p passwd_esx start "[ha-datacenter/datastore-236] boyang_BZ1609683_RHEL7.5/boyang_BZ1609683_RHEL7.5.vmx" to boot the remote RHEL7.5 Guest

4. In the localhost(Fedora), RUN vmrun -T esx -h https://esxi6.0_ipadd/sdk -u user_esx -p passwd_esx -gu user_guest -gp passwd_guest runProgramInGuest "[ha-datacenter/datastore-236] RHEL-7.6-20180830.1-x86_64-EFI-A/RHEL-7.6-20180830.1-x86_64-EFI-A.vmx" /bin/hostnamectl set-hostname test222 to execute the commmand

5. In the RHEL7.5 Guest terminal, check the dmesg, message, audit.log


Results:
1. After step 5, 
++++++++++++++++++++++++++++++ dmesg ++++++++++++++++++++++++++++++
Guest program exited with non-zero exit code: 1


++++++++++++++++++++++++++++++ message ++++++++++++++++++++++++++++++
Sep  3 14:00:06 vm-198-127 dbus[749]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Sep  3 14:00:06 vm-198-127 systemd: Starting Hostname Service...
Sep  3 14:00:06 vm-198-127 dbus[749]: [system] Successfully activated service 'org.freedesktop.hostname1'
Sep  3 14:00:06 vm-198-127 systemd: Started Hostname Service.
Sep  3 14:00:31 vm-198-127 vmtoolsd: Could not set property: Connection timed out


++++++++++++++++++++++++++++++ audit ++++++++++++++++++++++++++++++
type=USER_AVC msg=audit(1535954406.380:71): pid=749 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.16 spid=1597 tpid=1596 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:system_r:vmtools_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'


Additional:
1. Tried in RHEL7.6, also met the issue
2. Replaced hostnamectl command with other command (such as timedatectl) in step2, also could not execute successfully


If you have any question or specific case to run, welcome to share.

Thanks


BR,
BO

Hi Ravindra,

Could you help take a look at this issue? Its main info and reproduce steps is listed in in Comment 13.

Thanks!

Thank you for taking a look.
Below is another reproducer, purely local, using VMPlayer.

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 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/hostnamectl

Based on comment#8 and comment#13, following SELinux policy rules are needed:

allow systemd_hostnamed_t vmtools_t:dbus send_msg;
allow systemd_localed_t vmtools_t:dbus send_msg;
allow systemd_logind_t vmtools_t:dbus send_msg;
allow systemd_machined_t vmtools_t:dbus send_msg;
allow systemd_timedated_t vmtools_t:dbus send_msg;

Here is a workaround policy module, which brings these rules:

# cat workaround.cil 
( allow systemd_hostnamed_t vmtools_t ( dbus ( send_msg )))
( allow systemd_localed_t vmtools_t ( dbus ( send_msg )))
( allow systemd_logind_t vmtools_t ( dbus ( send_msg )))
( allow systemd_machined_t vmtools_t ( dbus ( send_msg )))
( allow systemd_timedated_t vmtools_t ( dbus ( send_msg )))
#

To load this policy module into memory please run:

# semodule -i workaround.cil

Now you should re-run your scenario. If it works as expected, then we know that the fix is sufficient.

To unload this policy module please run:

# semodule -r workaround

Hi Milos,

I wouldn't recommend such new rules, because it's too static and very likely other commands will fail later.
Indeed, vmtoolsd should be made SELinux aware instead: the vmrun command enables to have vmtoolsd act as a remote shell, so that "runProgramInGuest" part of vmtoolsd should be enhanced to really act as a remote shell, exactly as sshd does for example.

Renaud.

OK, I'm fine with your reasoning.

Milos

To echo Yaju request Ravindra please work this issue.

Thanks,

Cathy

(In reply to Renaud Métrich from comment #17)
> Hi Milos,
> 
> I wouldn't recommend such new rules, because it's too static and very likely
> other commands will fail later.
> Indeed, vmtoolsd should be made SELinux aware instead: the vmrun command
> enables to have vmtoolsd act as a remote shell, so that "runProgramInGuest"
> part of vmtoolsd should be enhanced to really act as a remote shell, exactly
> as sshd does for example.
> 
> Renaud.


WW35.2 UPDATES:


Hi Ravindra,

Based on your Comment 17, tried the workaround. ONLY hostnamectl worked, other commands failed with "Error: A file was not found".

Like what you suggested, these aren't recommended rules. But if you need the these commands logs, I can upload mines.


Thanks.

BO

(In reply to Renaud Métrich from comment #8)
> If we want to support this, then very likely some adaptation must be made
> for vmtoolsd to run in invoking user's SELinux context (similar to what sshd
> does).

(In reply to Renaud Métrich from comment #10)
> Something similar to what is done in sshd should be done in vmtoolsd code:
> 
> openbsd-compat/port-linux-sshd.c:
> 
> 371 /* Set the execution context to the default for the specified user */
> 372 void
> 373 sshd_selinux_setup_exec_context(char *pwname)
> ...
> 
> open-vm-tools doesn't have any SELinux specific code and IMO for that
> particular capability of acting as a shell, it should have.

Thanks Renaud for the suggestion. I have 2 questions on this:

1. I'm not SELinux expert but I'm curious if this can also be addressed by generating an appropriate security policy for vmtoolsd. Basically, we enable the necessary/required transitions in the vmtoolsd security policy implemented as part of https://bugzilla.redhat.com/show_bug.cgi?id=1463593. Is it possible?

2. If above is not possible, we will go with your suggested change. However, we would like to know if sshd solution works reliably? Asking this because I came across a "sshd_selinux_setup_exec_context" related bug -https://bugzilla.redhat.com/show_bug.cgi?id=1269072.

Oops, didn't see the request. I believe Lukas will have an answer to 1.

*** This bug has been marked as a duplicate of bug 1656814 ***