Skip to content
This repository has been archived by the owner on Dec 30, 2021. It is now read-only.

DSOs loaded into different address after execve #54

Open
wangbj opened this issue Jul 22, 2019 · 4 comments
Open

DSOs loaded into different address after execve #54

wangbj opened this issue Jul 22, 2019 · 4 comments

Comments

@wangbj
Copy link
Collaborator

wangbj commented Jul 22, 2019

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
Copy link
Collaborator Author

wangbj commented Jul 23, 2019

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
Copy link
Collaborator Author

wangbj commented Jul 25, 2019

@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
Copy link
Collaborator Author

wangbj commented Jul 26, 2019

kernel patch can be found in commit a0cf8b1

@rrnewton
Copy link
Collaborator

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants