[PATCH] ping: try SOCK_DGRAM if no root privileges

[Rich Felker]

On Fri, Jan 10, 2014 at 09:33:56PM +0000, Laurent Bercot wrote:
> On 2014-01-10 19:27, Rich Felker wrote:
> 
> >Note that this kind of approach STILL does not protect you from
> >vulnerabilities in the dynamic linker (avoiding them would require
> >making both the wrapper and busybox binary static-linked)
> 
>  Which is the case for me.
> 
> >or libc startup code (inevitable).
> 
>  I'm using musl, it looked like a good, paranoid libc; maybe I was
> lied to ? :-O

Part of being good and paranoid is not trusting even yourself that
much. :-) But I was thinking more of other libcs that have more
complicated startup code.

> >[dangers of suid]
> >This is why I want to see a ping that works without suid.
> 
>  So do I. I also want to write a simple user database backend (with
> its own getpwent() implementation) so that passwd doesn't need to
> be setuid root.

These are much harder problems. The difficulty of solving a harder
problem is not an argument for not solving easy ones. BTW, musl also
supports /etc/tcb/ shadow passwords, another feature from Owl,
whereby, depending on how you set permissions, it's trivial to write a
passwd utility that does not need root to change your password.

> And a Unix-socket-based "su" daemon with credential
> passing, and terminal passing too.

alias su="ssh root at localhost" makes a decent substitute.

> And rewrite qmail-queue as a
> Unix-socket-based daemon.

Now we're well outside the scope of things in Busybox.

> And a non-setuid traceroute.

Non-Busybox traceroute already does it. Busybox traceroute --help
implies it supports UDP-based trace, so I don't know why it tries to
open a raw socket and aborts when it fails. Ideally the same method
proposed for ping could also be supported by traceroute to allow
ICMP-based trace by non-root, but I think this is lower-priority than
support in ping since traceroute generally works fine with UDP or TCP.

> And a pony.

IIRC we have some MLP fans in #musl who might could help. :-)

>  In the meantime, I also want a usable, working system. As Denys
> noted, cleansing the existing codebase of setuid is an energy- and
> time-consuming practice; in the name of good compromise between
> practicality and security, I will still use the setuid binaries I need
> until I've replaced them (or, better, until you and John have done all
> the hard work for me), while making sure privileges are only gained
> when they are strictly required.

*nod*

It's still rare that I use systems with absolutely no suids, but I'd
like to move more in that direction, and lack of ping is a big point
of frustration that would be easy to fix.

Rich