Quotes of the week

In DTrace we had this problem too. Because I was ptracing the process in question anyway, I implemented a horrible solution involving a new ptrace operation that handed back an fd to the complete original mapped file for analysis -- but there are not one, but two, better ways these days, if you turn the appropriate kernel option on. The best approach is clearly to have the kernel component pass you a PID and an address and use /proc/$pid/map_files, which you can always follow, even if the executable is in another namespace or is deleted, as long as you have permission to ptrace the executable (and if you don't, why are you trying to get at its mappings?). Alternatively, you can have your kernel component pass you a handle and use open_by_handle(), but that unfortunately constrains you to scanning programs running on XFS filesystems, which is probably inadequate.

Your only worry in the pid-and-address case is another thing Casey noted, races. The only ways I can think of to avoid racing with the program terminating and the PID being reused are horrific: do not restart the paused victim until the scanner reports back (what *if* it dies?), or force this process to remain around, like a zombie, if it dies with an outstanding request (more special process states, oh joy).

No, this whole idea is a disaster area. I'm not happy with the races DTrace has in this area (mostly around getting ustack()s of processes that die before userspace learns about them: right now you're going to get a bunch of probably useless addresses back in that case), but frankly a tracer has different constraints on it than an LSM. You can afford to lose stack traces now and then from a tracer. You can't afford to lose permission decisions from an LSM, but having a userspace component like this almost guarantees it -- and both alternatives, fail-open and fail-closed, are disastrous.