[GH-ISSUE #380] Programs start without sandbox if /proc is mounted with hidepid

gitea-mirror commented

2026-05-05 05:28:42 -06:00

Owner

Originally created by @ghost on GitHub (Mar 24, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/380

If the /proc file system is mounted with hidepid=1 or hidepid=2, firejail reports to have detected an existing sandbox (as it can't see the kernel processes), starting the program in a normal /bin/sh shell. While this can be avoided using --force, it looks like a security problem to me as the warning can't be seen unless firejail is started in a terminal, making it seem like the program is sandboxed when it really isn't.

Would it be possible to detect an existing sandbox without checking for kernel processes?
Instead of starting programs in an insecure /bin/sh shell, the default behavior in my opinion should be not to start the program unless a special command-line flag is used. Otherwise, people might restrict access to kernel processes, not realizing that their sandbox isn't being used anymore.

Originally created by @ghost on GitHub (Mar 24, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/380 If the `/proc` file system is mounted with `hidepid=1` or `hidepid=2`, firejail reports to have detected an existing sandbox (as it can't see the kernel processes), starting the program in a normal `/bin/sh` shell. While this can be avoided using `--force`, it looks like a security problem to me as the warning can't be seen unless firejail is started in a terminal, making it seem like the program is sandboxed when it really isn't. 1. Would it be possible to detect an existing sandbox without checking for kernel processes? 2. Instead of starting programs in an insecure `/bin/sh` shell, the default behavior in my opinion should be not to start the program unless a special command-line flag is used. Otherwise, people might restrict access to kernel processes, not realizing that their sandbox isn't being used anymore.

gitea-mirror

2026-05-05 05:28:42 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 05:28:47 -06:00

Author

Owner

@ghost commented on GitHub (Mar 26, 2016):

Would you accept a pull request that changes the default behavior to require an --allow-no-sandbox option (or similar) for firejail to use an insecure /bin/sh shell, so that, when an existing sandbox is detected:

--allow-no-sandbox uses a normal, insecure /bin/sh shell
--force uses a sandbox (no change necessary)
Both options given: use a sandbox (--force takes precedence)
None of the options given: show an error message asking the user to specify one of the options; then exit

@ghost commented on GitHub (Mar 26, 2016): Would you accept a pull request that changes the default behavior to require an `--allow-no-sandbox` option (or similar) for firejail to use an insecure `/bin/sh` shell, so that, when an existing sandbox is detected: - **`--allow-no-sandbox`** uses a normal, insecure `/bin/sh` shell - **`--force`** uses a sandbox (no change necessary) - **Both options given**: use a sandbox (`--force` takes precedence) - **None of the options given**: show an error message asking the user to specify one of the options; then exit

gitea-mirror commented

2026-05-05 05:28:50 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 28, 2016):

I would leave it as is for now, probably there will be more changes in the future.

The question is this: you are in a sandbox, and you try to start another sandbox, what should happen? For Mozilla Thunderbird users this happens every time when they click a link in an email. So far the only idea I had was to start Firefox in the existing sandbox.

@netblue30 commented on GitHub (Mar 28, 2016): I would leave it as is for now, probably there will be more changes in the future. The question is this: you are in a sandbox, and you try to start another sandbox, what should happen? For Mozilla Thunderbird users this happens every time when they click a link in an email. So far the only idea I had was to start Firefox in the existing sandbox.

gitea-mirror commented

2026-05-05 05:28:52 -06:00

Author

Owner

@ghost commented on GitHub (Mar 28, 2016):

You're right, I didn't think about that.
Do you have any idea how a sandbox could be detected other than by kernel processes? If not, let's close this issue?

@ghost commented on GitHub (Mar 28, 2016): You're right, I didn't think about that. Do you have any idea how a sandbox could be detected other than by kernel processes? If not, let's close this issue?

gitea-mirror commented

2026-05-05 05:28:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 28, 2016):

Probably there are other ways. The kernel gives out some inode numbers in /proc/self/ns, you can compare these numbers with a regular process and detect the namespaces.

@netblue30 commented on GitHub (Mar 28, 2016): Probably there are other ways. The kernel gives out some inode numbers in /proc/self/ns, you can compare these numbers with a regular process and detect the namespaces.

gitea-mirror commented

2026-05-05 05:28:56 -06:00

Author

Owner

@Sidnioulz commented on GitHub (May 30, 2016):

@netblue30 not sure what exactly is the mechanics behind the Thunderbird situation, but on my fork I expect all my Xfce apps to use libxfce4ui's spawning function, and that function will detect if it is in a sandbox and then run "unsandboxed" (as in, not prepend firejail to the arguments being executed, resulting in the newly executed app being in the same container as its parent).

Assuming that you refer to Thunderbird running a .desktop file that does "firejail firefox", then the issue is that the .desktop file should embed that information another way (.desktop files have a special key in my fork indicating that Xfce should sandbox them) and the spawning utility used should be compatible (so that the initial run of the .desktop file in an unsandboxed environment properly runs it in a sandbox, and runs inside existing sandboxes put the new app inside that existing sandbox).

This is reliable and, as I see it, allows legitimate use of program helpers without raising security issues. But then again I have window decorations that clearly indicate the domain in which a windowed program is, you'd need that too to avoid user errors (using Thunderbird's firefox rather than another sandboxed firefox, when both are running).

@Sidnioulz commented on GitHub (May 30, 2016): @netblue30 not sure what exactly is the mechanics behind the Thunderbird situation, but on my fork I expect all my Xfce apps to use libxfce4ui's spawning function, and that function will detect if it is in a sandbox and then run "unsandboxed" (as in, not prepend firejail to the arguments being executed, resulting in the newly executed app being in the same container as its parent). Assuming that you refer to Thunderbird running a .desktop file that does "firejail firefox", then the issue is that the .desktop file should embed that information another way (.desktop files have a special key in my fork indicating that Xfce should sandbox them) and the spawning utility used should be compatible (so that the initial run of the .desktop file in an unsandboxed environment properly runs it in a sandbox, and runs inside existing sandboxes put the new app inside that existing sandbox). This is reliable and, as I see it, allows legitimate use of program helpers without raising security issues. But then again I have window decorations that clearly indicate the domain in which a windowed program is, you'd need that too to avoid user errors (using Thunderbird's firefox rather than another sandboxed firefox, when both are running).

gitea-mirror commented

2026-05-05 05:28:58 -06:00

Author

Owner

@deathtrip commented on GitHub (Jul 31, 2016):

I have /proc mounted with hidepid=2, and when i start a sandboxed program from the terminal, everything seems ok.
No report of an existing sandbox.
However no sandbox can be seen by using "firemon --list" or by firetools.

@deathtrip commented on GitHub (Jul 31, 2016): I have /proc mounted with hidepid=2, and when i start a sandboxed program from the terminal, everything seems ok. No report of an existing sandbox. However no sandbox can be seen by using "firemon --list" or by firetools.

gitea-mirror commented

2026-05-05 05:29:01 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 31, 2016):

How do you mount /proc with hidepid=2?

@netblue30 commented on GitHub (Jul 31, 2016): How do you mount /proc with hidepid=2?

gitea-mirror commented

2026-05-05 05:29:03 -06:00

Author

Owner

@deathtrip commented on GitHub (Jul 31, 2016):

here's the fstab entry:
proc /proc procfs hidepid=2,gid=proc 0 0

and the group file entry:
proc❌26:polkitd

@deathtrip commented on GitHub (Jul 31, 2016): here's the fstab entry: proc /proc procfs hidepid=2,gid=proc 0 0 and the group file entry: proc:x:26:polkitd

gitea-mirror commented

2026-05-05 05:29:05 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 1, 2016):

I'll give it a try, thanks.

@netblue30 commented on GitHub (Aug 1, 2016): I'll give it a try, thanks.

gitea-mirror commented

2026-05-05 05:29:07 -06:00

Author

Owner

@deathtrip commented on GitHub (Nov 9, 2016):

any progress on this?

@deathtrip commented on GitHub (Nov 9, 2016): any progress on this?

gitea-mirror commented

2026-05-05 05:29:09 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 9, 2016):

However no sandbox can be seen by using "firemon --list" or by firetools

Are you talking about this?

@netblue30 commented on GitHub (Nov 9, 2016): > However no sandbox can be seen by using "firemon --list" or by firetools Are you talking about this?

gitea-mirror commented

2026-05-05 05:29:13 -06:00

Author

Owner

@deathtrip commented on GitHub (Nov 9, 2016):

Yes.

@deathtrip commented on GitHub (Nov 9, 2016): Yes.

gitea-mirror commented

2026-05-05 05:29:16 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 10, 2016):

I'll try to bring in a fix.

@netblue30 commented on GitHub (Nov 10, 2016): I'll try to bring in a fix.

gitea-mirror commented

2026-05-05 05:29:17 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 12, 2016):

Fixed!

@netblue30 commented on GitHub (Nov 12, 2016): Fixed!

Rows
Columns

[GH-ISSUE #380] Programs start without sandbox if /proc is mounted with hidepid #273