Can't exec ping inside chroot

[purplesyringa]

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?

[smitsohu]

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.

[purplesyringa]

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.