Global automount configuration

[vladimir-novoseltsev]

Hello, please add an option to globally configure automount with .wslconfig file. Option to not automount removable drives would be perfect as well, right now, if someone use removable drives they cannot be safely removed until WSL distros with automount enabled are shutdown.

[WSLUser]

is /etc/fstab not enough of a global automount for you?

[vladimir-novoseltsev]

/etc/fstab is per distro, so it is not global and it is not automount at all.

[vladimir-novoseltsev]

Ok, sorry, I've probably been not precise enough in what I wanted. Right now you can set per distro if host's drives are mounted when WSL distro is started. By default all host's drives are mounted into distro. You can disable that with /etc/wsl.conf with following:

[automount]
enabled=false

Then you can mount whatever you want through /etc/fstab.

The problem I see is this behavior mount ALL drives from the host system, including removable drives, which you cannot safely remove without stopping WSL distros. This is ok, as long as you manage and configure it yourself. Sometime you don't want to mess with distro config, like i.e. Docker WSL2 distro as it will loose some flexibility and might be broken in result.

So what I want is option to globally for all WSL distros to disable mounting for host's removable drives.

[WSLUser]

Interesting. Many people wanted precisely the behavior of auto-mounting removable drives. To the point projects exist using things like USB-IP for WSL2 to pick up on them. You didn't specify, but sounds like based on what I just said, you're using WSL1 and want more options available under [automount] to be configurable. I think the answer from the MS devs will still be use /etc/fstab, which only mounts what's defined. You can copy that to every distro, they're all the same when it comes to mounting. I suppose they could make a global /etc/fstab that's written to every distro you install but they prefer to remain hands off of the distros as much as possible. It's bad enough we still have a proprietary init being used on WSL2.

[dinvlad]

I have another use case for this - to isolate WSL distros from Windows for more sensitive scenarios. For example, I want to prevent malware downloaded inside WSL from accessing (or overriding access to) the Windows host. Right now, I can disable it via wsl.conf, but that can be overridden by malware (assuming it got root inside WSL). It would be nice to be able to enforce [automount] enabled=false globally instead. Same goes for [interop] enabled = false for this purpose.

[cycledetector]

Has there been any progress towards implementing this feature? Being able to set [automount] enabled = false and [interop] enabled = false in .wslconfig, i.e. globally, instead of setting those options in wsl.conf per distro would actually be a very useful feature. As dinvlad pointed out, if we assume that someone has root access inside a WSL distro, wsl.conf can be modified, while modifying .wslconfig would require access to the actual Windows host.

There is also the option of creating a wsl.conf for each distro, that would be located in the Windows host (and not in the distro itself) and parsing it when launching a distro with wsl.

In any case, I think the main problem is that placing the wsl.conf in the distro itself has security implications. It's like having a Hyper-V virtual machine that can give permissions to itself in order to access the host, while it should be the other way around.

[Biswa96]

It may be possible with a little Win32 program. The logic would be like following:

1. Use WslGetDistributionConfiguration() to get wslDistributionFlags.
2. Remove the flags you want to disable.
3. Set the remaining flag value with WslConfigureDistribution().

[cycledetector]

It may be possible with a little Win32 program. The logic would be like following:

1. Use WslGetDistributionConfiguration() to get wslDistributionFlags.
2. Remove the flags you want to disable.
3. Set the remaining flag value with WslConfigureDistribution().

As far as I understand, this flag value is set in the Windows Registry. However, someone can still mount a host drive and enable interoperability by modifying the /etc/wsl.conf file or manually mounting a drive, right?

I think the main question here is, how can one block access to certain resources for each distro?

[Biswa96]

However, someone can still mount a host drive and enable interoperability by modifying the /etc/wsl.conf file or manually mounting a drive, right?

As for the formality, I do not suggest to modify registry value because any wrong step may break your WSL setup. But be as naughty as you want, just don’t get caught. Yes, those flags are set in Flags registry. Those will override any options in /etc/wsl.conf. For example, if WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING flag is removed [automount] enabled=true would do nothing. After that, Windows drives will not be automatically mounted inside of WSL sessions.

[cycledetector]

However, someone can still mount a host drive and enable interoperability by modifying the /etc/wsl.conf file or manually mounting a drive, right?

As for the formality, I do not suggest to modify registry value because any wrong step may break your WSL setup. But be as naughty as you want, just don’t get caught. Yes, those flags are set in Flags registry. Those will override any options in /etc/wsl.conf. For example, if WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING flag is removed [automount] enabled=true would do nothing. After that, Windows drives will not be automatically mounted inside of WSL sessions.

