Traceroute needs net_admin capability for unknown reason

[Vincas Dargis]

With help of AppArmor on 17.04 and 17.10 I've discovered that traceroute needs net_admin capabilities.

My plan is to update [0] AppArmor profile to fix various DENIED messages in syslog/audit for traceroute, though I am not sure about allowing, or denying, net_admin capability.

Looks like traceroute tries to set SO_RCVBUFFORCE and SO_SNDBUFFORCE:

setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)

What is interesting, that traceroute developer does not recall changing these values [1]. On Debian Sid and OpenSuse Tumbleweed this issue does not reproduce either.

Could it be some Ubuntu-specific patch in the works? It seems that traceroute works OK without net_admin...

Thanks!

[0] https://code.launchpad.net/~talkless/apparmor/fix_traceroute_tcp/+merge/326260
[1] https://sourceforge.net/p/traceroute/mailman/message/35927818/

[Seth Arnold (seth-arnold)]

This smells a lot like a systemdism. Wild guess time, is systemd-resolved in use on this system?

Thanks

[Vincas Dargis (talkless)]

Yes, systemd-resolved is running, and strace says that it does something when `traceroute -T google.com` is executed.

[Vincas Dargis (talkless)]

Looks like culprit is libnss_resonve.so.

First of all, to reproduce, I have to use hostname like google.com. If I give traceroute an IP address, there are no setsockopt calls that needs net_admin cap.

Here's gdb log, breakpointed on setsockopt, dumped registers (you can see rdx set to "33" so that's one of SO_RCVBUFFORCE/SO_SNDBUFFORCE), and backtrace, that leads to /lib/x86_64-linux-gnu/libnss_resolve.so.2:

Breakpoint 1 (setsockopt) pending.
Starting program: /usr/sbin/traceroute -T google.com
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, setsockopt () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
rax 0x34000 212992
rbx 0x55ad9953abe0 94204090100704
rcx 0x7ffc27aac6d0 140720973989584
rdx 0x21 33
rsi 0x1 1
rdi 0x3 3
rbp 0x7ffc27aac6d0 0x7ffc27aac6d0
rsp 0x7ffc27aac6c8 0x7ffc27aac6c8
r8 0x4 4
r9 0x0 0
r10 0x7ffc27aac6d0 140720973989584
r11 0x202 514
r12 0x3 3
r13 0x7ffc27aac6d4 140720973989588
r14 0x7ffc27aac760 140720973989728
r15 0x55ad9953abe0 94204090100704
rip 0x7f057a78a320 0x7f057a78a320 <setsockopt>
eflags 0x293 [ CF AF SF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
#0 setsockopt () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f057af2cd43 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#2 0x00007f057af1ccd5 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#3 0x00007f057af46f02 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#4 0x00007f057af2287d in _nss_resolve_gethostbyname4_r () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#5 0x00007f057a76e16f in gaih_inet (name=name@entry=0x7ffc27aae76e "google.com", service=<optimized out>, req=req@entry=0x7ffc27aad400, pai=pai@entry=0x7ffc27aacf28, naddrs=naddrs@entry=0x7ffc27aacf24,
    tmpbuf=tmpbuf@entry=0x7ffc27aacf90) at ../sysdeps/posix/getaddrinfo.c:848
#6 0x00007f057a770448 in __GI_getaddrinfo (name=<optimized out>, service=<optimized out>, hints=0x7ffc27aad400, pai=0x7ffc27aad3f8) at ../sysdeps/posix/getaddrinfo.c:2391
#7 0x000055ad9791e326 in ?? ()
#8 0x000055ad9791e4b3 in ?? ()
#9 0x000055ad97921cae in ?? ()
#10 0x000055ad9791a7d1 in ?? ()
#11 0x00007f057a6a13f1 in __libc_start_main (main=0x55ad9791a700, argc=3, argv=0x7ffc27aad888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc27aad878)
    at ../csu/libc-start.c:291
#12 0x000055ad9791b3fa in ?? ()

[Vincas Dargis (talkless)]

Added systemd because:
# apt-cache show libnss-resolve | fgrep Source
Source: systemd

[Vincas Dargis (talkless)]

How could I get comment from Systemd maintainers..?