mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5861] vmplayer: cannot work with firejail #3110
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3110
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MikeNavy on GitHub (Jun 19, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5861
Description
Describe the bug
Steps to Reproduce
Steps to reproduce the behavior
LC_ALL=C firejail vmplayer(LC_ALL=Cto get a consistentoutput in English that can be understood by everybody)
Output:
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 vmplayerin aterminal?
Terminal output:
A VMware Kernel Module Updater window opens:
Additional context
Any other detail that may help to understand/debug the problem
Environment
Checklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
Output of
LC_ALL=C firejail vmplayerOutput of
LC_ALL=C firejail --debug vmplayerhttps://gist.github.com/MikeNavy/7bb73370626c8d6926b9f8d2340066fa
@rusty-snake commented on GitHub (Jun 19, 2023):
No, it has no profile. And the default profile does not work with privileged programs.
@kmk3 commented on GitHub (Jun 20, 2023):
(Offtopic)
@MikeNavy
Please see the following links for how to format code blocks in markdown:
@kmk3 commented on GitHub (Jun 20, 2023):
Does it work if you run that outside of firejail first (or manually installing
the kernel modules yourself) and then try to run
vmplayerin firejail later?@rusty-snake on Jun 19:
There are a few vmware-related profiles, but not vmplayer.profile:
vmplayermay be the same thing asvmware-player, in which case it could bebe added as a redirect to vmware.profile.
@MikeNavy What is the output of:
@MikeNavy commented on GitHub (Jun 20, 2023):
Hi,
Concerning profiles:
"vmplayer" is the command that launches VMware Workstation Player.
"VMware Workstation Player" is the actual name of "VMware Player", it has been changed years ago by VMware (former products "VMware Player" and "VMware Workstation" have been merged in one, "VMware Workstation Player"; now existing products are "VMware Workstation Player" and "VMware Workstation Pro").
"VMware Workstation Player" Product page: https://www.vmware.com/content/vmware/vmware-published-sites/us/products/workstation-player/workstation-player-evaluation.html.html
Revision 17.0.2 is the latest one.
Outputs:
"shell": such a command does not exist in Ubuntu.
"which -a vmplayer" output:
/usr/bin/vmplayer
/bin/vmplayer
"which -a vmware-player vmware-view vmware-workstation vmware" output:
no output
Concerning kernel: after each kernel change, VMware Workstation Player asks, at its first launch, to compile and install two vmnet modules in the kernel. Of course, this has been done for my latest 5.4.0-152 generic kernel, and VMware Workstation Player works when launched without firejail ("vmplayer" or "vmplayer %U" command). It is only when launched with "firejail --noprofile" that I see the "VMware Kernel Module Updater" window.
Regards,
MN
@MikeNavy commented on GitHub (Jun 20, 2023):
Hi,
I have done the following test:
I have copied "/etc/firejail/vmware-player.profile" to my home "/.config/firejail/" directory, then renamed "/.config/firejail/vmware-player.profile" to "/.config/firejail/vmplayer.profile".
I have then launched VMware Workstation Player with the following command in a terminal:
firejail vmplayer.Here is the output:
Now, "vmware.profile" is read, but there are errors.
Here is the output of
LC_ALL=C firejail --debug vmplayer:https://gist.github.com/MikeNavy/d7d794334eea6d5f65543ddeb934143e
Here is "/etc/hosts" ownership:
"/etc/hosts" is owned by my username (michel), user with superuser rights. It is not owned by root, since I use hosts as an IP addresses filter and update it regularly using a bash (I update hosts in my home, then copy it to "/etc/hosts" with
sudo mv hosts /etc/hostscommand).Regards,
MN
@kmk3 commented on GitHub (Jun 20, 2023):
Note that changing the ownership of system files may make it easier for
malicious programs to modify them.
Since it is being modified in the user home and since
sudois being usedanyway, I'd suggest to make it owned by
root:rootbefore copying it to /etc.Example:
Does it run if you change the permissions?
@MikeNavy commented on GitHub (Jun 20, 2023):
Hi,
I have added
sudo chown root:root hostsin my bash file, before thesudo mv hosts /etc/hosts, and now my "/etc/hosts" is owned by root.I have done the following test:
firejail vmplayer.Terminal output in debug mode is here:
https://gist.github.com/MikeNavy/7d006729b482568dcf3f20eaaafd14f8
Regards,
MN
PS: VMware Workstation Player does work without Firejail
@kmk3 commented on GitHub (Jun 20, 2023):
I'd try commenting parts of the profile until it works.
These includes might be related to the issue:
@MikeNavy commented on GitHub (Jun 20, 2023):
Hi,
No, I think something prevents
vmplayerto read / access its modules installed in the kernel: without Firejail,vmplayerwants to compile and install two modules in the kernel just once, after a new kernel has been installed.And it has been done.
Without Firejail, those "VMware Kernel Module Updater" windows do not appear at each launch and don't claim for Kernel Headers or for GCC. The application window (see capture above) opens directly.
I don't want to take the risk that enabling something would induce a new compiling of vmnet modules and might break the working installation (working without Firejail). So, I will not test the profile with comments before these "disable-..." lines: the existing vmware profile is just not designed nor tested for existing vmware applications...
Regards,
MN
@rusty-snake commented on GitHub (Jun 20, 2023):
Maybe the implicit blacklist of /sys/module
@MikeNavy commented on GitHub (Jun 20, 2023):
Hi,
I have been using VMware Workstation Player for years on Linux Mint or Ubuntu (several versions before 17...) and it has always asked to compile and install modules in the kernel at the first launch after a kernel change.
(And I think it is also the way WMware Workstation Pro works)
A firejail profile for VMware Workstation Player should so allow to read the kernel, but also to install modules in the kernel.
Regards,
MN
@rusty-snake commented on GitHub (Jun 20, 2023):
TBH, if you allow to install own modules into the kernel, you do not need a sandbox.
You sandbox to limit privileges. The kernel is the most privileged part of your system after the firmware (BIOS/UEFI and ME/PSP).
@kmk3 commented on GitHub (Jun 20, 2023):
@MikeNavy on Jun 20:
@rusty-snake on Jun 20:
Yes, if a program can run arbitrary code in the kernel, then sandboxing can't
do much.
But if the goal is to sandbox VMs rather than vmware itself, then a way to do
it might be to:
kernel modules and then exit afterwards
@kmk3 commented on GitHub (Jun 20, 2023):
Also, installing kernel modules is not something that random programs should be
doing on a whim, especially if that is intended to be done after installing a
certain package.
That is usually done by creating one or more hook scripts inside of the
package, which are then executed directly by the system package manager (such
as
apt) whenever the relevant package is upgraded.I was going to suggest reporting it to them as a packaging bug, but it appears
that vmware doesn't even provide a proper package for any distribution; the
user is supposed to just download a random binary file from a third-party
website and run it as root.
If security is a concern, then I'd try my best to avoid vmware and use
something like qemu or virtualbox instead.
@rusty-snake commented on GitHub (Jun 20, 2023):
OT rant on VMware: Moreover this random 3p binary installs to /use/lib rather than /use/local or /opt. And fails to provide a function uninstall method. You can only install VMware products in a VM/Container/chroot if you want a stable system. And want to be able to unstinstall without OS reinstall.
@MikeNavy commented on GitHub (Jun 21, 2023):
@ kmk3
Yes, I agree with this. Of course, it prevents the use of firecfg (or firecfg whould not write symlink for vmplayer).
Regards,
MN
@MikeNavy commented on GitHub (Jun 21, 2023):
Hi,
VMware has a long (20 years) and good reputation. I use VMware Workstation Player because I trust VMware. I have always a fresh system backup that I could use after a VMware update, or a VMware modules installation in the kernel, if something went wrong. I also use Tripwire, to check that changes are limited to what they should be.
VMware Workstation Player is provided as a large file, a Linux executable installer, which fits any Linux version. It is the way VMware solved the problem to avoid compiling one version for each existing distribution (other ways are flatpaks, snaps, AppImages...). At the opposite, VirtualBox provides 12 different packages, and each distribution provides its own.
I have compared VMware and VirtualBox to install a Windows 10 Pro guest in Linux Mint host:
Qemu is very difficult to set up, in command line mode only. It is much easier to use Gnome Boxes, a GUI for libvrt/qemu. And Gnome Boxes in its flatpak version offers great security.
Speaking of security, virtual machines programs, per se, offer an excellent isolation between host and guest operating system. Of course, they can have, as any program, vulnerabilities that could be used by guest to attack host. This is hypothetical, particularly if guest and host are different operating systems. Sandboxing is here to reduce this hypothetical risk. Updating regularly the virtual machine program is another way to reduce this risk.
At the opposite, "pseudo" virtual machines programs are dangerous: Windows 10 Pro and Windows 11 Pro offer WSL/WSL2 (Windows Subsystem Linux), with a great facility to use a Linux distribution such as Ubuntu directly on Windows. Operating systems isolation is poor, or non-existing, and there are attacks targeting Windows through the Linux operating system running in WSL/WSL2.
Regards,
MN
@kmk3 commented on GitHub (Jun 21, 2023):
@MikeNavy on Jun 21:
Fixed in #5865.
@MikeNavy on Jun 21:
Creating one package per distribution is not really necessary in practice. In
fact, there is no need to create any package at all; as long as a normal
tar/zip archive (rather than an executable) is provided, the rest can generally
be done by the packagers of each distribution. If that was fixed, it's more
likely that someone would have created a PPA with a package containing proper
hooks by now.
Which is why this is baffling, since even if the archive only contained binary
files (so it's not even necessarily about being libre vs proprietary), as long
as they were properly split (such as the main program from the module
installer), it would be easier to package it properly.
Someone managed to do it in the AUR, but it seems to be much more complicated
(why does it need to modify an sqlite database during packaging?) compared to
virtualbox (and especially to other packages in general):
Yes, regardless of the interface, I'd consider using qemu to be an improvement.
As for the rest, it's good to know about the performance/usability differences,
but to be clear I'm not a big fan of virtualbox either, it's just that is seems
to be less proprietary overall compared to vmware and it is properly packaged
in more distributions.
Yeah, WSL seems like the worst of both worlds.
@kmk3 commented on GitHub (Jun 21, 2023):
@Neo00001
@ra1nb0w
Hello, I see that you added/updated the vmware profiles in the following pull
requests:
Do the profiles still work for you?
@ra1nb0w commented on GitHub (Jun 21, 2023):
Yes, I am still using it.
@kmk3 commented on GitHub (Jun 21, 2023):
Nice, in what distribution do you use it?
Have you ever had issues with vmware compiling/installing kernel modules?
Example:
@ra1nb0w commented on GitHub (Jun 21, 2023):
Archlinux updated today and vmware-workstation from aur (
vmware-workstation 17.0.2-1)No issue with kernel modules.
This is my actually
.config/firejail/vmware.local@kmk3 commented on GitHub (Jun 21, 2023):
So it seems that indeed only the AUR has vmware properly packaged.
If anyone wants to package it for Debian/Ubuntu, that AUR package seems like a
good starting point.
Misc: It would be kind of interesting to see that happen, as it's usually the
other way around, in that the official package is a .deb and someone turns that
into an Arch package (though it would still be preferable to have an official
package of course).
Anyway, thanks for the details.
@MikeNavy commented on GitHub (Jun 21, 2023):
@kmk3
Hi,
Reading this page, https://aur.archlinux.org/packages/vmware-workstation, shows that vmware modules need to be installed in kernel:
And a user says in his comments that the bundle works, while it is not the case with the AUR package:
Regards,
MN
@ghost commented on GitHub (Jun 21, 2023):
@MikeNavy
Greetings
Please don't quote only half the story. One comment above is an explanation for what happened. In the mean time I've built the AUR package without any trouble. Due to the dependency on
dkmsthe vmware kernel modules are built and installed via a pacman post-install hook. So that's BEFORE any firejailing comes into play. After modprobe'ing vmw_vmci & vmmon the application works with the vmplayer.profile from #5865 or when using --profile=vmware on CLI. All this confirms what @ra1nb0w already kindly stated: no problems on Arch Linux with sandboxing VWMare...I can understand your point of view, up to a point. It's your decision to not try to debug the existing profile by commenting lines as suggested by @kmk3. Yet you do expect a tested/working firejail profile, which - I agree - is a reasonable expectation, no argument there. But these profiles don't come falling from the The Great SandBox Skies magically :)
Collaborators run the exact same 'risks' when creating/testing a profile. Let's reopen this issue and try to determine where the issue on Linux Mint stems from. Building the required gcc 12.2.0 right now on a Ubuntu machine I dusted off. Will report back.
@kmk3 commented on GitHub (Jun 22, 2023):
Quoting it here for reference:
jihem commented on 2023-06-03 17:01 (UTC)
(For reference, the comment is by the current package maintainer)
@MikeNavy commented on GitHub (Jun 22, 2023):
@glitsj16
Hi,
OK, you have succeeded in building a package for AUR where "the vmware kernel modules are built and installed via a pacman post-install hook".
What does arrive when kernel changes? With Ubuntu, after each kernel change, vmplayer requests at its first launch to compile and install vmmon and vmnet modules in the kernel; and it is mandatory to click on "install button" to have vmplayer working. How did you manage this?
Concerning testing: I could comment the four "disable-..." lines as suggested and test the modified profile. But I don't know how to cope with this @rusty-snake comment, the read access to kernel might be prevented by "Maybe the implicit blacklist of /sys/module". How to disable this implicit blacklist?
Moreover, what would be the security improvement given by sandboxing without "disable-devel.inc", "disable-exec.inc", "disable-interpreters.inc", "disable-programs.inc" and with noblacklist of "/sys/module"?
Finally, testing needs a lot of time: I have to test that vmplayer is launched; that, once launched, it can launch a virtual guest; that the virtual guest works correctly (display resizing, all display modes, files copy/paste, contents copy/paste, shared folders, hardware disconnecting from host and connecting to guest, using host printers...); that a new virtual guest can be created, and VMware tools installed in the guest...
These are things I could do with a profile having some chances to work, and still giving an improved security.
Regards,
MN
@kmk3 commented on GitHub (Jun 22, 2023):
From a loose glance at the vmware-workstation AUR repository, this is more or
less how it seems to happen:
It adds its own Makefile (to compile the modules) and dkms.conf files into
/usr/src/vmware-workstation. Then it extracts and copies the vmware modules
(from the vmware executable) into that directory as well.
Whenever pacman upgrades the kernel (or an adjacent package), it runs something
to update the dkms, which looks into that directory and runs
maketorebuild/install the kernel modules.
It likely tells vmware (through a config file) to not try to update the modules
(or that they are always updated), so that only pacman gets to update the
modules.
To have a better understanding, I'd suggest cloning the AUR repository and
reading the files inside of it:
Try adding this to the profile:
Though that might only be necessary if vmware tries to do something with the
kernel modules itself (it shouldn't be needed if you update the modules before
running vmware in firejail).
These includes are arguably not as important for security as the rest of the
profile. Also, it likely isn't necessary to disable all of them for it to
work, just to go and comment lines in the profile until you find exactly which
line(s) are causing issues.
Yes and the quality of the profiles ultimately depends on users testing and
maintaining them. No one else can really make the profiles be as secure and as
usable as possible other than the people that regularly use the programs that
the profiles are for.
@ghost commented on GitHub (Jun 22, 2023):
The PKGBUILD only copies the
sourcefiles for the kernel modules into /usr/src/vmware-workstation, not the built modules themselves. That part is left todkmsas usual. The actual modules are indeed built via a post-install hook that targets linux kernel headers. They end up in /usr/lib/modules/6.3.8-foo/updates/dkms/{vmmon,vmnet}.ko.zst, also as usual for dkms modules. There's nothing really special about this. Debian-based systems have similar apt/dpkg hooks. But that only works for regular.debpackages and not for the.bundlethat VMWare offers.I fully agree with @kmk3 that probably the only thing that needs checking is VMWare's ability to confirm those kernel modules are there from within the sandbox. This is the
/sys/modulepart. You might use an extrawhitelist /sys/moduleandread-only /sys/moduleto keep protecting this path. That's what blender.profile does for AMD GPU support:1003dee6ff/etc/profile-a-l/blender.profile?#L21-L24Still building gcc 12.3.0 on my old Ubuntu box to confirm all this. Should have more details later today.
@MikeNavy commented on GitHub (Jun 22, 2023):
Hi,
I have copied the "vmware.profile" from "/etc/firejail/" to "~/.config/firejail/" and renamed it "vmplayer.profile".
Then I have done the following tests:
Then I launch "LC=ALL firejail vmplayer" in a terminal.
VMware Kernel Module Updater asks for Kernel Headers.
Terminal output:
whitelist /sys/moduleand kept the former four lines commented.No vmplayer window.
Terminal output:
whitelist /sys/moduleand replaced it byread-only /sys/module, still keeping the former four lines commented.Result is the same as with test 1.
Regards,
MN
@MikeNavy commented on GitHub (Jun 22, 2023):
@glitsj16
Hi,
Concerning the deb packaging: it is not proposed by VMware, and it is not done by others (Ubuntu, PPAs...) since VMware is a proprietary software. If we put apart the technical problems, there is a licensing one: VMware does not license the right to diffuse or change its programs. (Some ones could argue that, since VMware officially uses software with GPL V2 or GPL V3, GPL has been propagated to all VMware code...)
This explains why there is no deb available.
The solution to copy the sources of vmmon or vmnet at installation will not work when VMware updates their sources; it could arrive when a new revision is available (e.g., from 17.0.1 to 17.0.2) or when a new major version is available (e.g. from 16 to 17). I have just installed VMware Workstation Player bundle once on my Linux Mint 20.3, at version 15.5: all the updates between 15.5 and 17.0.2, including major versions changes, have been done from the application itself, with the "check for updates" function. Meanwhile, vmmon and vmnet sources may have changed.
So, a packaging solution could work only if the version is a stable one, updated through package manager, and with check for updates function disabled.
Concerning vmmon and vmnet modules, they are used by VMware in order to build the network between host and guest (bridge, nat or host-only).
Regards,
MN
@MikeNavy commented on GitHub (Jun 22, 2023):
Another test:
I have written a very minimal restricting profile using Firetools, and pasted its content to "~/.config/firejail/vmplayer.profile":
No VMware window opens.
Here is terminal ouptut:
So, could "disable-common.inc" be responsible ?
New profile, without disable-common.inc:
When I launch
LC=ALL firejail vmplayer, the usual VMware Kernel Module Updater asks for Kernel Headers:Here is terminal output:
Is Firejail compatible with VMware Workstation Player?
Regards,
MN
@kmk3 commented on GitHub (Jun 22, 2023):
@MikeNavy on Jun 22:
Did the profile include the
noblacklist?You can ignore those
whitelist/read-onlycommands until the profile works,as they are intended for hardening in this case.
@MikeNavy on Jun 22:
That file blacklists /usr/lib/vmware, which is undone in vmware.profile, so no.
Does it work without disable-common.inc and with the following added?
@kmk3 commented on GitHub (Jun 22, 2023):
(Offtopic)
@MikeNavy on Jun 22:
As I mentioned before, the license is unrelated to the packaging format.
Steam and Zoom are proprietary and both offer .deb packages, for example. Wine
is libre and offers a PPA repository for Ubuntu.
Unless shown otherwise, the only thing stopping vmware from providing a proper
archive and/or package is themselves.
It will work because the AUR package is updated whenever a new version comes
out and it always points to a specific version (that is, to a specific file and
its checksum).
That is how basically all packaging on Linux works (except for packages
intended to build in-development versions), regardless of whether the files
downloaded during packaging are entirely source code or binaries.
Yes, updates through the program are disabled because the package manager is
the one responsible for updating packages. That is usually done when packaging
any program with a built-in update checker, including for things like Firefox.
You could think of the AUR package as a more "enterprise"/stable/IT-managed
version of the installer.
@MikeNavy commented on GitHub (Jun 22, 2023):
Hi,
Latest trial with the following "vmplayer.profile":
When launching
LC=ALL firejail vmplayer, no VMware window opens.Terminal output:
Note that "VMware Workstation Player" and "VMware Workstation Pro" may not work the same way as older products "VMware Player" and "VMware Workstation": they use "VMware Sphere" hypervisor virtualization technology, a recent technology, more recent than "VMware Player" and "VMware Workstation".
Regards,
MN
@kmk3 commented on GitHub (Jun 22, 2023):
See this:
@MikeNavy commented on GitHub (Jun 22, 2023):
Hi,
Trial with
vmware.profile, copied to "~/.config/firejail", renamedvmplayer.profile, and modified as follows:When I launch vmplayer with
LC=ALL firejail vmplayer:VMware player opens the usual VMware Kernel Module Updater requesting for Kernel Headers,
Terminal output:
Regards,
MN
@kmk3 commented on GitHub (Jun 22, 2023):
Hmm that is surprising; I didn't think it would fail with only that.
Please try it with noprofile.profile, which is supposed to be as
permissive as possible:
Note: There is no need to modify any profile, just use that exact command line.
If that fails, then the issue is not with any profile but with firejail itself.
Sorry, I should have suggested it before.
@kmk3 commented on GitHub (Jun 22, 2023):
Also, doesn't vmware write any logs?
They might contain more details about what exactly vmware is failing to access,
so if you could find and post them it could make debugging much easier.
Note: If the log contains too many lines to put in a comment, you can upload
the log file itself (drag and drop) in the comment.
@MikeNavy commented on GitHub (Jun 23, 2023):
Hi,
Test with
LC_ALL=C firejail --profile=noprofile vmplayerFinally, the VMware Workstation Player opens:
So, there is hope a working profile can be created!
Here is terminal output:
Here is vmplayer log: https://gist.github.com/MikeNavy/eb0153dbb042ae131a884f3d4ea0b2ed
Here is vmplayer latest failed trial (yesterday) log: https://gist.github.com/MikeNavy/45d8d0bb5a02dfb41d21768fa001841e
Here is vmplayer without firejail log: https://gist.github.com/MikeNavy/5bb55dcf0ec67c58e48a617187d47d38
NB: those logs are USB arbitrator logs, "vmware-usbarbxxxx.log", found in "/var/log/vmware". Other logs are found in virtual machines directories, and log the VM functionment.
Regards,
MN
@kmk3 commented on GitHub (Jun 23, 2023):
Nice.
Interesting, this path seems to be missing in the profile.
Please try with only the following in the profile (for example, in
vmplayer.profile):
Then comment each line in the
from noprofilesection until it breaks to findthe offending line.
If it still works after commenting the entire section, try adding more lines
from
vmware.profileinto thefrom vmwaresection.@MikeNavy commented on GitHub (Jun 23, 2023):
Hi,
Using the proposed profile works.
Then I have tried to comments lines in the section "# from noprofile.profile"; I have commented them one at a time.
When this line is commented "# allow-debuggers", the VMware Kernel Module Updater opens, asking for kernel headers.
No other commented line in "# from noprofile.profile" breaks vmplayer launch.
Regards,
MN
@MikeNavy commented on GitHub (Jun 23, 2023):
Hi,
VMware Player still opens with the following
vmplayer.profile:Note that I have not tested the full working, just that vmplayer window opens.
Regards,
MN
@ghost commented on GitHub (Jun 23, 2023):
Apologies for the later-than-planned report from my
VMWare on Ubuntutesting. After a terrible ordeal to get the modules built I've got a working profile. Obviously that needs more extensive usage by someone that uses this app regularly and is familiar with it (which I'm not). Comments/questions/answers etcetera: later. This gave me a bit of a headache so I'm going out for a long stretch. Compared with the breeze it is on Arch Linux and its AUR package, well, enough said. Here goes:@MikeNavy commented on GitHub (Jun 23, 2023):
Hi, Profile has been edited (see former message); there was a bug in copy/paste.
Rename attached file as "vmplayer.profile".
vmplayer.txt
MN
@ghost commented on GitHub (Jun 23, 2023):
@MikeNavy
We're pretty close IMO. Take the time you need to test things more thoroughly in your regular workflow with VMWare. We can polish things later. Have a nice weekend!
@MikeNavy commented on GitHub (Jun 23, 2023):
Hi,
Things are not so good.
With the latest profile, vmplayer window opens but it can't see any file and I can't open existing virtual machine, in a subdirectory of my home.
Terminal output:
I need to test more...
@MikeNavy commented on GitHub (Jun 23, 2023):
Sorry, bad news.
Even with this profile:
Vmplayer window opens, but it cannot see any file and I cannot launch existing virtual machine.
(note that "Windows 10 x64" is not seen in the screen capture, while it was when I used
LC_ALL=C firejail --profile=noprofile vmplayer; and "File / Open a virtual machine" does not see any file).Terminal output:
--> At the moment, vmplayer can work only with firejail with
LC_ALL=C firejail --profile=noprofile vmplayer@MikeNavy commented on GitHub (Jun 23, 2023):
Latest testing:
firejail vmplayer, vmplayer opens, it displays "Windows 10 x64" VM.Since my Windows 10 VM can be damaged, I replace it with the backed up one.
Regards,
MN
@MikeNavy commented on GitHub (Jun 23, 2023):
New test with
LC_ALL=C firejail --profile=noprofile vmplayer:Vmplayer window opens, I can launch "Windows 10 x64 VM"; shared folders work, file copy/paste works, content copy/paste works, Gimp (demanding on GPU) works, Windows Update works.
In terminal output, no GTK critical error, but warnings:
To compare with previous test, I replace my "Windows 10 x64" VM by the backed up one, and I launch vmplayer from a terminal.
Terminal output:
Both terminal logs are similar. The "Gtk-WARNING" occur during Windows shutdown.
At the moment, I would say that with "firejail --profile=noprofile vmplayer" command, vmplayer and Windows 10 seem to work the same way as vmplayer without firejail (note: I have not tested VM creation).
Regards,
MN
@kmk3 commented on GitHub (Jun 23, 2023):
@MikeNavy on Jun 23:
Sorry, the
${RUNRUSER}/vmwarepart was wrong, it should be/var/run/vmware,though it shouldn't cause any issues considering the above profile.
As for debugging, note that
whitelistboth 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-) operatingon the same base path need to be commented/uncommented together for things to
work properly.
(
mkdirandnoblacklistlines should never break anything, so feel free toleave them uncommented)
For example:
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.
@MikeNavy commented on GitHub (Jun 23, 2023):
@kmk3
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:
--> 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,
MN
@MikeNavy commented on GitHub (Jun 24, 2023):
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,
MN
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.
@MikeNavy commented on GitHub (Jun 25, 2023):
As analyzed, sandboxing VMware Workstation Player with Firejail does not seem possible:
@rusty-snake commented on GitHub (Jun 25, 2023):
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.
@MikeNavy commented on GitHub (Jun 26, 2023):
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,
MN
@rusty-snake commented on GitHub (Jun 26, 2023):
Right on that.
I remembered wrong. I thought libvirt uses a name on the system bus as a hard factor in it's architecture.
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).@kmk3 commented on GitHub (Jun 27, 2023):
(Re-closing as "not planned" since nothing was changed in firejail)