[PATCH] traceroute: delete the verification of root user

[tito]

On Sun, 2 Mar 2025 23:37:09 +0800 (GMT+08:00)
范星宇 <isfanxy at 126.com> wrote:

> Thanks for your reply!
> 
> 
> I have done a test as a non-root user to perform traceroute -s:
> 1. Busybox process without CAP_NET_RAW will fail in opening a new socket(xsocket, libbb/xfuncs_printf.c, EPERM).
> 2. Busybox process with CAP_NET_RAW will succeed in opening a new socket and fail in the root check.
> 
> It seems "traceroute -s" is available just for root user.
> I mean, is it possible for kernel to decide whether traceroute succeeds, instead of busybox's specific judgment?
> 
> Could you give any advice about the necessity of getuid() == 0 when using "traceroute -s"? The capability of busybox process isn't secure enough to avoid the root check?

Hi,
I suspect that the necessity arises out of tradition to do so. Many programs warn if they
require root privileges and are not run as root, just a few for example:
 
   apt upgrade
    Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

    mount: /backup: must be superuser to use mount.

    umount: /backup: must be superuser to unmount.

   shutdown
   shutdown: you must be root to do that!
  
   reboot
   reboot: must be superuser.

  adduser
  adduser: Only root may add a user or group to the system.

  deluser
  deluser: Only root may remove a user or group from the system.

  swapoff -a
  swapoff: Not superuser.

 fsck.ext4 /dev/sda
  e2fsck 1.47.0 (5-Feb-2023)
 fsck.ext4: Permission denied while trying to open /dev/sda
 You must have r/w access to the filesystem or be root
 
 for sure there many others.
 
 Why they do that:
 1) when they were written there were no capabilities, so this was the only way;
 2) to educate the user about what actions are reserved to the superuser
      or system administrator because this actions can harm the system
      or are a security concern;

Number 2 is rather important in my view and worth the effort because in 
the long run it produces better users and maybe the sysadmins of tomorrow.

Nowadays there are other ways like capabilities, ACLs etc. for a finer grained
control of who is allowed to perform what action.
So the question is  what to do with the checks and warnings:

1) do nothing
2) rip out all checks and  just let the system throw cryptic error messages
3) follow tradition and continue to warn to educate the user
 
I think the 3rd option is the most useful in the long run.

BTW: newer versions of traceroute use different techniques to perform the trace,
such as sending UDP packets with increasing TTL (Time-to-Live) values instead
of raw ICMP packets and do not require raw socket access and so users do not
need root permissions.

So if we check for root we can also check for CAP_NET_RAW if needed
or switch to an implementation that doesn't need root.

Just my 2 cents.

Ciao,
Tito
> 
> 
> 
> 
> 
> 
> ---- Replied Message ----
> | From | Henrique de Moraes Holschuh<henrique at nic.br> |
> | Date | 3/1/2025 23:20 |
> | To | <busybox at busybox.net> |
> | Subject | Re: [PATCH] traceroute: delete the verification of root user |
> On 01/03/2025 09:38, tito wrote:
> couldn't you check if the capability is available?
> 
> Why?  It is just as problematic as the euid() == 0 test.  One could be
> root without CAP_NET_RAW.  One could be non-root with CAP_NET_RAW.  One
> could be constrained by any other kernel-side policy...
> 
> Instead, I recommend that you don't assume you cannot (or can) send packets.
> 
> Try to open (and if you want/need to, connect()) the socket, and if that
> succeeds, try to send the packets.  Should you get EPERM or EACCES back
> on any of those syscalls, you report that you don't have permission to
> send RAW packets.
> 
> Maybe you will also need to cover more errors than just EPERM and
> EACCES, but the idea that "don't assume you cannot do it, try and report
> errors instead" still holds.
> 
> You could differentiate socket() and connect() as "cannot create raw
> socket", and send()/sendto()/write() as "cannot send raw packets", for
> better user experience.
> 
> Please remember to handle EPERM results as "permission denied": Linux
> can return EPERM for send()/sendto() due to local firewall rules in many
> cases.  socket() may return EPERM in several operating systems (maybe
> also Linux), etc.
> 
> 
> Suggestions:
> 
> (for EACESS, EPERM on socket(), connect()):
> "cannot open raw socket: permission denied.  You might need root or
> CAP_NET_RAW for this to work".
> 
> and
> 
> (for EPERM, EACCES on sendto()/send()/write()):
> "cannot send packet: permission denied.  You might need root or
> CAP_NET_RAW for this to work.  Also check local firewall rules"
> 
> 
> --
> Henrique de Moraes Holschuh