DSOs loaded into different address after execve

[wangbj]

We setup seccomp filter rules based on DSO load address, unfortunately after execve syscall, the new DSOs can have different addresses, even when ASLR is disabled. seccomp filter rules are preserved after execve, however, they become worthless because of the addresses change. Need to find a way to workaround this, but it won't be easy, due to seccomp's design

[wangbj]

ptrace has an option called TRACE_O_SUSPEND_SECCOMP:

PTRACE_O_SUSPEND_SECCOMP (since Linux 4.3)
    Suspend  the tracee's seccomp protections.  This applies regardless of mode, 
    and can be used when the tracee has not yet installed seccomp filters.  That 
    is, a valid use case is to suspend a tracee's seccomp protections before they
    are installed by the tracee, let the tracee install the filters, and then clear this
    flag when the filters should  be resumed.   Setting  this  option requires that
    the tracer have the CAP_SYS_ADMIN capability, not have any seccomp
    protections installed, and not have PTRACE_O_SUSPEND_SECCOMP
    set on itself.

The description is rather vague (to me) whether or not it can be used to keep seccomp disabled unless tracee calls seccomp to setup filter by itself. So I did explore, and unfortunately even by calling PTRACE_O_SUSPEND_SECCOMP won't uninstall the old filter inherited from parents. After execve, even if tracee install new filters with seccomp suspended, after un-suspend seccomp, both filters inherited and new filters are in effect. So PTRACE_O_SUSPEND_SECCOMP won't help us.

[wangbj]

@rrnewton There's another way to address this issue: modifying kernel seccomp source code, by introducing a special flag just like CLOEXEC, I've got kernel patch and made a commit bdee820, it works very well, and fixed all the CI issues, we can even build musl-libc again by using echo tool, which is linked against glibc, using dlmopen.

The problem is it is quite painful because we need to patch Linux kernel, and most likely impossible with azure pipeline; Also it would be hard to get the kernel patch accepted by mainstream linux kernel.

[wangbj]

kernel patch can be found in commit a0cf8b1

[rrnewton]

Very cool ;-). Let's see what they think.