Re: file(1) now with seccomp support enabled
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 [cjwatson@debian.org]
Reply to: