Multipass on Windows - permissions, privileges, etc

Multipass
1

I’ve just recently become aware of Multipass and made a few attempts to use it on a Windows test machine.

I have a few problems and questions revolving around the required permissions for installing and using Multipass.

For instructions demonstrating

  1. Why does Multipass run as admin? Do multipassd.exe and sshfs_server.exe have to run as NT AUTHORITY\SYSTEM?

I’m assuming multipassd.exe basically performs the various multipass.exe commands (launch, start, stop, suspend, exec, etc.). All of them can be performed as a non-admin. I don’t know about VirtualBox, but I can do all those things with Hyper-V from a non-admin account as long as I’m a member of Hyper-V Administrators, which I am.

I don’t run as admin things that don’t have to run as admin.
This is a major issue for me and a major reason that prevents me from using Multipass outside of the test machine, even before comparing features in Multipass and alternatives.

Note: I’m not saying that there’s no reason to exploit Hyper-V to get admin privileges from being a member of Hyper-V Administrators. I honestly don’t know. But it obviously doesn’t matter.

There’s a difference between the ability of malicious code to use the Hyper-V Administrators permissions to do bad things and being a standard admin/SYSTEM that can completely mess up my system by mistake.

If I trust Multipass to not be malicious and not try to get system control from being a member of Hyper-V Administrators, it doesn’t mean that I trust Multipass not to have bugs that can cause harm to my machine by accident, when everything runs as LOCAL_SYSTEM.

There are already examples of this today: Putting Multipass’ data in C:\Windows\System32\config for starters. You’re not Windows developer so you don’t know how wrong it is to put your stuff in there. Fine. But without admin rights you wouldn’t be able to do that nonsense in the first place.

The same problems happens with mounts: Since sshfs_server.exe runs as NT AUTHORITY\SYSTEM it’s too easy to mount a privileged directory into the guest and corrupt it from within. There’s no reason for that either.

The principle of least privlege is important not only for security but also for stability and safety.

  1. Why does installing Mutipass require admin permissions?

Let’s ignore the previous issue and say Multipass has to run as admin. Why does the installer has to run as admin?

There are countless programs that really need admin permissions to run, but still provide binaries in ZIP files etc. The installer adds the stuff in HKLM\SYSTEM\CurrentControlSet\Services\Multipass? That’s the big deal? I’ll do it myself, and if you want so much to save me the time give me PowerShell script that does that.

Examples range from utilities such as WizTree, Everything, Sysinternals Suite, FileTest to “system-level” tools such as even Docker.

Docker is actually a very good candidate for comparison. It’s the same kind of tool, but I cant download a Docker ZIP and “install” it using a tiny PowerShell script from Mirantis, or even do everything myself, since it’s so simple.

Why can’t I do that with Multipass?

  1. There’s still no way to build Multipass for Windows.

Even if I were inclined to fix all of that myself, there’s still now way to do it.
A GitHub issue from April 2020 (#1465) was closed with:

the macOS and Windows parts of Multipass are currently closed source, the lack of build instructions is the result of that.

And basically the same on May 2021 (#2087):

I’m afraid those bits are currently closed source.

I’ll dupe this to #1851.

But #1851 itself, titled “Add README message indicating that windows and Mac are unbuildable due to closed source components” is still open and we’re left to wonder what are those components.

While searching for information I came across this message regarding macOS:

The reason why we currently require admin privileges is that through Multipass you can circumvent file permissions (because you can mount arbitrary paths from the host into the instance).

Multipass itself, generally, needs to run with admin privileges to be able to use the hardware features.

As it stands, there’s no reliable way for Multipass to know what your user has access to, and what should be prevented.

Long-term we have some ideas on how to work around that:

  • the socket will be world-accessible, but you’ll need an access token
  • “server side” mounts will become privileged
  • we’ll introduce “client side” mounts, where the source side of the mount runs with your user’s privileges
  • for VM drivers that don’t require admin privileges, we’re thinking of introducing a “user” instance of Multipass

Even if that’s true for macOS it’s not for Windows. A simple way to realize this is to Frankenstein a Multipass installation the following way:

  1. Install Multipass the usual way. I used multipass-1.8.0+win-win64.exe on Windows 10 Enterprise 21H1 (19043.1348).
  2. Set MULTIPASS_STORAGE to C:\Foo (which is accessible by all users).
  3. Create a standard, non-admin, user and add it to the Hyper-V Administrators group.
  4. Give that user full control over C:\Windows\System32\config\systemprofile and all it’s subitems. That’s because even with MULTIPASS_STORAGE multipassd.exe stores multipassd.conf in there and expects it to be writable. Maybe other stuff too.
  5. Change the Multipass service to run as that user instead of as LOCAL_SYSTEM.
  6. Restart the Multipass service.

Voila.

Everything mostly works with Multipass (both multipassd.exe and sshfs_server.exe) running as non-admin. launch, shell and mount work. Yes, mount works as non-admin. If I try to mount a folder that the non-admin Windows user doesn’t have access to I get an error:

PS C:\Users\AdminUser> multipass.exe mount  .\AppData\Local\ primary:/mnt/foo
mount failed: source "C:/Users/AdminUser/AppData/Local" does not exist

Not the best error message, but certainly better than having complete access to everything.
if I mount System32 it works, but respect permissions in the sense that the guest can only read but not write to the mount (since sshfs_server.exe on the host can’t write there).

This is how it’s supposed to work.

There is a small issue with the start command. When installing a new image using launch is start automatically, but starting a stopped image gives a silly error:

PS C:\> multipass.exe start primary
start failed: Cannot determine if Hyper-V is available on this system.
PS C:\> Start-VM -Name primary
PS C:\> multipass.exe info primary
info failed: ssh connection failed: 'Timeout connecting to primary.mshome.net'
PS C:\> multipass.exe info primary
Name:           primary
State:          Running
IPv4:           172.31.183.15
Release:        Ubuntu 20.04.3 LTS
Image hash:     939be728cbc7 (Ubuntu 20.04 LTS)
Load:           0.88 0.22 0.07
Disk usage:     1.3G out of 4.7G
Memory usage:   150.9M out of 916.9M
Mounts:         .........
PS C:\> multipass.exe shell primary
Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-90-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Wed Nov 10 23:52:54 GMT 2021

  System load:  0.68              Processes:             116
  Usage of /:   27.7% of 4.67GB   Users logged in:       0
  Memory usage: 21%               IPv4 address for eth0: 172.31.183.15
  Swap usage:   0%


1 update can be applied immediately.
To see these additional updates run: apt list --upgradable


Last login: Wed Nov 10 23:11:01 2021 from 172.31.176.1
ubuntu@primary:~$

This would be trivial to fix. I’d love to tell you where the problematic check is, but your sources are secret so I can’t do that.

In summary, Multipass is an interesting project and I’d love to have alternatives to WSL2, but as it stand today it’s not a viable alternative on Windows.

The behavior on Windows is subpar, the hogging of unnecessary and dangerous permissions is completely unjustified, the distribution method is hostile to power users, and the project isn’t even open source so I can’t fix any of those issues.

I may be interested in using Multipass in a future where these issue are resolved.

If you’d like technical assistance regarding specific issues with your top secret source code you may contact me privately and we’ll if I am able to help.

2

Hi @fooooo,

Thanks for all the work you put into this post. You’re right, on Windows with Hyper-V we could run as non-admin. It’s just work that we didn’t have time for so far.

The installer needs admin privileges so it can install the service, you said “That’s the big deal? I’ll do it myself” - most users would rather the installer do it for them, so while a ZIP file may be an option, we’re unlikely to make it the default delivery mechanism.

As you noted, we have registered issues for a lot of what you wrote down and we’ll work through them as time permits.

1 Like
3

Thanks for your reply, @saviq.

There are a few issues in your message not clear to me.

I understand this one is not a priority but there also not a lot of work to do actually, so this kind of balances out. It’s more of not doing things - not running as LOCAL_SYSTEM.

Where changes will be required is in places that assume administrative rights, such as the Hyper-V health check that runs Get-WindowsOptionalFeature, but that’s actually a good thing since this check is wrong and should be removes regardless of the admin issue. (I haven’t reviewed all the places where administrative rights are assumed for obvious reasons - source code being unavailable - but from the behavior presented I can see no reason administrative rights will be required.)

I’m pretty sure I didn’t ask for it to be the default delivery mechanism. I did say that it should be an option.

I’m also not sure if that statement about most users is in fact true. Do you have data to support this? Perhaps most users like this choice. Maybe that’s why most software products provide it where it’s not impossible or extremely difficult.

On the computer on which I’m writing this post the following software products provide file archives, “portable installers” or equivalent:

(i) Visual Studio Code; (ii) PowerShell 7; (iii) WinDbg; (iv) Windows Performance Analyzer; (v) 7-Zip; (vi) Beyond Compare; (vii) Git; (viii) Everything; (ix) Python; (x) Wireshark, and (xi) Docker.

I did not include small tools whose main delivery mechanism is file archives. I considered only major products that allow “install-less” distribution in addition to the default installer.

In contrast, I could find only two software products that don’t provide such an option - Google Chrome and Visual Studio.

(There’s a third category to which Windows Terminal belongs. It’s distributed as an .msixbundle which is not an installer that requires administrative rights, but also not a simple collection of files like the first category, so I left it out of both groups.)

Once again I emphasize so there will be no confusion: I do not expect a ZIP file to replace the installer and I did not ask for it. I’m asking for a ZIP file in addition to the installer. This requires zero development, has zero added test load, etc.

All it requires is that the build script that builds the NSIS installer also create a zip of the main assets. Worst case, for example if you added a new required DLL, updated the NSIS installer to include it and forgot to include it in the ZIP, the ZIP distribution would be broken but everything else will continue to work as usual. It doesn’t affect the code of Multipass itself and has no risk of causing regression in what already works.

Do you mean GitHub issues? There are a few issues about the unavailability of source code for Windows but they haven’t been updates for a while and there was no explanation given why can’t the Canonical part be provided, without the non open source parts, so while it won’t be buildable the community would still be able to better understand and improve the code. Besides that I could not find a GitHub issue for any of the issues I mentioned under the canonical/multipass repo. The issues being:

  1. Running as LOCAL_SYSTEM / an administrator.

  2. ZIP distribution.

  3. Using Windows\System32\config\systemprofile to store program data.

  4. Securing mount access. (Would be solved by not running as admin, but a distinct issue.)

The closest I could find is #1112 which deals only with the VM storage (the “vault”) but keeps multipassd.conf there regardless.