On the dynamic linker bypass specifically, have you looked at fapolicyd [1]? It uses fanotify(7) and the top of the README is:
> The restrictive policy was designed with these goals in mind:
> 1. No bypass of security by executing programs via ld.so.
> 2. Anything requesting execution must be trusted.
One correction on the table: SELinux and AppArmor shouldn't be grouped under "rename-resistant: No". AppArmor is path-based. SELinux labels are on the inode, a rename doesn't change the security context. The copy attack doesn't apply either: a process in sandbox_t creating a file in /tmp gets tmp_t via type transition, and the policy does not grant sandbox_t execute permission on tmp_t.
> The restrictive policy was designed with these goals in mind:
> 1. No bypass of security by executing programs via ld.so.
> 2. Anything requesting execution must be trusted.
One correction on the table: SELinux and AppArmor shouldn't be grouped under "rename-resistant: No". AppArmor is path-based. SELinux labels are on the inode, a rename doesn't change the security context. The copy attack doesn't apply either: a process in sandbox_t creating a file in /tmp gets tmp_t via type transition, and the policy does not grant sandbox_t execute permission on tmp_t.
[1] https://github.com/linux-application-whitelisting/fapolicyd