Traceroute needs net_admin capability for unknown reason

Bug #1703649 reported by Vincas Dargis
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Invalid
Undecided
Unassigned
traceroute (Ubuntu)
New
Undecided
Unassigned

Bug Description

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/

Vincas Dargis (talkless)
description: updated
description: updated
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Thanks

Revision history for this message
Vincas Dargis (talkless) wrote :

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

Revision history for this message
Vincas Dargis (talkless) wrote :

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 ?? ()

Revision history for this message
Vincas Dargis (talkless) wrote :

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

Revision history for this message
Vincas Dargis (talkless) wrote :

How could I get comment from Systemd maintainers..?

Dan Streetman (ddstreet)
Changed in systemd (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.