On Sat, Jul 27, 2019 at 03:55:36AM +0200, Christoph Biedl wrote: > LD_PRELOAD ruins your day. From the kernel's point of view there is no > difference between a syscall coming from the actual application and one > coming from the code hooked into it. And while the syscalls done by the > first (i.e. file) are more or less known, the latter requires > examination of each and every implementation and whitelisting > everything. Eventually fakeroot-tcp, wishes to open sockets, something > I certainly would not want to whitelist.
I ran into a ton of annoying problems like that when I added seccomp filtering to man-db (the idea there being to limit what damage might be done by potential bugs in groff and friends). The worst difficulties are from third-party programs that some people have installed: there are a couple of apparently fairly popular Linux antivirus tools that work by installing an LD_PRELOAD wrapper that talks to a private daemon using a Unix-domain socket and/or a System V message queue; there's a VPN that does something similar even though it really has no business existing at this level or interfering with processes that have nothing to do with networking; and there's the "snoopy" package in Debian that logs messages to /dev/log on execve. At the moment my compromise solution is to reluctantly open up the minimum possible set of syscalls I could find that stopped people sending me bug reports that were in fact caused by something injected from outside my software, and to limit most of that to only those cases where I've detected the relevant LD_PRELOAD wrappers as being present. This is pretty unsatisfactory, but I haven't found a better alternative ("ignore the problem and tell users to uninstall the third-party software in question after laboriously tracking down the exact cause of the seccomp failure in each and every case" isn't a viable solution in my mind). I suppose I could interpose a wrapper executable where I've forced ld.so into secure-execution mode somehow, but all the ways I know of to do that involve conferring some additional privilege on it which doesn't seem like the right way forward either. Or maybe I could have a wrapper executable and just unset LD_PRELOAD first. All very annoying. -- Colin Watson [cjwat...@debian.org]