torsocks: Unsupported syscall 157 (prctl)
== Overview
I run . torsocks on
by default and recently ran into this nuissance:
$ ls
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
foo/ bar.baz
== Version Info
$ lsb_release --all
LSB Version: 1.0
Distributor ID: VoidLinux
Description: Void Linux
Release: rolling
Codename: void
$ uname --all
Linux lang 5.4.8_1 #1 SMP PREEMPT Sun Jan 5 18:00:07 UTC 2020 x86_64 GNU/Linux
$ torsocks --version
Torsocks 2.3.0
$ ls --version
ls (GNU coreutils) 8.31
...
$ xbps-query -p pkgver libcap # see below for explanation
libcap-2.30_1
== Sleuthing the Cause
Grepping the linux kernel syscall table
$ cd path/to/kernel/git/repo/
$ grep 157 arch/x86/entry/syscalls/syscall_64.tbl
157 common prctl __x64_sys_prctl
So it looks like coreutils' ls is (eventually) calling prctl; indeed
$ strace -e prctl ls
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x28 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_BLOCK_SUSPEND) = 1
prctl(PR_CAPBSET_READ, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_AUDIT_READ) = 1
foo/ bar.baz
which correspondings nicely with the six warnings from above. The issue appeared quite recently on my machine; however, both the torsocks and coreutils I am running are not particularly new and have been running on my system for a while. Doing a little spelunking:
$ ldd /usr/bin/ls
linux-vdso.so.1 (0x00007ffcfb53d000)
/usr/lib/torsocks/libtorsocks.so (0x00007f1e5509e000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f1e5507f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f1e54ebc000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f1e54eb7000)
/lib/ld-linux-x86-64.so.2 (0x00007f1e550dc000)
libcap looks the most suspicious, and indeed, on my system it is the only library that has been recently updated:
$ xilog libcap-2.30
libcap-2.30_1 : 2020-01-07 09:13 JST
So we can be reasonably confident that a recent libcap update unearthed this potential regression.
== Comments
The security implications of prctl
are beyond my expertise, but given that it manages capabilities, I am guessing this would not be a trivial patch. Is there any hope this could be fixed or mitigated?
Trac:
Username: eirizuhaex