ping as non-root fails due to missing capabilities

[mika]

Current daily ISO of grml:

grml@grml ~ % ping grml.org
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?
2 grml@grml ~ %

Might be worth fixing this for new stable release?

[jkirk]

I quickly tried to figure out what the problem is.

On my Debian/bookworm system, ping has the following capabilities set:

❯ sudo getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep

ping on Grml has no capabilities set, but according iputils-ping.postinst it should have been set. So I am confused. Do you have an idea what the problem is?

root@grml ~ # getcap /usr/bin/ping
root@grml ~ # 
root@grml ~ # cat /var/lib/dpkg/info/iputils-ping.postinst 
#!/bin/sh

set -e

PROGRAM=$(dpkg-divert --truename /bin/ping)

if [ "$1" = configure ]; then
    # If we have setcap installed, try setting cap_net_raw+ep,
    # which allows us to install our binaries without the setuid
    # bit.
    if command -v setcap > /dev/null; then
        if setcap cap_net_raw+ep $PROGRAM; then
            chmod u-s $PROGRAM
        else
            echo "Setcap failed on $PROGRAM, falling back to setuid" >&2
            chmod u+s $PROGRAM
        fi
    else
        echo "Setcap is not installed, falling back to setuid" >&2
        chmod u+s $PROGRAM
    fi
fi
[...]

FTR, setting the capabilities manually fixes the problem (obviously):

root@grml ~ # setcap cap_net_raw+ep /usr/bin/ping
root@grml ~ # su - grml
grml@grml ~ % ping grml.org
PING grml.org (202.61.209.101) 56(84) bytes of data.
64 bytes from web.grml.org (202.61.209.101): icmp_seq=1 ttl=63 time=16.5 ms
^C
--- grml.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.537/16.537/16.537/0.000 ms

[jkirk]

I didn't try it yesterday, but FTR:

root@grml ~ # apt update
[...]
root@grml ~ # apt reinstall iputils-ping
[...]
root@grml ~ # su - grml
grml@grml ~ % ping grml.org
PING grml.org (202.61.209.101) 56(84) bytes of data.
64 bytes from web.grml.org (202.61.209.101): icmp_seq=1 ttl=63 time=17.3 ms
^C
--- grml.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.252/17.252/17.252/0.000 ms

grml@grml ~ % sudo getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep

So, it seems ping and the package itself is fine, but the cap_net_raw+ep capability got lost somewhere on the way.

[mika]

Thanks for looking into this. I tried to reproduce it, though it works fine and as expected both in my local builds as well in our daily ISOs. Feels to me like it's failing somewhere in our actual release builds where we use grml-live -e $ISO with unsquashfs etc :-/

[mika]

I tracked down the underlying issue, interesting one! 🤓

Good news: it's unrelated to the involved software versions (grml-live, squashfs-tools, fai-client, xorriso,…).

STR:

BASECHROOT='/tmp/basefile'
debootstrap --arch amd64 --exclude=info,tasksel,tasksel-data,isc-dhcp-client,isc-dhcp-common testing "$BASECHROOT" http://deb.debian.org/debian
tar -C "$BASECHROOT" --exclude='var/cache/apt/archives/*.deb' -zcf AMD64.tar.gz ./
mv AMD64.tar.gz /etc/grml/fai/config/basefiles/AMD64.tar.gz
grml-live …

To make it more obvious, it's failing due to the way our basefile gets generated:

# cd "$(mktemp -d)"
# tar -axf /etc/grml/fai/config/basefiles/AMD64.tar.gz           
# getcap usr/bin/ping                        
# 

So the problem is that in the created basefile the capabilities aren't stored.

Why wasn't this reproducible for us?

1. Our basefile dates back to 2023-11-17 (and includes iputils-ping v3:20221126-1)
2. The base build used for our 2024.02-rc1 release build also used that basefile (from install log: iputils-ping is already the newest version (3:20221126-1).)
3. Our current daily ISOs do not suffer from the problem though (and that's why it was hard to reproduce), because recently a new iputils-ping package version showed up in unstable/testing (see https://packages.qa.debian.org/i/iputils/news/20240211T194937Z.html). Its postinst maintainer script got executed and therefore receiving the capabilities after the basefile was extracted (and even though the underlying basefile didn't include the capabilities initially(!))

Solutions:

1. Don't use the basefiles at all
2. Create the basefile with --xattrs --xattrs-include='*.*' options (and when extracting manually, don't forget to specify the options again!). FAI also supports this with the basefiles since v5.5.1, see https://bugs.debian.org/881829

To speed up the builds, I'll go for option and re-build our basefiles, and also update our documentation accordingly.