Firejail: Ping replies going to wrong jails

[reinerh]

As reported here, when two ping processes are running in two separate jails, they BOTH receive ALL the replies.

Example (running both commands at the same time):

$ firejail ping ubuntu.com
PING ubuntu.com (91.189.94.40) 56(84) bytes of data.
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=1 ttl=57 time=42.3 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=1 ttl=54 time=43.8 ms (DUP!)
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=2 ttl=57 time=39.9 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=2 ttl=54 time=46.3 ms (DUP!)
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=3 ttl=57 time=40.0 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=3 ttl=54 time=44.2 ms (DUP!)

$ firejail ping debian.org
PING debian.org (5.153.231.4) 56(84) bytes of data.
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=1 ttl=54 time=43.8 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=2 ttl=57 time=39.9 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=2 ttl=54 time=46.3 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=3 ttl=57 time=40.0 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=3 ttl=54 time=44.2 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=4 ttl=57 time=41.6 ms
64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=4 ttl=54 time=42.4 ms

[SkewedZeppelin]

That seems pretty bad. Is this just limited to still having extra capabilities (net_raw)? ie. not a general flaw of firejail?

[reinerh]

It doesn't behave that way when running both pings as root without firejail.
Maybe related to network namespaces?

[netblue30]

Removed form firecfg, so we don't have a simlink for it under /usr/local/bin. I have no idea what's going on!

[Fred-Barclay]

I can't replicate on Arch but can on Ubuntu 18.04. Maybe a library difference?

[SkewedZeppelin]

@Fred-Barclay that is a bit weird. I just replicated again on both Arch and Fedora 27.

[Fred-Barclay]

@SkewedZeppelin What version of firejail did you use? I'm using firejail 0.9.53.

$ firejail ping ubuntu.com
PING ubuntu.com (91.189.94.40) 56(84) bytes of data.
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=1 ttl=48 time=132 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=2 ttl=48 time=133 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=3 ttl=48 time=132 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=4 ttl=48 time=135 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=5 ttl=48 time=139 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=6 ttl=48 time=132 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=7 ttl=48 time=143 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=8 ttl=48 time=135 ms
64 bytes from ovinnik.canonical.com (91.189.94.40): icmp_seq=9 ttl=48 time=132 ms

$ firejail ping debian.org
PING debian.org(klecker-misc.debian.org (2001:67c:2564:a119::148:14)) 56 data bytes
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=1 ttl=48 time=148 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=2 ttl=48 time=147 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=3 ttl=48 time=148 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=4 ttl=48 time=149 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=5 ttl=48 time=146 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=6 ttl=48 time=148 ms
64 bytes from klecker-misc.debian.org (2001:67c:2564:a119::148:14): icmp_seq=7 ttl=48 time=149 ms

[Fred-Barclay]

Ah, scratch that. Apparently if I make sure the addresses I ping are both IPv4 or IPv6, I can duplicate.

$ firejail ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=26.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=27.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=28.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=25.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=28.7 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=25.5 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=52 time=26.0 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=44.6 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=52 time=28.3 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=25.5 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=52 time=30.3 ms (DUP!)

$ firejail ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=52 time=26.0 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=44.6 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=52 time=28.3 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=25.5 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=52 time=30.3 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=25.5 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=52 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=55 time=25.7 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=52 time=26.0 ms

Similar when both are ping -6

[chiraag-nataraj]

I just replicated this in Debian sid/experimental with firejail 0.9.53.

[chiraag-nataraj]

Y'all, this is still an issue. How can we go about debugging this?

[chiraag-nataraj]

Okay, if this helps, I'm not seeing this when I create two separate network namespaces, but I still see the issue with the current firejail version (0.9.57 from master).

[chiraag-nataraj]

Still seeing this with current git master. How should we go about addressing this?

[chiraag-nataraj]

As I replied earlier, when I create new network namespaces, I'm not seeing the issue. Is this issue specific to ping or does it apply to other programs as well?

[matu3ba]

On arch I can not reproduce with current master and the following commands:

firejail ping 8.8.8.8
firejail ping 9.9.9.9

Closing or testing against other distros?

[reinerh]

I can confirm that I can no longer reproduce it.
Not even with the originally reported version (0.9.52).
So I guess it has been fixed somewhere else (kernel, glibc?).

I'll close it, as nothing needs to be fixed on the firejail side.