[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Miroslav Franc changed: What|Removed |Added Attachment #164984|0 |1 is obsolete|| --- Comment #20 from Miroslav Franc --- Created attachment 165137 --> https://bugs.kde.org/attachment.cgi?id=165137=edit implement --disable-seccomp=[no|yes] and seccomp syscall v4 Sorry, for the spam. I added another testcase and improved the remaining ones. The seccomp4 test is especially important, because it shows that valgrind will still work with seccomp filter active unless something important is blacklisted (I'm using alarm syscall there). Tested on x86_64 (kernel 6.6) and s390x (kernel 5.14). > $ perl tests/vg_regtest none/tests/linux/seccomp? > seccomp1:valgrind -q --disable-seccomp=yes ./seccomp1 > seccomp2:valgrind -q ./seccomp2 > seccomp3:valgrind -q ./seccomp3 > seccomp4:valgrind -q ./seccomp4 > > == 4 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == I would be grateful for any kind of review. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Miroslav Franc changed: What|Removed |Added Attachment #164961|0 |1 is obsolete|| --- Comment #19 from Miroslav Franc --- Created attachment 164984 --> https://bugs.kde.org/attachment.cgi?id=164984=edit --disable-seccomp=yes feature v3 I added two testcases and fixed linking of postwrappers. > $ perl tests/vg_regtest none/tests/linux/seccomp? > seccomp1:valgrind -q --disable-seccomp=yes ./seccomp1 > seccomp2:valgrind -q ./seccomp2 > seccomp3:valgrind -q ./seccomp3 > > == 3 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Miroslav Franc changed: What|Removed |Added Attachment #160505|0 |1 is obsolete|| --- Comment #18 from Miroslav Franc --- Created attachment 164961 --> https://bugs.kde.org/attachment.cgi?id=164961=edit --disable-seccomp=yes feature v2 Second version of the patch. It's not final, as I should throw in a few test cases. Disabling seccomp still allows SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES operations as those should never stop valgrind from working. I implemented some basic seccomp syscall checks (and left prctl as it was), then I thought I would throw in a few warnings based on how seccomp syscall api should be used, but I must say that the verbosity of the warnings surprised me. The default behviour: > $ valgrind file /bin/ls > ==17247== Memcheck, a memory error detector > ==17247== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==17247== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright > info > ==17247== Command: file /bin/ls > ==17247== > ==17247== WARNING: in STRICT SECCOMP mode 2nd argument (flags) should always > be 0 > ==17247== WARNING: valgrind is unlikely to work in STRICT SECCOMP mode > ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to > struct sock_fprog > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to > struct sock_fprog > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to > struct sock_fprog > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to > struct sock_fprog > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > ==17247== WARNING: in FILTER SECCOMP mode 3nd argument (args) should point to > struct sock_fprog > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > ==17247== WARNING: valgrind might not work in FILTER SECCOMP mode > Bad system call It seems to me that those warnings are not imaginary: > $ strace -e seccomp file /bin/ls > seccomp(SECCOMP_SET_MODE_STRICT, 0x1, NULL) = -1 EINVAL (Invalid argument) > seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT > (Bad address) > seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT > (Bad address) > seccomp(SECCOMP_GET_ACTION_AVAIL, 0, 0x7ffdbdae238c) = 0 > seccomp(SECCOMP_GET_ACTION_AVAIL, 0, 0x7ffdbdae238c) = 0 > seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 > EFAULT (Bad address) > seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, NULL) = -1 > EFAULT (Bad address) > seccomp(SECCOMP_GET_NOTIF_SIZES, 0, 0x7ffdbdae2392) = 0 > seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC_ESRCH, NULL) = -1 > EFAULT (Bad address) > seccomp(SECCOMP_SET_MODE_FILTER, 0, 0x564b7a15e490) = 0 > /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=22f5cfe4926547861d47486e96c0dceb360dec09, for GNU/Linux 3.2.0, > stripped > +++ exited with 0 +++ Disabling it works just fine: > $ valgrind --disable-seccomp=yes file /bin/ls > ==17584== Memcheck, a memory error detector > ==17584== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==17584== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright > info > ==17584== Command: file /bin/ls > ==17584== > /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=22f5cfe4926547861d47486e96c0dceb360dec09, for GNU/Linux 3.2.0, > stripped > ==17584== > ==17584== HEAP SUMMARY: > ==17584== in use at exit: 0 bytes in 0 blocks > ==17584== total heap usage: 838 allocs, 838 frees, 8,364,592 bytes allocated > ==17584== > ==17584== All heap blocks were freed -- no leaks are possible > ==17584== > ==17584== For lists of detected and suppressed errors, rerun with: -s > ==17584== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414
--- Comment #17 from Miroslav Franc ---
(In reply to Mark Wielaard from comment #15)
> Also note this patch that implements more of seccomp:
> https://sourceforge.net/p/valgrind/mailman/message/46305485/
To be honest. I was not trying to implement seccomp. I was trying to find a
way to turn it off. :-)
I took a look at the patch from the mailing list. Seeing "[PATCH 1/2]", is
there a second part to it? I see only one. I'm not subscribed to
valgrind-devel and the sourceforge web interface isn't the nicest one I have
seen.
If I read the valgrind-devel patch correctly, it does...
for SECCOMP_SET_MODE_STRICT
1/ make seccomp call visible two --trace-syscalls=yes
2/ say nothing about it's arguments
for SECCOMP_SET_MODE_FILTER
1/ make seccomp call visible two --trace-syscalls=yes
2/ tell valgrind it reads 3 arguments from registers
3/ tell valgrind it reads a memory from the third argument pointer (size of 1?)
I doesn't deal with SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES at
all.
In other words it does slightly less then what is currently being done for the
same operations invoked via older prctl syscall, because that tells valgrind it
reads 2 arguments from registers in case of SECCOMP_MODE_STRICT additionally.
To be fair, strict mode is a lost cause anyway for the simplests of programs,
unless they are specifically designed to run in it. It breaks even "int
main(void) {}" if you link against glibc, since glibc started invoking
exit_group(0) for all programs at some point (which is a syscall not allowed in
seccomp strict mode).
When I was writing the patch, I tried to preserve the prctl syscall case while
mark seccomp syscall as unimplemented. What I could do is basically copy paste
the prctl syscall case onto seccomp syscall case and tweak it and see how to
handle additional SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES
operations.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Mark Wielaard changed: What|Removed |Added See Also||https://bugzilla.mozilla.or ||g/show_bug.cgi?id=1288726 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=471340 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Mark Wielaard changed: What|Removed |Added CC||toralf.foers...@gmx.de --- Comment #16 from Mark Wielaard --- *** Bug 380183 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 --- Comment #15 from Mark Wielaard --- Also note this patch that implements more of seccomp: https://sourceforge.net/p/valgrind/mailman/message/46305485/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Sam James changed: What|Removed |Added CC||s...@gentoo.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 --- Comment #14 from Miroslav Franc --- (In reply to Paul Floyd from comment #13) > Is that safe to do? > > Valgrind, a bit like GDB, is a security risk. No doubt about that. But you can always make things safer by disallowing stuff. > On FreeBSD sysctl security.bsd.unprivileged_proc_debug controls whether > applications like gdb or valgrind can run. Does Linux have an equivalent? I haven't used FreeBSD for like 18 years, and I'm not sure what exactly it does, but there's a possibility of doing `sysctl -w kernel.yama.ptrace_scope=2` or similar on Linux to restrict what you can do with ptrace. But I don't think that restrict valgrind though, just gdb, strace etc. Is Valgrind using ptrace for something? > FreeBSD Valgrind does support Capsicum (it's capability mode interface), but > it just passes on syscalls (after printing a warning when calling > cap_enter). The means some Valgrind functionality is lost (specifically > opening files after entering capability mode which at least one of the tools > uses). The trouble is that it's a bit random about what is disallowed by seccomp. The default filter will kill valgrind for sure and otherwise it's about analyzing random cBPF filter that might be completely different per application. But, bear in mind is that I'm not proposing this to be the default behaviour. Nothing really changes except that you have now a choice to disable sandboxing. It's, I think, reasonably well described in the man page including the security implications. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #13 from Paul Floyd --- Is that safe to do? Valgrind, a bit like GDB, is a security risk. On FreeBSD sysctl security.bsd.unprivileged_proc_debug controls whether applications like gdb or valgrind can run. Does Linux have an equivalent? FreeBSD Valgrind does support Capsicum (it's capability mode interface), but it just passes on syscalls (after printing a warning when calling cap_enter). The means some Valgrind functionality is lost (specifically opening files after entering capability mode which at least one of the tools uses). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Miroslav Franc changed: What|Removed |Added CC||mfr...@gmx.com --- Comment #12 from Miroslav Franc --- Created attachment 160505 --> https://bugs.kde.org/attachment.cgi?id=160505=edit --disable-seccomp=yes feature I propose an option --disable-seccomp=[no|yes] feature to Valgrind, which would fake "seccomp" syscall (and an old style "prctl(PR_SET_SECCOMP...)") success if set to "yes" and would otherwise default to "no". "prctl" case remains the same unless "yes" is selected and "seccomp" case now returns ENOSYS unless "yes" is selected. The patch also adds the option to the --help output, man page, and "none/tests/linux/seccomp" test case to the testsuite. The usecase is that some programs only allow switching seccomp off at compile time. This way, they can be analyzed without recompilation (at the cost of sandboxing being turned off, because Valgrind is efefctivelly faking seccomp filter installation without doing anything). The proper emulation of the seccomp feature is impossible since Linux kernel doesn't allow switching between two different filters dynamically and partial solution with Valgrind analyzing cBPF program and whitelisting syscalls it needs for itself is too much work for very little gain. I tested the patch with the entire testsuite on x86_64 and s390x architectures (OpenSUSE Tumbleweed). Expected behaviour: $ valgrind -q --disable-seccomp=yes file /etc/passwd /etc/passwd: ASCII text $ valgrind -q --disable-seccomp=no file /etc/passwd Bad system call $ valgrind -q file /etc/passwd Bad system call $ perl tests/vg_regtest none/tests/linux/seccomp seccomp: valgrind -q --disable-seccomp=yes ./seccomp == 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 jb.1234a...@gmail.com changed: What|Removed |Added CC|jb.1234a...@gmail.com | --- Comment #11 from jb.1234a...@gmail.com --- Removed user jb.1234abcd from CC. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 --- Comment #10 from Tom Hughes --- A third option would be to report success but not actually do anything - that might be necessary for a program which refuses to proceed if it can't install it's seccomp filter but whose filter would break valgrind. The gold plated option of course would be try and modify the filter to allow any system calls valgrind might use in addition to anything which passes the original filter. That would be hard though, even if theoretically possible, and I'm not sure if even that is true. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 Mark Wielaard changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1800495 Ever confirmed|0 |1 Summary|I get the following when I |Missing seccomp support |ran valgrind WARNING: |(WARNING: unhandled |unhandled syscall: 317 |syscall: 317) CC||m...@klomp.org Status|REPORTED|CONFIRMED --- Comment #9 from Mark Wielaard --- There are more applications using seccomp now to create a kind of sandbox. e.g. qemu does (when using -sandbox=on). seccomp is a little tricky for valgrind to implement since valgrind itself might use system calls not used by the application running under valgrind since they are the same process. And the arguments are also tricky to interpret since depending on operation and flags this might be an arbitrary BPF program. We could simply return ENOSYS for seccomp and not produce the error/warning message. Or we could do some simple argument checks and pass it through as is to the kernel. That might then break valgrind if the seccomp call blocks some syscall we need, but things are already broken anyway. Or we could have a new command line flag --allow-seccomp that switches between the two modes of operation? -- You are receiving this mail because: You are watching all bug changes.
