Make it clear that ping writes to stdout and stderr.

It does not care that it's the terminal. From otto.
This commit is contained in:
Florian Obser 2023-02-19 11:21:02 +01:00
parent 2630fc6fbe
commit 087094cf06

View File

@ -146,12 +146,13 @@ parsing]][fn::I do not want to heckle FreeBSD, it is just that it is a
good illustration for what we are currently discussing. FreeBSD's good illustration for what we are currently discussing. FreeBSD's
ping(8) is using capsicum, so it is well locked away, too. And it is ping(8) is using capsicum, so it is well locked away, too. And it is
not like I am not making any [[https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/017_slaacd.patch.sig][mistakes]]...], a malicious ping target, or not like I am not making any [[https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/017_slaacd.patch.sig][mistakes]]...], a malicious ping target, or
even host in the middle, could still read and exfiltrate ssh even host in the middle, could still read and exfiltrate ssh private
private keys. ping(8) runs as my user-id. It can read all files my keys. ping(8) runs as my user-id. It can read all files my user can
user can read, it can open network connections to any host on the read, it can open network connections to any host on the internet, it
internet, it can execute arbitrary programs, heck it can talk to my can execute arbitrary programs, heck it can talk to my GPU. That is a
GPU. That is a lot of power that it does not need. It only needs to lot of power that it does not need. It only needs to write to =stdout=
write to the terminal and send and receive ICMP packets. and =stderr=[fn::Which is usually the terminal.], and send and receive
ICMP packets.
We could lock ping(8) away using chroot(2), that at least takes away We could lock ping(8) away using chroot(2), that at least takes away
file-system access. But what can we do about programs that need file-system access. But what can we do about programs that need