Potential Security Risk: /var/log/vmware-vmsvc.log is world readable

[archmangler]

We're currently going through the process of hardening linux systems to meet CIS Security Benchmark standards for Ubuntu Linux.

One of the items requires justification for permissions on logs under /var/log/*. I've noticed that vmware-vmsvc.log is world readable.

Is this a potential security risk, given that non-root users are able to browse this log and perhaps infer sensitive information from it? looking at the log, it does appear to contain a lot of information which could be used in combination with other sources to formulate an attack on a server.

Is there any documentation from regarding what the security best practice for these logs are? Specifically, why should it be world readable ? Can it be changed to user and group readable only?

Example below:

user@server:~$ tail /var/log/vmware-vmsvc.log

[Aug 10 04:25:09.726] [ message] [vix] QueryVGAuthConfig: vgauth usage is: 1

[Aug 10 04:25:09.726] [ message] [vmtoolsd] Plugin 'vix' initialized.

[Aug 10 04:25:09.726] [ message] [vmtoolsd] Plugin 'deployPkg' initialized.

[Aug 10 04:25:09.786] [ message] [vmtoolsd] Plugin 'grabbitmqProxy' initialized.

[Aug 10 04:25:09.786] [ message] [vmtoolsd] Plugin 'guestInfo' initialized.

[Aug 10 04:25:09.786] [ message] [vmtoolsd] Plugin 'powerops' initialized.

[Aug 10 04:25:09.786] [ message] [vmtoolsd] Plugin 'timeSync' initialized.

[Aug 10 04:25:09.786] [ message] [vmtoolsd] Plugin 'vmbackup' initialized.

[Aug 10 04:25:09.790] [ message] [vix] VixTools_ProcessVixCommand: command 62

[Aug 10 04:25:39.706] [ warning] [guestinfo] GuestInfoSendNicInfoXdr: update failed: request "SetGuestInfo  10 ", reply "Invalid guest information type.".

user@server:~$

user@server:~$

user@server:~$ ls -l /var/log/vmware-vmsvc.log

-rw-r--r-- 1 root root 3807557 Aug 10 04:25 /var/log/vmware-vmsvc.log

user@server:~$

[archmangler]

Additional related issue: There does not appear to be a configuration parameter available to set the default permissions for the vmware tools logs. This blocks securing the system by removing read permissions for users. What is the recommended way to do this ?

[ravindravmw]

Yes, there is no real reason for the service log file to be world-readable. You can safely make the log file user and group readable only. However, problem is vmtoolsd will continue to create new files with the same old permissions. So, you will have to have some script to keep fixing it periodically or have a power script to fix the file permissions during power on because that is when vmtoolsd will most likely be creating the new log file.

Thanks for reporting this issue. I have filed an internal bug to fix it in a future release.

[archmangler]

@ravindravmw - thanks for the feedback on this. I think we have no choice but to wait for a future release, if we implement a script to modify the permissions, any potential exploit would simply take advantage of the intervals between. Therefore it would not mitigate a persistent threat.

[ravindravmw]

@archmangler I understand your concern.

Actually, I forgot to mention another much better way to use till we fix this. Systemd allows you to define UMask for the service - https://www.freedesktop.org/software/systemd/man/systemd.exec.html. So, you could edit /usr/lib/systemd/system/vmtoolsd.service and add following line in the [Service] section:

UMask=0027

This should make vmtoolsd.service create all files with no access to others. The only negative side effect is, if you have a need to create some world-readable file with vmtoolsd, that will no longer be possible. If you don't have such use case, then you should be able to use it as a workaround for the time being.

NOTE: Replace 'vmtoolsd.service' with the appropriate service name in case of Ubuntu.

[stanguturi]

Fixed in commit 8ffda7d

8ffda7d#diff-692dafe0e4d04e6b5f2c859ab9029c2a