On Mon, Mar 2, 2020 at 6:43 PM [off-list ref] wrote:
On March 2, 2020 6:37:27 PM GMT+01:00, Jann Horn [off-list ref] wrote:
quoted
On Mon, Mar 2, 2020 at 6:01 PM Bernd Edlinger
[off-list ref] wrote:
quoted
On 3/2/20 5:43 PM, Jann Horn wrote:
quoted
On Mon, Mar 2, 2020 at 5:19 PM Eric W. Biederman
[off-list ref] wrote:
[...]
quoted
quoted
quoted
quoted
I am 99% convinced that the fix is to move cred_guard_mutex down.
"move cred_guard_mutex down" as in "take it once we've already set
up
quoted
quoted
the new process, past the point of no return"?
quoted
Then right after we take cred_guard_mutex do:
if (ptraced) {
use_original_creds();
}
And call it a day.
The details suck but I am 99% certain that would solve everyones
problems, and not be too bad to audit either.
Ah, hmm, that sounds like it'll work fine at least when no LSMs are
involved.
quoted
quoted
SELinux normally doesn't do the execution-degrading thing, it just
blocks the execution completely - see their
selinux_bprm_set_creds()
quoted
quoted
hook. So I think they'd still need to set some state on the task
that
quoted
quoted
says "we're currently in the middle of an execution where the
target
quoted
quoted
task will run in context X", and then check against that in the
ptrace_may_access hook. Or I suppose they could just kill the task
near the end of execve, although that'd be kinda ugly.
We have current->in_execve for that, right?
I think when the cred_guard_mutex is taken only in the critical
section,
quoted
then PTRACE_ATTACH could take the guard_mutex, and look at
current->in_execve,
quoted
and just return -EAGAIN in that case, right, everybody happy :)
It's probably going to mean that things like strace will just randomly
fail to attach to processes if they happen to be in the middle of
execve... but I guess that works?
That sounds like an acceptable outcome.
We can at least risk it and if we regress
revert or come up with the more complex
solution suggested in another mail here?
Yeah, sounds reasonable, I guess.