Christoph Biedl <debian.a...@manchmal.in-ulm.de> writes: > * Centralize the list of supported archs in the seccomp packages. By > either creating an empty libseccomp-dev for the archs where seccomp > is not supported, or by creating a "libseccomp-dev-dummy" for these. > In the latter case package maintainers would have to do a one-time > change of the build dependency into "libseccomp-dev | > libseccomp-dev-dummy" and can focus on other issues then.
For what it's worth, not being a libseccomp maintainer, I really like this idea. > * Introduce a statement for relaxed build dependencies. In other words, > a new "Build-Depends-Try:" or "Build-Recommends:" that will be tried > to be satisfied, but failure to do so will emit a warning at most. > Honestly, the last one has a lot of charm since it means a one-time > effort only. That effort however is huge and includes convincing > several people to implement it. It has some irritating build reproducibility issues, although maybe they're adequately dealt with via build manifests. > The second is questioning whether seccomp is something feasible on the > big scale. The domain of a seccomp filter set is the application, and > the way more and more libraries might be linked in during development, > the more syscalls have to be whitelisted, defeating the idea of > seccomp. So in consequence you'll either create a lot of small programs > or several threads with different sets of whitelisted syscalls. In > either way a lot of IPC is needed which is time-consuming and > error-prone, in implementation, execution, and debugging. Yeah, it's tricky, particularly when one is trying to support general applications. I think the best case scenario is something like file, where the scope is pretty limited. Another pattern that can work is to identify the particularly problematic bit of code where you think most of the bugs are (often in the parser, for instance) and try to delegate only that portion to one subprocess, although that does mean a lot of IPC. (Particularly since we don't have a great standard data packing format to pass things back and forth.) I would love to see more places where seccomp is at least present, if optional and off by default, since it provides an option to use the program more securely and accept that it breaks a lot of features. A great example would be ghostscript -- I would love to be able to prevent it from executing programs, writing to arbitrary files, and many other things that, strictly speaking, are part of the PostScript spec and therefore upstream wants to support in the more general case. Everyone who cares about this already has to pass in -dSAFER, so we're already dealing with the complexity cost of this being optional. This is hard and I don't think we have a great ecosystem or set of libraries or techniques around this yet, but I also think adding these types of syscall filters has way more security impact per unit time than tuning compiler options or plowing through fuzzing bugs, since it can remove whole classes of attacks permanently regardless of future code errors. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
