Apparmor + firejail = Warning: an existing sandbox was detected (+ problem with --force)

[random2344]

I want to use Apparmor and firejail in combination for firefox (or tor browser actually).
The system is debian testing with a custom apparmor profile for firefox, the kernel is 4.4.3 with grsecurity patch and firejail is version 0.9.38. The firejail profiles are form here: https://git.schwanenlied.me/yawning/tor-firejail
I found some similar issues here though they only seem to be related or the proposed solution does not work.
If I use apparmor or firejail alone with the browser it is working.
But if I want to use both at the same time I get the following message:
"Warning: an existing sandbox was detected ./firefox --class Tor Browser -profile TorBrowser/Data/Browser/profile.default will run without any additional sandboxing features in a /bin/sh shell"

What are the security implications of this warning? Does it mean I have no protection beyond the one apparmor provides?
Also the --debug option does not work in this case.
What can I do about that?
There are two related issues:

1. Firejail with grsecurity #141
   There is no mention of apparmor. Only grsecurity, however running firejail alone under the grsec kernel works fine.
   2.Run Firejail in Docker container #189
   Also no mention of apparmor. I tried the --force option but this does not even start the browser, instead I get:
   "Error getpwuid: extract_user_data(134): Permission denied"
   (I also don't get any apparmor denied messages)

[netblue30]

The version on the master branch has a number of apparmor fixes. Firefox and Chromium should work with the default apparmor profiles on Ubuntu 14.04. There are still some problems with evince, they seem to be apparmor specific problems: #396

I am basically waiting in this moment to see what they bring up in 16.04

This is the story of --force: In a sandboxed Mozilla Thunderbird if you click on a link in email, this should start Firefox. However, if Firefox is also sandboxed by some bash script, Thunderbird will not allow the second sandbox to start - the sandbox is SUID, so it is disabled by the first sandbox. The fix was to allow the program to run directly in the existing sandbox, without attempting to start another one.

--force allows the user to bypass this functionality and force the start of a new sandbox. It is used by people running firejail in a Docker or LXC container - somehow my sandbox detection code does not distinguish between Docker and Firejail containers.

I think you are attempting to instantiate the sandbox twice, probably with the same sandbox configuration.

[reinerh]

I'm just testing 0.9.40-rc1 and now I also get the warning about an existing sandbox:

$ firejail
Warning: an existing sandbox was detected. /bin/bash will run without any additional sandboxing features in a /bin/sh shell

I am also using apparmor (but not for the terminal or bash, so I don't think its related to that) and grsec.

[reinerh]

Additional information:
It works when running as root.
I just checked the source and it looks like you are checking for kernel processes.
But with my grsec configuration normal users only see their own processes.
So it looks like I always have to use --force?

[netblue30]

I'll install grsec here to take a look, definitely a bug, thanks!

[random2344]

I did some more tests:

tldr
There are notable differences in the sandbox detection between the two firejail versions. One reason for the sandbox warning seems to be indeed the grsec proc restrictions #141. Without the restrictions and without apparmor no warning appears.
But there is also an issue with apparmor itself. Even without the proc restrictions I get a sandbox warning when apparmor is enabled. Apparmor requests some more permissions (e.g. firejail wants to look into proc) but this also didn't help.
I'm not sure if anything will change with ubuntu 16.06. From looking at the packages they also use apparmor 2.10 at the moment which is also what debian testing is currently using. I don't know if there are any significant differences between the ubuntu and the debian package. The source for apparmor 2.11 beta was just released some days ago. I guess it won't make it into 16.06. Maybe there are also no changes relevant to our problem.

firejail 0.9.40rc1:

grsec-kernel without proc restrictions:
--> with apparmor enabled I get the sandbox warnign but the browser starts, I also get some new apparmor denied messages (/etc/ld.so.preload and proc/*/comm/). If I add those to my apparmor profile the browser didn't start anymore. Instead I get:" Error getpwuid:init_cfg(179): Permission denied"

--> without apparmor everything is working fine, no sandbox warnings.

grsec-kernel with proc restrictions:
--> with apparmor enabled I get the same error message as above when I use --force. Without the --force option the browser starts but I get the sandbox warning.

--> without apparmor I get the sandbox warning but the browser is working. If I use --force no warning appears but I get the "Entering sandbox-in-sandbox mode" message

firejail 0.9.38:

grsec-kernel without proc restrictions:
--> with apparmor enabled I get the sandbox warnign but the browser starts

--> without apparmor everything is working fine, no sandbox warnings. --force mode working too

grsec-kernel with proc restrictions:
--> with apparmor enabled I get the same error message as above when I use --force. Without the --force option the browser starts but I get the sandbox warning.

--> no warnings, --force also works

[netblue30]

I think I fixed grsec with proc restrictions, and also "Error getpwuid: extract_user_data(134): Permission denied". There are more fixes for grsecurity to come, but I don't think it affects you in this moment. Give it a try, thanks!

[reinerh]

Just tested your fix and I can confirm that it is now working for me.
Thanks!

[netblue30]

Thanks!