Hi Christoph, I've also Cced Kees Cook as he's done a lot of hardening in Linux and Debian and I'd like his input on this matter, because we're talking about trade-offs here. (Context: "fakeroot file ./foo" fails due to seccomp)
On Tue, Jul 23, 2019 at 12:52:55PM +0200, Christoph Biedl wrote: > > Let me propose a much simpler option: Check for the presence of > > LD_PRELOAD and imply -S when it is non-empty. > > This however is very broad and and has a risk risc of silently > disabling this security feature in a production system, so, no. It may be broad, but we used to live without this security feature and the approach should reliably fix the regressions. > What I am looking for now is to disable seccomp in a build environment > only. For the moment I can think of two ways to handle this: > > > * Have a second file package without seccomp support Please excuse my bluntness. This approach is wrong. Any security that requires attention from the user is bad security. If each and every user needs to figure out to install file-buildd when they use file with LD_PRELOAD, this has a very bad cost/benefit ratio. > * Have a build system detection in file(1) This is only partially solving the problem. In essence, this approach is whack-a-mole. > So the final solution I can think of is a distinct environment variable > set by debhelper I could depend on. The actual issue that made me file this bug was autoconf, not debhelper. Can I propose a third solution? Confine less code. The issue at hand is that file sets up its sandbox early and thus has to allow a ton of system calls (including open and write) even in the full sandbox. You can easily append to ~/.bashrc and escape the next time a user logs in. I'm arguing that this sandbox is somewhat useless, because it is way too weak. If file were opening the input file and the magic database prior to applying the sandbox, it could support a much stricter sandbox. In principle, it could do with just write (for communicating the result) and _exit. You can implement that using prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, 0, 0, 0), which is available for more than 10 years now. The code for loading (not parsing) the input file and the magic database is relatively harmless and confining it is what breaks fakeroot. The parsing code doesn't need syscalls, so it should be unaffected by most LD_PRELOAD hacks. Of course, getting there is essentially rewriting the seccomp feature in file. You cannot easily bolt it onto file in the way it currently is. TL;DR: * Having people choose a file package is going to cause pain. * Detecting build systems is going to be whack-a-mole. * The current seccomp support is mostly useless, because it allows way too many syscall. Helmut
