Russ Allbery wrote... > Christoph Biedl <debian-devel@lists.debian.org> writes: > > > tl;dr: The file program in unstable is now built with seccomp support > > enabled, expect breakage in some rather uncommon use cases. > > Thank you very much for doing this! Here's hoping this sets a trend. It > will provide so much defense in depth against malicious files.
Thanks for the positive feedback. While I agree seccomp is something
nice to have, I'd like to share two two very different thoughts that
arose while doing this.
The first one is Debian-specific: Declaring build-dependencies on
libaries that are not available in all archs, like seccomp.
This is not at all specific for seccomp, but perhaps it's one of the
places where this problem is seen relatively often. So read "seccomp"
as "$seccomp", describing a library that does not exist in all
architectures.
The build system of the file package uses autoconf to check for
presence of the seccomp library and will just disable that feature if
support is missing. But just adding "libseccomp-dev" will break the
build on e.g. alpha for an unsatisfyable build dependency - I don't
wish to simply ignore that. So I have to make sure lack of seccomp in
these architectures does not break the build.
Solutions I've seen (use codesearch to find examples):
* People don't care
* People add a hard-coded list of archs into the dependency clause
like "libseccomp-dev [amd64 ...]"
The first I consider plain ignorant.
The second puts work on each package maintainer who uses libseccomp in
the build dependencies: The list of supported archs may change, and
having to maintain this in many places is unrealiable and also stupid
work. Still it does the job - I am just looking for a better way.
Solutions I can think of:
* 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.
* Add an always-satisfyable alternative clause, like
"Build-Depends: libseccomp-dev | base-files".
Yuck.
* 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.
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.
Christoph
signature.asc
Description: PGP signature
