[compiler-rt] [sanitizer] Disable writes to log files for binaries in a secure context. (PR #92593)

[Mitch Phillips via llvm-commits]

hctim wrote:

I think there's two concerns:
 1. We don't want to break existing users, and
 2. Putting something like this in the code may give the impression that we are really trying very hard to solve this problem, and that it's okay to build setuid binaries with sanitizers and expect it to be a security mitigation.

But it's cheap and solves a known problem.

I'd be in favour of landing a slightly different version of this patch. When we see setuid or some of the other things in AT_SECURE, let's just not do a some cheap stuff (but not die). So:

 1. Disable the symbolizer (not currently in this patch but should happen),
 2. Simply don't allow a log path to be set, don't die, but just return early.
 3. Add a log around both areas saying "you're running a setuid binary under sanitizers, this is not a security mitigation, and you may be actually weakening your security by doing this because the sanitizers were not written with these kind of constraints in mind".

> This approach should effectively mitigate the attack surface exposed through command-line arguments. However, I have yet to formulate an equivalent solution for addressing potential SELinux use cases.

Can you elaborate on what you're concerned about here? A user with selinux permissions to run setuid binaries, and they use sanitizers as a trojan horse to execute syscalls they don't have access to? IMHO this is a "write bad selinux, deal with consequences" problem. I highly doubt any setuid software is designed to not be used as a syscall-trojan-horse.

https://github.com/llvm/llvm-project/pull/92593