vmplayer: cannot work with firejail

Description

Describe the bug

Steps to Reproduce

Steps to reproduce the behavior

Run in bash LC_ALL=C firejail vmplayer (LC_ALL=C to get a consistent output in English that can be understood by everybody)

Output:

Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
** Note: you can use --noprofile to disable default.profile **
Parent pid 11784, child pid 11785
Child process initialized in 91.13 ms
/usr/bin/vmware-modconfig: line 46: /usr/lib/vmware/bin/vmware-modconfig: Permission denied
Parent is shutting down, bye...

Expected behavior

VMware Worskstation Player can be launched with Firejail

Actual behavior

VMware Workstation Player cannot be launched with Firejail

Behavior without a profile

_What changed calling LC_ALL=C firejail --noprofile vmplayer in a terminal?_

Terminal output:

$ LC_ALL=C firejail --noprofile vmplayer
Parent pid 11836, child pid 11837
Child process initialized in 16.33 ms

A VMware Kernel Module Updater window opens:

Additional context

Any other detail that may help to understand/debug the problem

Environment

Linux Mint 20.3 Mate, based on Ubuntu 20.04 LTS with 5.4.0-152 generic kernel.
Firejail version 0.9.72, deb downloaded from SourceForge.
VMware Workstation PLayer for Linux 17.0.2.

Checklist

[x] The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
[x] I can reproduce the issue without custom modifications (e.g. globals.local).
[x] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
[x] The profile (and redirect profile if exists) hasn't already been fixed upstream.
[x] I have performed a short search for similar issues (to avoid opening a duplicate).
- [ ] I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
[ ] I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail vmplayer

``` Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 12092, child pid 12093 Child process initialized in 85.11 ms /usr/bin/vmware-modconfig: line 46: /usr/lib/vmware/bin/vmware-modconfig: Permission denied Parent is shutting down, bye... ```

Output of LC_ALL=C firejail --debug vmplayer

https://gist.github.com/MikeNavy/7bb73370626c8d6926b9f8d2340066fa

@MikeNavy on Jun 23:

Sorry, bad news. Even with this profile:

# from noprofile.profile
noblacklist /sys/fs
noblacklist /sys/module

allow-debuggers
allusers
keep-config-pulse
keep-dev-shm
keep-fd all
keep-var-tmp
writable-etc
writable-run-user
writable-var
writable-var-log

# from vmware.profile
noblacklist ${HOME}/.cache/vmware
noblacklist ${HOME}/.vmware
noblacklist ${RUNUSER}/vmware
noblacklist /usr/lib/vmware

mkdir ${HOME}/.cache/vmware
mkdir ${HOME}/.vmware
mkdir ${RUNUSER}/vmware
whitelist ${HOME}/.cache/vmware
whitelist ${HOME}/.vmware
whitelist ${RUNUSER}/vmware
include whitelist-common.inc
include whitelist-runuser-common.inc

Vmplayer window opens, but it cannot see any file and I cannot launch existing virtual machine.

Sorry, the ${RUNRUSER}/vmware part was wrong, it should be /var/run/vmware, though it shouldn't cause any issues considering the above profile.

As for debugging, note that whitelist both allows a path (such as ${HOME}/foo/bar) and enforces the whitelist on the base path (such as ${HOME}) at the same time, by hiding every sub path that is not whitelisted. And the whitelist .inc files do whitelisting on certain paths.

(The list of which paths are considered base paths is hardcoded, but they are basically the same as in whitelist-$path.inc)

So whitelisting commands (such as whitelist / include whitelist-) operating on the same base path need to be commented/uncommented together for things to work properly.

(mkdir and noblacklist lines should never break anything, so feel free to leave them uncommented)

For example:

# paths in ${HOME}
mkdir ${HOME}/.cache/vmware
mkdir ${HOME}/.vmware
whitelist ${HOME}/.cache/vmware
whitelist ${HOME}/.vmware
include whitelist-common.inc

# paths in ${RUNUSER}
mkdir ${RUNUSER}/vmware
whitelist ${RUNUSER}/vmware
include whitelist-runuser-common.inc

# paths in /var
whitelist /var/run/vmware
include whitelist-var-common.inc

So commenting/uncommenting one group at a time could help narrow down in which base path is the issue.

If in doubt, open the .inc files and see what paths they modify.

@kmk3

So commenting/uncommenting one group at a time could help narrow down in which base path is the issue.

