> > On Apr 21, 2024, at 6:00 AM, Simon McVittie <s...@debian.org> wrote: > > bubblewrap doesn't rely on seccomp itself, because linking to libseccomp > and compiling seccomp programs would be a concerning amount of attack > surface for a program that is optionally setuid root, but it has options > that can be used to make it receive a precompiled seccomp program as a > binary blob and submit it to the kernel.
libseccomp isn’t needed to write seccomp programs; you can use the macros that come with the kernel to build up the program struct manually. It’s a bit tedious and the bookkeeping can be finicky, but I’ve written worse C code. We (Charliecloud, a container implementation) did this to likewise avoid a libseccomp dependency, though I’ll emphasize that unlike many container implementations, we do not maintain any security boundary. If anyone wants to see the code, I’ve attached a copy of the relevant file, and the current version is here: https://github.com/hpc/charliecloud/blob/master/bin/ch_core.c I suspect a seccomp filter to block new network namespaces would be straightforward. For unshare(2) and clone(2), one could just examine the flags argument. clone3(2) takes flags in a pointed-to struct, and seccomp programs can’t dereference pointers, so the filter would need to delegate to a userspace process (with SECCOMP_RET_TRACE or SECCOMP_RET_USER_NOTIF). In either case, however, the seccomp filter itself would be reasonable to do manually without libseccomp. HTH, Reid — he/his
ch_core.c
Description: ch_core.c
