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
it
with 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