github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3567] Can't exec ping inside chroot #2237

New issue

Open

opened 2026-05-05 08:55:39 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 08:55:39 -06:00

Owner

Originally created by @purplesyringa on GitHub (Aug 3, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3567

I have a chroot environment with /bin/ping binary. The binary is non-suid but has cap_net_raw+eip capability. Unfortunately, running ping doesn't work inside firejail:

$ firejail --noprofile --chroot=skel ping
Parent pid 20544, child pid 20545

**     Warning: dropping all Linux capabilities     **
Warning: /var/lock not mounted
Warning: cannot hide /var/log directory
Warning: cannot find /var/run/utmp
Warning: cannot find home directory
Warning: failed to mount /sys
Child process initialized in 3.90 ms
/bin/bash: /usr/sbin/ping: Operation not permitted

Parent is shutting down, bye...

This is expected because all Linux capabilities are dropped. Whitelisting net_raw yields the following error:

$ firejail --noprofile --chroot=skel --caps.keep=net_raw ping
Error: all capabilities are dropped for chroot by default.
Please remove --caps options from the command line.

I know that running firejail as root, then dropping other capabilities and changing uid inside the jail is going to work, but I think a simpler solution should exist. What would be the security implications of allowing --caps.keep with --chroot?

Originally created by @purplesyringa on GitHub (Aug 3, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3567 I have a `chroot` environment with `/bin/ping` binary. The binary is non-suid but has `cap_net_raw+eip` capability. Unfortunately, running `ping` doesn't work inside `firejail`: ```shell $ firejail --noprofile --chroot=skel ping Parent pid 20544, child pid 20545 ** Warning: dropping all Linux capabilities ** Warning: /var/lock not mounted Warning: cannot hide /var/log directory Warning: cannot find /var/run/utmp Warning: cannot find home directory Warning: failed to mount /sys Child process initialized in 3.90 ms /bin/bash: /usr/sbin/ping: Operation not permitted Parent is shutting down, bye... ``` This is expected because all Linux capabilities are dropped. Whitelisting `net_raw` yields the following error: ``` $ firejail --noprofile --chroot=skel --caps.keep=net_raw ping Error: all capabilities are dropped for chroot by default. Please remove --caps options from the command line. ``` I know that running `firejail` as `root`, then dropping other capabilities and changing uid inside the jail is going to work, but I think a simpler solution should exist. What would be the security implications of allowing `--caps.keep` with `--chroot`?

gitea-mirror added the

enhancement

networking

labels 2026-05-05 08:55:39 -06:00

gitea-mirror commented

2026-05-05 08:55:41 -06:00

Author

Owner

@smitsohu commented on GitHub (Aug 3, 2020):

Generally speaking there is a problem if a privileged tool trusts a path, but permissions on this path are not adequate. Or the trusted file can be modified in another way, for example by mounting another file on top. This can happen if

the chroot environment was configured in an unsafe way
somewhere on the system there is a chroot'able directory we don't know about

By dropping all capabilities (and always setting the NO_NEW_PRIVS bit, which we also do), we effectively remove this attack surface. Maybe this could be made optional in the Firejail configuration file, but there probably should be a warning attached to it.

@smitsohu commented on GitHub (Aug 3, 2020): Generally speaking there is a problem if a privileged tool trusts a path, but permissions on this path are not adequate. Or the trusted file can be modified in another way, for example by mounting another file on top. This can happen if 1. the chroot environment was configured in an unsafe way 2. somewhere on the system there is a chroot'able directory we don't know about By dropping all capabilities (and always setting the NO_NEW_PRIVS bit, which we also do), we effectively remove this attack surface. Maybe this could be made optional in the Firejail configuration file, but there probably should be a warning attached to it.

gitea-mirror commented

2026-05-05 08:55:42 -06:00

Author

Owner

@purplesyringa commented on GitHub (Aug 3, 2020):

I am afraid that the current situation is even worse than allowing --caps.keep, because it's easier for a user to root-suid a tool (with possible security implications) than to patch firejail or add a launch script to the jail (and even then, it's easy to forget to drop some capabilities or such which are already handled by firejail itself). Hopefully we'll be able to use --caps.keep soon.

@purplesyringa commented on GitHub (Aug 3, 2020): I am afraid that the current situation is even worse than allowing `--caps.keep`, because it's easier for a user to root-suid a tool (with possible security implications) than to patch firejail or add a launch script to the jail (and even then, it's easy to forget to drop some capabilities or such which are already handled by `firejail` itself). Hopefully we'll be able to use `--caps.keep` soon.

gitea-mirror referenced this issue

2026-05-05 10:16:10 -06:00

[PR #2237] [MERGED] Update enpass.profile #4228

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2237

No description provided.

Rows
Columns