❦ 19 juillet 2019 17:18 +02, Christoph Biedl <debian-devel@lists.debian.org>:
> Upstream of the file package added seccomp support a while ago, and
> probably everyone with even a small concern about security will agree
> the file program, often being used on dubious or even doubtless
> malicious input, should use seccomp to make the attack surface smaller.
> However I refrained from enabling this feature back then just weeks
> before the buster freeze, in restrospect: indeed the right decision.
> Now this early moment in the bullseye development cycle is a good time,
> so there's version 1:5.37-2, accepted in unstable a few moments ago.
Hello,
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).
--
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature