Bug#932762: fakeroot file somefile: Bad system call
Hi Christoph, On Fri, Jul 26, 2019 at 03:35:23PM +0200, Christoph Biedl wrote: > However, once we (as in Debian) promote seccomp, users will assume it's > available. Silently disabling it in in a way not obvious at all ... for > me it's like disabling the security belt in a car as soon as traffic > uses the left side of the street. I can hardly deny this. Still sometimes having the belt may be better than never. > Possibly there was a misunderstanding here: Since all the problems that > had arisen with seccomp support in file arose in the context of > packaging building (but see below), my idea was to disable seccomp in > the build proccess globally without creating side-effects like your > LD_PRELOAD approach does. Regular users should better not even know > about the existence of such a package. I think it would be great if users were never needing this file-buildd, but I think that there will be uses of LD_PRELOAD + file outside package building and users will gain this knowledge. > >> * Have a build system detection in file(1) > > > > This is only partially solving the problem. In essence, this approach is > > whack-a-mole. > > Err, it's just a refinement of your approach "Disable seccomp if > LD_PRELOAD is set". It's not. Checking LD_PRELOAD kills the entire problem space (likely too much). Checking for build systems only finds some applications of file + LD_PRELOAD. The difference is under-approximation vs. over-approximation. Also dpkg-buildpackage doesn't always need to remove seccomp since we have R³ now. > > Confine less code. (...) > > 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. > > I have to admit this solution is much saner then anything else. There > are some gotchas wrt compression but it should be possible to deal with > them, I'll do some research and take the idea to upstream. I didn't think of compression indeed. Likely, you need dynamic memory allocation here so you cannot use the non-bpf seccomp. Still the confinement could be reduced significantly to a point where file system interaction is not subject to seccomp. > And with another issue (syscall whitelist incomplete on arm64, #932947) > I think it's about time to end this experiment. It was insightful in > many ways but the result is file's seccomp support in its current state > is causing too many side-effects. The next upload in a few hours will > disable seccomp, and a new, saner attempt will hopefully follow soon. Thank you Helmut
Bug#932762: fakeroot file somefile: Bad system call
Helmut Grohne wrote... [ Disable seccomp if LD_PRELOAD is set ] > It may be broad, but we used to live without this security feature and > the approach should reliably fix the regressions. However, once we (as in Debian) promote seccomp, users will assume it's available. Silently disabling it in in a way not obvious at all ... for me it's like disabling the security belt in a car as soon as traffic uses the left side of the street. >> * 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. Possibly there was a misunderstanding here: Since all the problems that had arisen with seccomp support in file arose in the context of packaging building (but see below), my idea was to disable seccomp in the build proccess globally without creating side-effects like your LD_PRELOAD approach does. Regular users should better not even know about the existence of such a package. >> * Have a build system detection in file(1) > > This is only partially solving the problem. In essence, this approach is > whack-a-mole. Err, it's just a refinement of your approach "Disable seccomp if LD_PRELOAD is set". >> 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. Other issues were in debhelper and dh-strip-nondeterminism. I'd like to catch that as well. > Can I propose a third solution? > > Confine less code. (...) > 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. I have to admit this solution is much saner then anything else. There are some gotchas wrt compression but it should be possible to deal with them, I'll do some research and take the idea to upstream. And with another issue (syscall whitelist incomplete on arm64, #932947) I think it's about time to end this experiment. It was insightful in many ways but the result is file's seccomp support in its current state is causing too many side-effects. The next upload in a few hours will disable seccomp, and a new, saner attempt will hopefully follow soon. Christoph signature.asc Description: PGP signature
Bug#932762: fakeroot file somefile: Bad system call
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
Bug#932762: fakeroot file somefile: Bad system call
Control: reopen 932762 Control: severity 932762 important Control: retitle 932762 Needs a sane solution for running under LD_PRELOAD like fakeroot [ Taking Niels into the loop. I'm sorry the first approach didn't work out. ] With the problem preliminary fixed, the whole story needs some consideration. Aside, I noticed too late fakeroot-tcp is still broken, so another upload will follow soon-ish. Situation unchanged: When running under fakeroot, the file binary does (via libfakeroot) additional syscalls that are not whitelisted in the seccomp filter, hence breaking operation. This might happen in other LD_PRELOAD mechanisms as well. Helmut Grohne wrote... > The blocked syscall is 68 aka msgget. It is an IPC call used by > fakeroot to communicate the faked permissions. I think allowing more > syscalls in the sandbox is a bad idea. > > * You're whitelisting amd64 syscalls now. Other architectures use >different numbers and hunting them down for each and every >architecture is painful. JFTTR, whitelisting is done by a symbolic name - so this should work on all archs. > * fakeroot uses msgget when used with faked-sysv. For use with >faked-tcp, you will need socket and connect and stuff. > * Blocking IPC or network was exactly the job of seccomp. If you allow >these calls, you are significantly weakening the sandbox. Yes, figured that in the meantime, consider the whitelisting approach dead for that reason. > * Have you tried faketime, fakechroot, eatmydata, ...? faketime and eatmydata yes - but I assume there exist several more packages using LD_PRELOAD during build. > 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. 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 A second file package without seccomp, "Package: file-buildd", "Provides: file", and the toolchain/debhelper has an explicit dependency on that one. This would require all buildsystems have an explicit dependency on that packages, debhelper to start with. My only concern is users will start using this, "because the other one just creates trouble". Hence the somewhat obscure name. Feel free to propose another one. * Have a build system detection in file(1) The programs using LD_PRELOAD often leave specific data in the environment, file(1) could use that one, in theory. However, pseudo(1) does not, and as that detection should be generic, I fail to see this road leads anywhere. So the final solution I can think of is a distinct environment variable set by debhelper I could depend on. In either way, this requires some coordination with debhelper, and theoretically other build systems as well. And since the first one seems way saner to me, I am willing to take the additional efforts required (packaging, NEW) upon me as they are one-time only. Christoph signature.asc Description: PGP signature
Bug#932762: fakeroot file somefile: Bad system call
Hi Christoph, On Tue, Jul 23, 2019 at 01:13:51AM +0200, Christoph Biedl wrote: > Hm, let's give this a quick fix as a sound one. My plan is to whitelist > all the syscalls used by fakeroot. Are you aware of other environments > that might be caught by the same issue? Or in other words, which > syscalls were reported as inacceptable in the kernel log? The blocked syscall is 68 aka msgget. It is an IPC call used by fakeroot to communicate the faked permissions. I think allowing more syscalls in the sandbox is a bad idea. * You're whitelisting amd64 syscalls now. Other architectures use different numbers and hunting them down for each and every architecture is painful. * fakeroot uses msgget when used with faked-sysv. For use with faked-tcp, you will need socket and connect and stuff. * Blocking IPC or network was exactly the job of seccomp. If you allow these calls, you are significantly weakening the sandbox. * Have you tried faketime, fakechroot, eatmydata, ...? Let me propose a much simpler option: Check for the presence of LD_PRELOAD and imply -S when it is non-empty. Helmut
Bug#932762: fakeroot file somefile: Bad system call
Control: tags 932762 pending Helmut Grohne wrote... > Package: file > Version: 1:5.37-3 > Severity: serious > Control: affects -1 + src:unbound > > file no longer works under fakeroot. For example: (...) > Can we please disable seccomp until a solution for fakeroot is found? Hm, let's give this a quick fix as a sound one. My plan is to whitelist all the syscalls used by fakeroot. Are you aware of other environments that might be caught by the same issue? Or in other words, which syscalls were reported as inacceptable in the kernel log? Christopg signature.asc Description: PGP signature
Bug#932762: fakeroot file somefile: Bad system call
Package: file Version: 1:5.37-3 Severity: serious Control: affects -1 + src:unbound file no longer works under fakeroot. For example: $ fakeroot file /bin/true Bad system call $ echo $? 159 $ This is relevant when packages that still require root for building use fakeroot and then call file. autoconf tends to use file and such use breaks cross building unbound for mips64el as it detects LD="ld -m elf" instead of LD="ld -m elf64smip". I suspect that this is also what breaks building binutils and causes the autopkgtest regression. Can we please disable seccomp until a solution for fakeroot is found? Helmut
