❦ 28 juillet 2019 12:11 +02, Philipp Kern <phil@philkern.de>:
>> 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?
Yes, but I was thinking to cases where you run kernel from oldstable
with stable for example. This is something currently allowed that may
not work anymore. I am just providing the information, I don't have a
strong opinion if seccomp should or shouldn't be enabled.
--
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature