[GH-ISSUE #4550] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has m…

gitea-mirror commented

2026-05-05 09:21:55 -06:00

Owner

Originally created by @deletedaccount00 on GitHub (Sep 15, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4550

user@hdd:/Downloads$ firejail --appimage --noprofile ./Bitwarden-1.28.2-x86_64.AppImage
Mounting appimage type 2
Parent pid 8934, child pid 8937

** Warning: dropping all Linux capabilities **
Child process initialized in 54.55 ms
[2:0915/164221.230211:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755.

Parent is shutting down, bye...
AppImage unmounted

" You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. "

BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY.

Originally created by @deletedaccount00 on GitHub (Sep 15, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4550 user@hdd:/Downloads$ firejail --appimage --noprofile ./Bitwarden-1.28.2-x86_64.AppImage Mounting appimage type 2 Parent pid 8934, child pid 8937 ** Warning: dropping all Linux capabilities ** Child process initialized in 54.55 ms [2:0915/164221.230211:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. Parent is shutting down, bye... AppImage unmounted " You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. " BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY.

gitea-mirror closed this issue

2026-05-05 09:21:56 -06:00

gitea-mirror commented

2026-05-05 09:21:57 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 15, 2021):

BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY.

THERE IS A .appimage-xxx IN appimage DIRECTORY WHEN YOU START THE APPIMAGE.

firejail --appimage --noprofile ./Bitwarden-1.28.2-x86_64.AppImage
The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755.

You can not use an chrom* AI together with firejail --appimage (at least on systems that do not support unprivileged_userns_clone, not sure about systems with support for unprivileged_userns_clone).

You can

try to make it work without --appimage
try if it works if you allow unprivileged_userns_clone if it is disable
run it without it's sandbox (don't do that)

@rusty-snake commented on GitHub (Sep 15, 2021): > BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY. THERE IS A `.appimage-xxx` IN `appimage` DIRECTORY WHEN YOU START THE APPIMAGE. > firejail --appimage --noprofile ./Bitwarden-1.28.2-x86_64.AppImage > The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. You can not use an chrom* AI together with `firejail --appimage` (at least on systems that do not support unprivileged_userns_clone, not sure about systems with support for unprivileged_userns_clone). You can 1. try to make it work without `--appimage` 2. try if it works if you allow unprivileged_userns_clone if it is disable 3. run it without it's sandbox (don't do that)

gitea-mirror commented

2026-05-05 09:21:58 -06:00

Author

Owner

@deletedaccount00 commented on GitHub (Sep 15, 2021):

I tried without " --appimage " flag.

output navigates me to make some changes to chrome-sandbox but I end up not seeing the previous directory In my case it's " .mount_Bitwara7ohsq ".

@deletedaccount00 commented on GitHub (Sep 15, 2021): I tried without " --appimage " flag. output navigates me to make some changes to chrome-sandbox but I end up not seeing the previous directory In my case it's " .mount_Bitwara7ohsq ".

gitea-mirror commented

2026-05-05 09:21:58 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 16, 2021):

is owned by root and has mode 4755

I think this will not work in an AppImage, no matter with or without Firejail. For security reasons the AppImage is always mounted with nosuid flag. At the same time the Chromium sandbox helper cannot work without being root, hence the error your are seeing.

Your best chance is to somehow enable unprivileged user namespaces (which has its own security implications).

Some commands which may or may not work (as root):

echo 1 > /proc/sys/kernel/unprivileged_userns_clone
echo 0 > /proc/sys/kernel/userns_restrict
echo 10000 > /proc/sys/user/max_user_namespaces

@smitsohu commented on GitHub (Sep 16, 2021): > is owned by root and has mode 4755 I think this will not work in an AppImage, no matter with or without Firejail. For security reasons the AppImage is always mounted with `nosuid` flag. At the same time the Chromium sandbox helper cannot work without being root, hence the error your are seeing. Your best chance is to somehow enable unprivileged user namespaces (which has its own security implications). Some commands which may or may not work (as root): `echo 1 > /proc/sys/kernel/unprivileged_userns_clone` `echo 0 > /proc/sys/kernel/userns_restrict` `echo 10000 > /proc/sys/user/max_user_namespaces`

gitea-mirror commented

2026-05-05 09:21:59 -06:00

Author

Owner

@ckorder commented on GitHub (Dec 3, 2021):

echo 1 > /proc/sys/kernel/unprivileged_userns_clone
echo 0 > /proc/sys/kernel/userns_restrict
echo 10000 > /proc/sys/user/max_user_namespaces

i can confirm that it's working but only if you are okay with increasing the attack surface as mentioned
which has its own security implications

https://www.realmicentral.com/2021/07/21/linux-leaks-kernel-security-vulnerabilities-unprivileged-users-can-gain-root-privileges/
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

i suggest using: firejail --parameter options someapp.AppImage --no-sandbox
which will disable the chromium sandbox feature instead of enabling dangerous kernel options.

any thoughts on this? otherwise can be closed again.

@ckorder commented on GitHub (Dec 3, 2021): > echo 1 > /proc/sys/kernel/unprivileged_userns_clone > echo 0 > /proc/sys/kernel/userns_restrict > echo 10000 > /proc/sys/user/max_user_namespaces i can confirm that it's working but only if you are okay with increasing the attack surface as mentioned `which has its own security implications` https://www.realmicentral.com/2021/07/21/linux-leaks-kernel-security-vulnerabilities-unprivileged-users-can-gain-root-privileges/ https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do i suggest using: firejail --parameter options someapp.AppImage --no-sandbox which will disable the chromium sandbox feature instead of enabling dangerous kernel options. any thoughts on this? otherwise can be closed again.

gitea-mirror commented

2026-05-05 09:21:59 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 4, 2021):

