Re: Linux: Disabling network namespaces

["Priedhorsky, Reid" <reidpr () lanl gov>]

> On Apr 21, 2024, at 6:00 AM, Simon McVittie <smcv () 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

Attachment: ch_core.c
Description: ch_core.c