I noticed this weird thing: 1) ping is working 2) start apt dist-upgrade 3) at some point new ping stops working with ping: socket: Operation not permited for minutes. 4) apt dist-upgrade finishes 5) ping works again That is not nice. Looking at dpkg.log I see this: 2020-09-24 01:34:40 upgrade iputils-ping:amd64 3:20190709-3 3:20200821-2 2020-09-24 01:34:40 status half-configured iputils-ping:amd64 3:20190709-3 2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20190709-3 2020-09-24 01:34:40 status half-installed iputils-ping:amd64 3:20190709-3 2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20200821-2 ... ... 2020-09-24 01:45:28 configure iputils-ping:amd64 3:20200821-2 <none> 2020-09-24 01:45:28 status unpacked iputils-ping:amd64 3:20200821-2 2020-09-24 01:45:28 status half-configured iputils-ping:amd64 3:20200821-2 2020-09-24 01:45:28 status installed iputils-ping:amd64 3:20200821-2 So I suspect there is something critical in configure that prevent ping from working during this intermitent period. Wish it could be fixed somehow.
Control: severity -1 minor The ping process requires the ability to open a raw network socket, which is a privileged operation. The ping binary contained within the package is completely unprivileged, so when it's initially installed it can only be executed by the root user or some other user that has retained the cap_net_raw capability. Later in the installation process, the package's post-install script tries to add the cap_net_raw file-based capability to the binary as that's the safest (least privileged) way to grant users the ability to run ping. If that fails, probably because the system is configured with some unusual filesystem that doesn't support file-based capabilities, then the script sets the suid bit on the binary, granting unprivileged users the ability to run ping with a slight reduction in the security posture. I'm not sure of a practical way to avoid this situation. If .deb files could contain files with capabilities set on them, then this would likely improve the situation for most users, but I believe it's still the case that this isn't possible. You can see the script in question at https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst noah
Thanks Noah. I was not sure if ping is using suid as in the past, or the capabilities. You are of course right: root@debian:~# ls -l `which ping` -rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping root@debian:~# getcap `which ping` /usr/bin/ping cap_net_raw=ep root@debian:~# This looks like a limitation that would only be possible to solve by dpkg and extending tar / cpio probably. From what I found it is possible to do this with tar and --xattrs-include='security.capability' when packing and unpacking. There is some hacky non-standard patches for cpio, https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef , but afaik not upstreamed. And even more hacky support in kernel for initramfs uses: https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg00001.html I didn't see any real updates on this topic, last one is from middle of 2019. I agree it is hard. Cheers.
Control: reassign -1 src:dpkg Control: severity -1 wishlist I'm reassigning this to dpkg as a wishlist item. If the problem is going to be fixed, it's going to happen at a layer more fundamental to package management. Context for the dpkg maintainers: Ping requires elevated privileges in order to open its ICMP network sockets. The postinst script attempts to set a file-based cap_net_raw capability on the binary after installation, and falls back to setuid in case that fails (usually due to missing filesystem support for file capabilities). This workflow is racy, however, as there's a period of time when the file exists on disk but has not had any privilege acquisition mechanism applied to it. During this period of time, unprivileged users cannot run this program, when otherwise they could. Elimination of this race situation would likely require the ability for dpkg to initially create files with additional file-based capabilities. noah
Hi! [ Thanks! Only thing missing was an explicit Cc to dpkg@packages.debian.org or similar, as the BTS does not do that. :/ ] So, implementing this in dpkg, would require at least the upcoming metadata tracking support <https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>, which is currently blocked. Another approach to get similar results would be just having support in dpkg-statoverride (tracked in #502580). But a way to implement this more reliably already in iputils would be to ship the file in the .deb as set-UID-root (so that it always can work), and apply the POSIX capabilities and remove the set-UID-root bit in the maintscript if the system supports the former. Thanks, Guillem
Hi, I've blocked 827479 and 1098773 on this bug; they request file capabilities (instead of setuid root) on newgrp and newuidmap, newgidmap. I don't really want to play postinst games in their respective packages, except if really necessary. (I've seen this, but still. Would be a lot better without a postinst.) Chris