People working on Oculus (and from my past experience and current discussions with the Googlers CCed here, people working on Android) have been frustrated with the difficulty of tracking down the precise caller that triggers an selinux denial, since it might be multiple layers deep in transitive dependencies of the process that actually gets blamed. Thiébaud implemented a tracepoint which can be used to interactively track down a denial, but it has some shortcomings: - it requires a tracer running as root (or some equivalently scary set of capabilities), so it's not really feasible to run it across our deployment of dogfood devices - trace output doesn't provide the full context of the process, so AFAIK, it's not possible to do things like unwind through JIT compiled functions, or print syscall arguments that are on the heap - it's asynchronous, so you can't go in with a debugger and inspect program state to figure out why the failing syscall was made in the first place In an ideal world, an selinux failure would have the same sort of diagnostic tooling as a SIGSEGV. To do this, I propose that we let processes opt-in to receiving a signal when an avc denial occurs. If a user wants to debug interactively, they can set it to SIGSTOP manually; on systems like Android where libc registers a signal handler that collects a bug report and forwards it through a crash reporting pipeline, the system can set it to that signal automatically. I'm guessing that the best interface for this is a file in procfs at somewhere along the lines of /proc/$PID/selinux/audit_signal, taking a signal number. It's probably useful to be able to correlate this with an audit serial number, so perhaps we should add an si_code value for this, with a field in siginfo_t? To keep this from inadvertently allowing signals to be sent on systems that would otherwise prevent them entirely, we can add a new access vectors in process2 to get/set the audit signal. I think the setting should be maintained across fork; I'm not sure whether it should be reset on exec. AT_SECURE transitions almost definitely should, but I'm not sure about the utility of inheriting it in the first place: if it's configured to a signal that's set by libc, and libc itself triggers an audit before it gets around to registering a signal handler, the process will mysteriously disappear. I have a patch against 4.9 that implements most of this [1], but I wanted to run this by the upstream mailing list to get some feedback before reimplementing it on linux-next. Thanks, Josh 1: https://gist.github.com/jmgao/9c17bcc93d65472d9dd2a17362ed4075