If in doubt, open the .inc files and see what paths they modify. Hi,

It has been done, see https://github.com/netblue30/firejail/issues/5861#issuecomment-1604211251

But it did not work when I tried to launch Windows 10 VM: some peripherals were missing, there were Gtk critical errors.

I tested completely the noprofile.profile, and it seems to work, see https://github.com/netblue30/firejail/issues/5861#issuecomment-1604253472 (though I don't really know what is the security increase when using this.

To go further, commenting or uncommenting blindly a line in a profile is not the solution: tests are long, they can corrupt my Windows 10 VM image and I need to restore it after each test.

It would be preferable to write a profile by analyzing what vmplayer does:

it uses CPU, GPU, RAM and can allow CPU cores, RAM and video RAM to the virtual machine;
it has access to all system peripherals and, when they are connected to host with USB, can disconnect them from host and connect them to guest;
it writes in the file system, its logs are in "/var/log/vmware"
it writes in the user home: "/.vmware", "/.cache/vmware", and in the directory where is stored a virtual machine image and its files (user chooses the directory);
it can mount a disk image in write mode and install programs in this image (vmware tools), compact this disk image and defragment it;
it can share folders between host and guest, copy/paste files between host and guest, copy/paste contents between host and guest;
it can establish a network between host and guest (bridge, NAT, host-only) and needs read access to its kernel modules vmmon and vmnet;
it can access the network through host;
it can allow guest to use a printer configured in host;
... --> there are a lot of interactions between vmplayer and host operating system; it may be hard to sandbox it correctly; and sandboxing should not degrade the way it works (reduce its speed or anything impacting usability).

I don't know firejail in depth (I am just a user), but I am sure that some of Firejail settings would prevent / would allow vmplayer functions. The first step in writing a profile would be to write a specification for the profile, then to remove all the settings that could prevent vmplayer working, and to allow all that is necessary.

Trying to write a profile from the one of an obsolete no longer existing product (VMware Player), based on older virtualization technology and without all VMware Workstation Player functionalities is probably not the solution.

Regards,

Hi,

Some thoughts about VMware Workstation Player sandboxing.

Processes:

When it has been installed, VMware Workstation Player automatically launches 8 processes at boot: "vmnet-bridge", "vmnet-dhcpd" (two instances), "vmnet-natd", "vmnet-netifup" (two instances), "vmware-authdlauncher", "vmware-usbarbitrator". --> those processes are executed as root.

When it is launched, "vmplayer" is executed as user.

When the virtual guest is launched, a new process "vmware-vmx" is launched by "vmplayer" and executed as user.

Major risk may be associated to the 8 processes executed as root and to "vmware-vmx", which is launched by "vmplayer" and which communicates with the 8 root ones. They cannot be sandboxed with Firejail. Sandboxing those 9 processes would mean they would be isolated from the operating system.

