On 2019-07-27 10:01, Vincent Bernat wrote:
Just a quick note: seccomp filters may need adaptations from one libc
to
another (and from one kernel to another as the libc may adapt to the
current kernel). For example, with the introduction of "openat"
syscall,
the libc has started to use it for "open()" and the new syscall has to
be whitelisted. On the other hand, if you start implementing seccomp
filters late, you may have whitelisted only the "openat" syscall while
older libc (or current libc running on older kernels) will invoke the
"open" syscall.
I am upstream for a project using seccomp since a long time and I have
never been comfortable to enable it in Debian for this reason. However,
they enable it in Gentoo and I get the occasional patches to update the
whitelist (I am not doing anything fancy).
But technically it should be possible to test this in an autopkgtest,
no? I don't think perfect has to be the enemy of good here, as long as
we can detect breakage and remediate it afterwards?
Technically you cannot use any non-vendored libraries when enabling
seccomp if you reason about it this way. Practically it mostly works
except sometimes when the filters need to be adjusted. And as you can
see Gentoo deals with that just fine and we could accept some breakage
in unstable too, as long as the migration of the breaking library is
stopped until the fix for the dependencies is in.
Kind regards
Philipp Kern