any thoughts on this?

"which will disable the chromium sandbox feature" "which has its own security implications".

You have to work out what is more important in your thread models.

An remote attacker getting access to your system.
An attacker with access to your system becomes root.

The chromium sandbox is a default enabled security feature, while userns is enabled by default and disabled as defense-in-depth.

@rusty-snake commented on GitHub (Dec 4, 2021): > any thoughts on this? "which will disable the chromium sandbox feature" "which has its own security implications". You have to work out what is more important in your thread models. - An remote attacker getting access to your system. - An attacker with access to your system becomes root. The chromium sandbox is a default enabled security feature, while userns is enabled by default and disabled as defense-in-depth.

gitea-mirror commented

2026-05-05 09:21:59 -06:00

Author

Owner

@ckorder commented on GitHub (Dec 7, 2021):

@rusty-snake
You seem to be more experienced on the firejail source code.

I know every layer protection is valuable but does this mean "An remote attacker getting access to your system." that firejail shall be viewed as inefficient for protecting the access to our systems?

Shall I more likely enable a global security decrease in favor of the trusted google devs?

Until now, i would take my chance of running a single NodeJS app without third party connections in a private-home and a proper firejail profile rather than enabling these options within my kernel.

If I'm wrong, please change my mind and let others now as well since i think this issue is quite important because of the increase of popularity on chromium based apps.

Have been any efforts tried to communicate these issues with the dev's of chromium?

I think there are just a few people able to address the cause and the related problems properly relating towards the source of firejail and could suggest a different path how the chromium sandbox could be setup. e.g @rusty-snake || @netblue30 <3

But maybe I'm wrong here and there are good reasons for them handling it this way beside faster loading time since it does not need to be created for every use but why than not dropping it somewhere persistent ?

" You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. "

BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY.

@ckorder commented on GitHub (Dec 7, 2021): @rusty-snake You seem to be more experienced on the firejail source code. I know every layer protection is valuable but does this mean "An remote attacker getting access to your system." that firejail shall be viewed as inefficient for protecting the access to our systems? Shall I more likely enable a global security decrease in favor of the trusted google devs? Until now, i would take my chance of running a single NodeJS app without third party connections in a private-home and a proper firejail profile rather than enabling these options within my kernel. If I'm wrong, please change my mind and let others now as well since i think this issue is quite important because of the increase of popularity on chromium based apps. **Have been any efforts tried to communicate these issues with the dev's of chromium?** I think there are just a few people able to address the cause and the related problems properly relating towards the source of firejail and could suggest a different path how the chromium sandbox could be setup. e.g @rusty-snake || @netblue30 <3 But maybe I'm wrong here and there are good reasons for them handling it this way beside faster loading time since it does not need to be created for every use but why than not dropping it somewhere persistent ? > > " You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has mode 4755. " > > BUT THERE'S NO " .appimage-8934 " IN " appimage " DIRECTORY.

gitea-mirror commented

2026-05-05 09:22:00 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 7, 2021):

I know every layer protection is valuable but does this mean "An remote attacker getting access to your system." that firejail shall be viewed as inefficient for protecting the access to our systems?

It depends.

Short story: An attacker who can execute arbitrary code inside the sandbox can (in the most cases) escape if he wants (wants=is aware of firejail and how to escape it).

Let's take chromium as an example:
Scenario 1: An attacker escaped chromium-sandbox => firejail shouldn't be barrier because chromium-sandbox has a much much tighter sandbox.
Scenario 2: chromium-sandbox is disable, chromium.profile is unmodified => 🤦
Scenario 3: chromium-sandbox is disable, chromium.profile is hardened => It depends on the attacker:

spyware which wants your email/banking/github/... credentials => it does not need to escape.
ransomware: will probably don't care about the few systems with firejail, if it does it depends on how good you hardened your chromium.profile
targeted attack by an advanced attacker: Use Tails/QubesOS/Whonix and be paranoid

Shall I more likely enable a global security decrease in favor of the trusted google devs?

Are privileged escalation in your thread models? Or is this an "already lost scenario"?
See #4601.

user.max_user_namespaces=0 disables userns => all sandboxes are weaker
kernel.unprivileged_userns_clone=1 is the "default" used by mainline kernels
kernel.unprivileged_userns_clone=0 is a hardening option
kernel.unprivileged_userns_clone=0 mitigate some (!=all) privileged escalation vulnerabilities
kernel.unprivileged_userns_clone=0 weakens the firejail sandbox for programs like chromium which execute remote code and have a millions line complexity.

If I'm wrong, please change my mind and let others now as well since i think this issue is quite important because of the increase of popularity on chromium based apps.

My opinion:

privileged escalation is just not inside my (main) thread models (#4601)
kernel.unprivileged_userns_clone=0 isn't available for my kernel (Fedora Linux) and user.max_user_namespaces=0 disables userns entirely.
unprivileged userns allow you to run some program (bubblewrap, podman, ...) without sudo/suid.
kernel.unprivileged_userns_clone=0 is a hardening option (which should be set if you don't need/use unprivileged userns; if you don't know what unprivileged userns are and if you don't know if you need/use them don't change it) but it is enabled by default, it is not an insecure feature (unlike X for example). It increases complexity of "Linux" which makes bugs more likely (that can be said about everything today).

Have been any efforts tried to communicate these issues with the dev's of chromium?

Not official (you can search thier issue tracker, maybe there are some reports regarding unprivileged_userns_clone=0 and NNP). However it would be a "won't fix".

@rusty-snake commented on GitHub (Dec 7, 2021): > I know every layer protection is valuable but does this mean "An remote attacker getting access to your system." that firejail shall be viewed as inefficient for protecting the access to our systems? It depends. Short story: An attacker who can execute arbitrary code inside the sandbox can (in the most cases) escape if he wants (wants=is aware of firejail and how to escape it). Let's take chromium as an example: Scenario 1: An attacker escaped chromium-sandbox => firejail shouldn't be barrier because chromium-sandbox has a much much tighter sandbox. Scenario 2: chromium-sandbox is disable, chromium.profile is unmodified => :facepalm: Scenario 3: chromium-sandbox is disable, chromium.profile is hardened => It depends on the attacker: - spyware which wants your email/banking/github/... credentials => it does not need to escape. - ransomware: will probably don't care about the few systems with firejail, if it does it depends on how good you hardened your chromium.profile - targeted attack by an advanced attacker: Use Tails/QubesOS/Whonix and be paranoid > Shall I more likely enable a global security decrease in favor of the trusted google devs? Are privileged escalation in your thread models? Or is this an "already lost scenario"? See #4601. - user.max_user_namespaces=0 disables userns => all sandboxes are weaker - kernel.unprivileged_userns_clone=1 is the "default" used by mainline kernels - kernel.unprivileged_userns_clone=0 is a hardening option - kernel.unprivileged_userns_clone=0 mitigate some (!=all) privileged escalation vulnerabilities - kernel.unprivileged_userns_clone=0 weakens the firejail sandbox for programs like chromium which execute remote code and have a millions line complexity. > If I'm wrong, please change my mind and let others now as well since i think this issue is quite important because of the increase of popularity on chromium based apps. My opinion: - privileged escalation is just not inside my (main) thread models (#4601) - kernel.unprivileged_userns_clone=0 isn't available for my kernel (Fedora Linux) and `user.max_user_namespaces=0` disables userns entirely. - unprivileged userns allow you to run some program (bubblewrap, podman, ...) without `sudo`/suid. - kernel.unprivileged_userns_clone=0 is a hardening option (which should be set if you don't need/use unprivileged userns; if you don't know what unprivileged userns are and if you don't know if you need/use them don't change it) but it is enabled by default, it is not an insecure feature (unlike X for example). It increases complexity of "Linux" which makes bugs more likely (that can be said about everything today). > Have been any efforts tried to communicate these issues with the dev's of chromium? Not official (you can search thier issue tracker, maybe there are some reports regarding unprivileged_userns_clone=0 and NNP). However it would be a "won't fix".

Rows
Columns

[GH-ISSUE #4550] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /run/firejail/appimage/.appimage-8934/chrome-sandbox is owned by root and has m… #2702