On 2019-07-27 03:55, Christoph Biedl wrote:
Vincas Dargis wrote...On 2019-07-26 18:59, Christoph Biedl wrote: > > tl;dr: The file program in unstable is now built with seccomp support > > enabled, expect breakage in some rather uncommon use cases.Interesting, what are these uncommon use cases? Maybe we could confine itwith AppArmor instead, since we have it enabled by default?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.
FWIW the same is true when you just link against libraries and they change their behavior. That makes things pretty brittle.
That being said: It feels like if you face this situation, you could also fork off a binary with a clean environment (i.e. without LD_PRELOAD) and minimal dependencies and only protect that with seccomp. Of course you lose the integration point of LD_PRELOAD that others might want to use if you do that, in which case I guess one could offer a flag to skip that fork.
In terms of prior art SSH also forks off an unprivileged worker to handle network authentication in preauth and only seccomps that one rather than its main process. But it's also not doing the environment cleanup AFAICS.
Kind regards and thanks for making all of us more secure! :) Philipp Kern