search

reverie-rs / reverie

trace and intercept linux syscalls.
Other
14 stars 5 forks source link

DSOs loaded into different address after execve #54

Open wangbj opened 5 years ago

wangbj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 bdee82055e4d2dbf5f84cd420a24ac44d8137e56, 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 commented 5 years ago

kernel patch can be found in commit a0cf8b17

rrnewton commented 5 years ago

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