RFE: Document libseccomp usage in multithreaded environment

[Talkless]

Looking at seccomp_init() and seccomp_load() man's raised me a question, what happens if I try to init() and load() another set of seccomp filters while running on another child thread, after main thread have completed that part?

In essence, can I restrict child thread more than that first-ever seccomp_load() execution did (probably in main thread), or calling any libseccomp functions (hence, underlying syscalls) after filters are applied won't work at all?

Thanks.

[pcmoore]

In essence, can I restrict child thread more than that first-ever seccomp_load() execution did (probably in main thread), or calling any libseccomp functions (hence, underlying syscalls) after filters are applied won't work at all?

The seccomp filters exist on a per-thread basis, and are inherited when the process/thread is forked, meaning it is possible to add additional filters to a given thread, separate from the rest of the threads in the process. You might also want to look at the libseccomp attribute SCMP_FLTATR_CTL_TSYNC in the seccomp_attr_set(3) manpage for a way to synchronize the seccomp filters across the threads of a process.

[FedericoCeratto]

In my understanding a compromised thread would be able to read and write the memory used by all the other threads within the same process. This could negate the security benefits of setting more restrictive seccomp rules to a given thread.
If that's true and there is no workaround maybe it should be good to add a warning in the documentation.