Another sandbox is detected in Ubuntu 22.04 (WSL)

[timsu92]

I'm using Ubuntu 22.04 in WSL, and firejail was installed using git method in other section, with master in 5604a723b.
This is the full process I installed this work:

sudo apt-get install git build-essential libapparmor-dev pkg-config gawk
git clone https://github.com/netblue30/firejail.git
cd firejail
./configure --enable-apparmor --prefix=/usr
make -j14 && sudo make install-strip

And I see that no matter which program I launch with firejail, it shows a warning like this:

Warning: an existing sandbox was detected. <the program's name> will run without any additional sandboxing features

I see some say the reason is that sudo firecfg creates symlinks so the command I'm invoking becomes firejail firejail tar. However, I didn't execute firecfg, and this warning still exists after I run sudo firecfg --clean

What does this warning mean? Should I do something to fix this? Or Ubuntu 22.04 has already protecting me?

---

Output of firejail --version

firejail version 0.9.73

Compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file transfer support is enabled
	- IDS support is disabled
	- Landlock support is enabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-lib support is disabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

[glitsj16]

Hi, thanks for reporting. Yes, you should fix this doubled sandbox invocation.

I see some say the reason is that sudo firecfg creates symlinks so the command I'm invoking becomes firejail firejail tar. However, I didn't execute firecfg, and this warning still exists after I run sudo firecfg --clean

That's correct reasoning indeed. Firecfg puts those symlinks into /usr/local/bin. As that path should be searched before /usr/bin, the 'symlink magic' works. Not sure why sudo firecfg --clean isn't fixing things for you. Never touched WSL, but I'd double-check what the PATH environment var is set to on that machine.

[timsu92]

Thanks for your reply!
However, I found that command -v tar returns /usr/bin/tar, and I didn't see a tar under /usr/local/bin. So I guess sudo firecfg --clean is doing its work.

[rusty-snake]

I guess the other sandbox that beeing detected is called WSL?

IDK, if firejail works in WSL2 (WSL1 is not supported). If you want to hack around, try to run container=lxc firejail --noprofile echo hello.

[timsu92]

Yes! This works! Thanks!
After testing, removing --noprofile works as well.

However, may I have your time to know more? Does this command specifies container to be lxc and not detected by the program?

[rusty-snake]

Yeah, firejail has a (not very up to date) of container runtimes it assumes it can operate in and does the normal stuff. In all other container runtimes it continues w/o additional sandboxing.

LXC is one of this assumed to be supported runtimes. container=lxc then matched this condition in firejail and let it continue.