firejail always detects a sandbox when running under WSL

[mqudsi]

I'm unable to use firejail (to test for app compatibility) due to it always thinking it's running in a sandbox anytime I run it under WSL.

mqudsi@Blitzkrieg /m/d/r/fish> firejail --shell=build/fish
Warning: shell-related command line options are disregarded - using SHELL environment variable
Warning: an existing sandbox was detected. /bin/bash will run without any additional sandboxing features
mqudsi@Blitzkrieg:/mnt/d/rand/fish$ exit
exit
mqudsi@Blitzkrieg /m/d/r/fish> uname -a
Linux Blitzkrieg 4.4.0-17763-Microsoft #55-Microsoft Sat Oct 06 18:05:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
mqudsi@Blitzkrieg /m/d/r/fish> firejail --version
firejail version 0.9.57

[SkewedZeppelin]

I don't think WSL actually implements any of the kernel features that firejail needs, because it isn't actually running the Linux kernel.

That being said the error message should probably be tweaked for different cases like this.

[crass]

While I highly doubt WSL implements the needed kernel container APIs, as far as I can tell, firejail doesn't actually check for the APIs. It first checks the "container" envvar (see check_namespace_virt) and if not in a container white list, checks if its in a pid namespace by seeing if any of a list of 5 kernel process names exist in /proc (see check_kernel_procs). I suspect firejail isn't finding a matching kernel process name. If you run with --debug, I believe more info confirming this will be shown.

This seems list a pretty hacky/error-prone way of doing this, but I'm not terribly interested in this use case, especially since the underlying APIs likely aren't there anyway.

[chiraag-nataraj]

Let's go ahead and close this as wontfix for now (although apparently WSL 2 will actually run a Linux kernel? That may very well change the situation).

[erndob]

To anyone reading this, WSL 2 doesn't work either. At least the 19041 build.