Flatpaks and snaps allow this (flatpaked or snapped applications don't use system libraries, but flatpak runtimes or snap cores ones). But VMware Workstation Player is not available as a flatpak or as a snap.

Someone on internet suggests to install Docker inside Ubuntu, then Ubuntu inside Docker, then a virtual machne program (here qemu/kvm) inside Ubuntu, then Windows inside the virtualization program. It is right that, with this configuration, Windows will be fully isolated from the Ubuntu operating system running on the physical computer... But, with three operating systems, a containerizing program and a virtualizing one, needed resources are huge, and Windows will finally be very slow or unusable.

So, Firejail can only sandbox "vmplayer" process, one of the ten, run as user.

Risks:

Malware programs, once installed in a virtual or sandboxed environment, can detect they don't run on a physical computer and can adapt the way they function, in order to avoid be detected and, hypothetically, to use a vulnerability in virtual machine program to attack the host.

Looking at VMware Security Advisories, https://www.vmware.com/security/advisories.html shows 388 security advisories:

A keyword search with "Player" gives 139, among them 8 are critical or important and did affect VMware Workstation Player on Linux.

Reading the descriptions and attack vectors shows that the affected process is in most of cases "vmware-vmx", the one launched by "vmplayer" when a guest runs, and in one case ""vmnet-dhcpd" launched at system boot. And those two processes are not (cannot be?) sandboxed by Firejail.

This does not mean that sandboxing "vmplayer" is useless. Simply, during the latest 4 years, no successful attack involving "vmplayer" has been reported...

Risks mitigation:

When a security advisory is published by VMware, an update is available with a fix for the vulnerability. So, the first way to mitigate risks is to keep VMware Workstation Player updated. And this is in favor of the use of the bundle installation, with automatic check for updates enabled, and not in favor of the use of a package, always updated well after the bundle update, and without automatic update.

The second way to mitigate risks is to prevent malware programs in the guest: keep the guest machine updated, enable firewall, use antivirus (in Windows guest), practice safe browsing, use trusted sources etc., in the same way as if the guest was run on a physical computer.

The third way is to remove from virtual guest description any unused hardware or simulated hardware: having removed the CD-ROM device would have prevented one of the 8 mentioned attacks.

At this point, sandboxing "vmplayer" (which is not the process that runs the guest) with Firejail might offer an extra security (at least for the peace of mind), but doesn't appear paramount. The "noprofile.profile" works well with "vmplayer", that's probably enough.

Regards,

~~PS1: AppArmor profiles for the 10 processes (8 different processes with two having two instances) might be a good sandboxing approach.~~

PS2: "vmware-vmx" process is the one that needs to be sandboxed; it is the process which runs the guest, and, since is the process in contact with the guest, it is the one targeted by attacks. It could be sandboxed by Firejail using a symlink (in the same way as firecg does) and a "vmware-vmx" profile.

PS3: There is no "vmware-vmx" executable installed on the operating system. It seems that "Virtual Machine Executable (VMX) process", "Virtual Machine Monitor (VMM) process" and "Mouse Keyboard Screen (MKS) process" make up a group running in the VMkernel. VMkernel is a POSIX-like operating system developed by VMware. It acts as a liaison between virtual machines and the physical hardware that supports them.

--> No chance to sandbox VMware Workstation Player processes without sandboxing the whole VMware Workstation Player software.

PS4: The only wholly sandboxed virtual machine program I know is Gnome Boxes, in its flatpak version.

As analyzed, sandboxing VMware Workstation Player with Firejail does not seem possible:

"vmplayer" is the only executable installed on the system, and it be run satisfactorily with Firejail "noprofile.profile".
But the 8 processes launched at boot and the "vmware-vmx" one, launched at guest run, cannot be sandboxed by Firejail. Among these processes, "vmware-vmx" and "vmnet-dhcpd" have concentrated all the critical and important security advisories from 2020 up to now.

The only wholly sandboxed virtual machine program I know is Gnome Boxes, in its flatpak version.

Which used libvirt from the host IIRC. => Only the UI is sandboxed.

The complexity of the most guest-to-host exploits is a few times bigger than the complexity of the most sandbox escapes (be it a vulnerability or a hole by design).

This means in the most situations you try to stop somebody how just jumped over a 5m wall with a 1m wall.

The only wholly sandboxed virtual machine program I know is Gnome Boxes, in its flatpak version.

Which used libvirt from the host IIRC. => Only the UI is sandboxed.

The complexity of the most guest-to-host exploits is a few times bigger than the complexity of the most sandbox escapes (be it a vulnerability or a hole by design).

This means in the most situations you try to stop somebody how just jumped over a 5m wall with a 1m wall.

Hi,

You are right when you say Gnome Boxes flatpak uses libvrt, but you are wrong when you say it uses the operating system one. As any flatpak application, Gnome Boxes flatpak has all what it needs to work, including libvrt, in the application itself or in the runtime it uses: --> it runs on my system, without qemu and libvrt installed

No flatpak application can use operating system libraries: flatpak applications are completely isolated from the operating system, and are completely isolated each other:

Principles are the same with snaps, snapped applications use the libraries available in cores. The difference between flatpaks and snaps is the sandboxing tool: flatpaks rely on Bubblewrap, while snaps rely on AppArmor.

And Gnome Boxes is also available as a snap.

Regards,

Gnome Boxes flatpak has […] libvrt, in the application itself or in the runtime it uses:

Right on that.

I remembered wrong. I thought libvirt uses a name on the system bus as a hard factor in it's architecture.

flatpak applications are completely isolated from the operating system,

No!

The manifest of gnome-boxes for example contains multiple options that punch escapeable holes in the sandbox (under some conditions like with fallback-x11).

        "--share=ipc",
        "--socket=fallback-x11",
        "--share=network",
        "--device=all",
        "--filesystem=host",
        "--talk-name=ca.desrt.dconf",

(Re-closing as "not planned" since nothing was changed in firejail)

netblue30 / firejail