Why is ping special: why do "unprivileged pings" have to be enabled?

Question

Rootless podman, by proxy of the Linux Kernel, has restrictions against ping,

It is most likely necessary to enable unprivileged pings on the host.

Why do unprivileged pings need to be enabled? And what is the detriment to be able to send a ping packet?

Answer 1

Ping uses a special kind of IP (Internet Protocol) packet known as ICMP (Internet Control Message Protocol), as opposed to the much-more-common UDP (User Datagram Protocol, used for broadcast messages or anything where minimal overhead is needed) and TCP (Transmission Control Protocol, used everywhere reliable delivery is needed including most web traffic).

The Linux kernel (and other operating systems too) does not by default allow arbitrary processes to generate or receive ICMP traffic; instead, it is generated by low-level network drivers and hardware (and responded to at the same layer), well below the visibility of user applications. Thus, either ping needs special permissions to generate arbitrary IP packets (this is why, on many Linux systems, the ping binary is marked SetUID root... but of course that doesn't work on rootless environments) or the kernel must be re-configured to allow unprivileged processes to generate and receive ICPM traffic.

On modern Linux, there are a number of "capabilities" that control kernel-enforced privileges. Try man 7 capabilities (or see https://man7.org/linux/man-pages/man7/capabilities.7.html) to read about them and view the list. Some network-relevant ones are:

• CAP_NET_ADMIN, which allows controlling a bunch of network configuration stuff and is usually used by firewalls, VPNs, and tools like NetworkManager.
• CAP_NET_BIND_SERVICE, which bypasses the usual restriction on listening at TCP or UDP ports below 1024 and is used by server processes that want to listen on well-known ports without needing arbitrary root privileges, such as web and DNS servers.
• CAP_NET_RAW, which allows crafting and listening to network packets using arbitrary protocols, including ICMP; one of the main users is ping.

A simple way to give a process such capabilities is to have it run as root, since by default the root user has access to all capabilities (though this can be restricted, and is in various containers or sandboxes). However, root has for more privileges (both in terms of capabilities, and in terms of file system / object access) than most processes need, so it's a violation of the principle of least privilege to run things as root just because they need e.g. raw packet access. Thus, capabilities create a way to grant much more fine-grained and limited privileges, so fewer processes need to run as root. Processes can also drop capabilities after they no longer need them (e.g. a web server could bind to local TCP ports 80 and 443, and then drop the CAP_NET_BIND_SERVICE capability before it starts handling requests so that even if the server is compromised, it doesn't even have that privilege anymore.

---

As for why unprivileged apps aren't allowed to use ICMP, the short answer is that normal apps have no legitimate use for ICMP traffic (which is mostly for error handling, some but not all of which is the sort that causes the OS to report various error codes) so, by principle of least privilege, they can't use it. This isn't actually a restriction about ICMP at all; there are several protocols available on top of IP (and more protocol numbers that could be standardized to mean various new transports). The expectation is that if a program is using IP, it's probably able to do anything it needs via TCP or UDP, so giving it access to anything else is unnecessary risk. The fact that Ping (and Traceroute) are thus impaired is an unfortunate historical fact.

An incomplete list of specific attacks that can occur if programs are able to use ICMP or other non-TCP, non-UDP protocols:

• ICMP is used for error reporting, and a malicious program could report nonexistent errors along particular network paths. This might cause other programs to be unable to reach their destination hosts, or even the entire machine to incorrectly think the network is down.
• ICMP can be used for various attacks on servers, such as ping floods, misdirection attacks (where the attacker sends a ping which lies about its origin, and the router or destination server sends the response to another IP, increasing the target's network congestion and load), and overly-large packets that recipients fail to handle, such as the classic "ping of death". Obviously anybody on the Internet could be sending those at any time, so Internet-facing services need to be prepared for them, but inside a controlled environment (e.g. a corporate LAN), you might expect that such attacks won't occur because you haven't given any untrusted users root privileges and don't allow untrusted devices on the network.
• ARP (Address Routing Protocol) is used to associate MAC (physical) addresses to IP addresses on a LAN. A malicious process able to spoof ARP traffic can convince other machines on the same LAN that it - rather than the router - is the network gateway (by e.g. telling them that 192.168.0.1 maps to their own MAC address) and convince the router that the other machines' IP addresses are all actually located on its own IP address. The attacker thus gains a "man in the middle" position for all Internet traffic that the target machines send or receive, enabling many attacks. While this is hard to prevent in environments where arbitrary machines can connect to the network (e.g. a coffee shop), it's another case where a secure network such as a corporate LAN might assume no malicious code has the privileges required.
• ARP spoofing can of course also be used to just block other machines off of the network, or prevent them from communicating with specific network peers.