is it always accessible from the host using ...
Great question. AFAIK, currently yes, it is always accessible. There's no way that I can think of to disable this entirely.
However, in the absence of a WSL feature to handle this directly, here are several alternative implementations. It should be noted, however, that none of these can protect the data from a determined third-party if they have access to the Windows host (see footnote).
First, and perhaps most straightforward, would be to restrict your default WSL user from accessing the mountpoint. That will make in inaccessible from \\wsl$\
(and it's successor \\wsl.localhost\
) but require that you use a different username when accessing the mount in Ubuntu. That could be root, or you could create a secondary user that you su -
to when you want to work with the LUKS drive.
sudo chmod 700 /mnt/LUKSdrive
Conversely, you can change your default user to nobody
and give ownership of the mount to your regular user. The \\wsl$\
share will then be accessed with permissions of nobody
, and access will be denied.
sudo chown $USER:$USER /mnt/LUKSdrive
sudo chmod 700 /mnt/LUKSdrive
sudo -e /etc/wsl.conf
Add the following:
[user]
default=nobody
Exit Ubuntu, and from PowerShell:
$ wsl --shutdown
$ wsl ~
<3>WSL (9) ERROR: CreateProcessEntryCommon:559: chdir(/nonexistent) failed 2
This account is currently not available.
$ wsl ~ -u <your_Ubuntu_username>
You'll need to specify the -u <username>
each time you start Ubuntu, but your user will have access to the LUKS-encrypted drive, while \\wsl$\
will not.
keep it protected from outside access, ideally by hiding this mount completely
Most complicated, but probably the closest to "hiding it" would be to use a mount namespace, inside which you can use mount --make-private
in order to restrict it from being seen in the initial/default namespace.
# One time
sudo touch /root/LUKSns
sudo mkdir /mnt/LUKSdrive
sudo unshare --mount=/root/LUKSns --propagation unchanged
# Now we are inside the mount namespace as root
mount --make-private /dev/mapper/LUKSdrive /mnt/LUKSdrive/
logout # exit or Ctrl+D, etc.
# Back in the initial namespace
ls /mnt/LUKSdrive
# Should be empty
sudo nsenter --mount=/root/LUKSns runuser -P -l $USER -c "exec $SHELL"
ls /mnt/LUKSdrive
# Contents should be visible
From File Explorer, \\wsl$\<distribution>\mnt\LUKSdrive
will appear empty.
Caveats:
From inside the namespace, certain WSL features will not work. This includes:
The Windows Path will no longer be appended to the Linux path. As a result, if you want to call a Windows command, you'll need to do it with the fully-qualified path (e.g. /mnt/c/Windows/notepad.exe
).
WSL-configured environment variables will not be set, including $WSL_DISTRO_NAME
and $DISPLAY
. Assuming that you are on a recent WSL release, you can manually export DISPLAY=:0
to restore X11 functionality. Other variables for Wayland and PulseAudio can be manually reset as well.
In getting this solution working, I've hard-locked WSL a few times, requiring a taskkill
of the entire Subsystem. This may be due to attempting to enter \\wsl.localhost\<distro>\mnt\LUKSdrive
, but I am not certain yet. I'd be curious to hear (if you try this) whether or not you run into any issues.
Footnote: Security implications
WSL works on the concept of "containers", and there's currently no way to restrict the distribution from being accessed by the Windows user. Even if we prevent access to \\wsl$\
as above, a user can still always simply:
wsl -u root
... and enter the namespace or bypass ownership/permission restrictions. This is very similar to the way that Docker containers work. See the Stack Overflow question, How to password protect a docker container?, for which the WSL answer is very similar.