larry@focsys.UUCP (Larry Williamson) (08/09/89)
On our System V/386 Unix, ping works only if the effective user id of ping is root. Is this really necessary? As a temporary measure, I've chmod'd ping to run as root. Is this a bad idea? If it matters, the system is Interactive 386/ix 1.0.6 and their host based tcp/ip package v1.0.3. -larry
barmar@think.COM (Barry Margolin) (08/10/89)
In article <525@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: >On our System V/386 Unix, ping works only if the effective >user id of ping is root. Is this really necessary? >As a temporary measure, I've chmod'd ping to run as root. >Is this a bad idea? From the source code (which is public domain): * This program has to run SUID to ROOT to access the ICMP socket. ICMP is connectionless, and reading the ICMP socket gives the caller a copy of *all* ICMP packets received by the system. Since it permits access to packets not necessarily intended for that particular process, it may only be accessed by root. It's safe to setuid ping. It filters out the packets not associated with the ping, so there is no security problem there. The only reason not to would be if you are worried about users wasting net bandwidth by running lots of pings. Since there are plenty of other ways to waste net bandwidth, I wouldn't worry. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/10/89)
In article <26366@news.Think.COM>, barmar@think.COM (Barry Margolin) writes: > > It's safe to setuid ping. ... I wouldn't worry. > > Barry Margolin > Thinking Machines Corp. > barmar@think.com > {uunet,harvard}!think!barmar While on balance ping seems too useful to restrict, it is only fair to mention that `ping -f <broadcast>` is a handy way to melt the wire. If a bad guy does not have a ping with -f, then `repeat 100 eval "ping <broadcast> > /dev/null &"` is as good. Unless you've changed things to not respond to ICMP echo requests to broadcast addresses. Vernon Schryver Silicon Graphics vjs@sgi.com