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
1 changed files with 7 additions and 6 deletions

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
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
even host in the middle, could still read and exfiltrate ssh
private keys. ping(8) runs as my user-id. It can read all files my
user can read, it can open network connections to any host on the
internet, it can execute arbitrary programs, heck it can talk to my
GPU. That is a lot of power that it does not need. It only needs to
write to the terminal and send and receive ICMP packets.
even host in the middle, could still read and exfiltrate ssh private
keys. ping(8) runs as my user-id. It can read all files my user can
read, it can open network connections to any host on the internet, it
can execute arbitrary programs, heck it can talk to my GPU. That is a
lot of power that it does not need. It only needs to write to =stdout=
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
file-system access. But what can we do about programs that need