[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: file(1) now with seccomp support enabled



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


Reply to: