On Mon, Jan 22, 2024 at 02:24:37PM +0100, Bernd Edlinger wrote:
The main concern was when a set-suid program is executed by execve. Then it makes a difference if the current thread is traced before the execve or not. That means if the current thread is already traced, the decision, which credentials will be used is different than otherwise.
So currently there are two possbilities, either the trace happens before the execve, and the suid-bit will be ignored, or the trace happens after the execve, but it is checked that the now potentially more privileged credentials allow the tracer to proceed.
With this patch we will have a third prossibility, that is in order to avoid the possible dead-lock we allow the suid-bit to take effect, but only if the tracer's privileges allow both to attach the current credentials and the new credentials. But I would only do that as a last resort, to avoid the possible dead-lock, and not unless a dead-lock is really expected to happen.
Instead of doing this special cred check (which I am worried could become fragile -- I'd prefer all privilege checks happen in the same place and in the same way...), could we just fail the ptrace_attach of the execve?