A compromised user account has the ability to set the LD_PRELOAD (or similar) environment variable. This basically allows an attacker to redefine syscalls and spy on whatever they want. It is the most common method of user space rootkits. A few examples I found within a few seconds of searching:
It is trivial to create a rootkit via LD_PRELOAD. This is somewhat similar to the ptrace syscall which we already restrict in security-misc via the YAMA LSM.
LD_PRELOAD and co. are ignored when executing setuid binaries to prevent obvious privilege escalations. MAC systems can also enforce some restrictions (AppArmor’s isn’t great though, see below).
https://manpages.debian.org/buster/manpages/ld.so.8.en.html#Secure-execution_mode
However, when considering sandbox-app-launcher, an attacker would only be able to set LD_PRELOAD within the sandbox (not outside) unless they also have a sandbox escape. This would still be useful for defense-in-depth and for programs that are not sandboxed though.
I likely can.
No, unless you revoke the setuid bit from bwrap which we could do but might be too restrictive and annoying.
No, AppArmor’s environment scrubbing only applies to profile transitions. E.g. a program executing under the init-systemd profile would have some dangerous environment variables erased when transitioning to the torbrowser profile. This would not cover programs executing within the same profile though. E.g. if program X and Y are both under the init-systemd profile and X sets LD_PRELOAD, it will also leak over to program Y. AppArmor’s environment scrubbing is only feasible when everything has it’s own profile.