Thank you for the clarification, that's a good workaround for stopping automounting and blocking interopability, but unless I am missing something, someone could still mount the host drives manually, is that correct?

[Biswa96]

someone could still mount the host drives manually, is that correct?

Only if the current user has administrator privilege or belongs to Hyper-V Administrators user group.

[cycledetector]

someone could still mount the host drives manually, is that correct?

Only if the current user has administrator privilege or belongs to Hyper-V Administrators user group.

I found out that it is possible to also mount a physical drive from within a Linux distro running on WSL. I disabled automount and interoperability and executed: sudo mount -t drvfs e: /mnt/e. The drive was properly mounted at /mnt/e and I could list its contents. So while wsl --mount has to be run from the host (assuming that interoperability and automounting is off), if we assume that someone has root access on the Linux distro, access to the physical drives of the host is still possible.

I understand that WSL is a product geared towards development workstations and not production servers but on the other hand, not being to limit access to certain resources is a security oversight in my humble opinion. In the same vain, I think that wsl.conf should not be located in the distro. As you mentioned, configuration for each Linux distro already exists in the Windows Registry, so what is the purpose of having a second one, one that can be modified from inside the distro?

[Biswa96]

I disabled automount and interoperability and executed: sudo mount -t drvfs e: /mnt/e.

Did you disable that with those WSL APIs? I have tried that command and it shows error like the following after disabling WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING flag.

$ sudo mount -t drvfs e: /mnt/e
<3>init: (23) ERROR: UtilConnectVsock:408: connect port 50002 failed 110
Operation timed out

[cycledetector]

I disabled automount and interoperability and executed: sudo mount -t drvfs e: /mnt/e.

Did you disable that with those WSL APIs? I have tried that command and it shows error like the following after disabling WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING flag.

$ sudo mount -t drvfs e: /mnt/e
<3>init: (23) ERROR: UtilConnectVsock:408: connect port 50002 failed 110
Operation timed out

I haven't tried using the WSL API. I disabled mounting through /etc/wsl.conf initially. I tried again by setting the Flags registry value to 8 in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{Distro GUID} for the distro. I assume this to be equivalent to using the WSL API. Running sudo mount -t drvfs e: /mnt/e again mounted the drive. I set it to 8 since this is the flag value for defining WSL version 2 without any additional features. I assume 9 would be the value to only enable interoperability, a to only append Windows path elements to $PATH, b to do both, c to only enable drive mounting and f to enable all three.

When you changed WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING, was the version of the WSL distro 2 or 1? Because anything under 8 for the flag value sets the WSL distro to version 1.

[Biswa96]

I have tried that with both WSL1 and WSL2. Here I focused on the automount feature. Whether Flags works with different values is a broad topic. Some calculation,

• WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING = 0x4
• WSL1: Before 0x7 → Subtract 0x4 → After 0x3
• WSL2: Before 0xf → Subtract 0x4 → After 0xb

[cycledetector]

I have tried that with both WSL1 and WSL2. Here I focused on the automount feature. Whether Flags works with different values is a broad topic. Some calculation,

• WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING = 0x4
• WSL1: Before 0x7 → Subtract 0x4 → After 0x3
• WSL2: Before 0xf → Subtract 0x4 → After 0xb

Setting the flag value to either 8 or b does disable automount but I can still mount the physical drives from within the Linux distro with the aforementioned command.

So disabling WSL_DISTRIBUTION_FLAGS_ENABLE_DRIVE_MOUNTING disables automounting but not mounting drives as a whole, at least on my system.

And even if it did disable mounting drives, there is still no way to disable access for some drives and enable it for other drives, e.g. enable access for C: and disable it for D:. Hyper-V permits this but WSL does not.

Normally, I would be using Hyper-V instead of WSL but getting the GPU to work in a Linux virtual machine requires a lot of workarounds at the moment.

[thawkins]

This is an important requirement for us to be able to permenantly and globaly disable interop and automount and also disable drvfs completly, without non local admins or wsl sudo users being able to enable it again.. We are a large corporate, and our security division will not allow the deployment of wsl without this ability to lock it down.

[dinvlad]

This is pretty much the reason why I stopped using WSL, unfortunately. It worked quite flawlessly otherwise, but the lack of separation between the host and guests is just not workable in a multi-project environment.

[Detzler]

This is pretty much the reason why I stopped using WSL, unfortunately. It worked quite flawlessly otherwise, but the lack of separation between the host and guests is just not workable in a multi-project environment.

I fully agree. Had the same situation and consequence. Can't use WSL in my enterprise field because of this security issue.