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
