On Mon, Mar 2, 2020 at 6:43 PM christian@brauner.io wrote:
On March 2, 2020 6:37:27 PM GMT+01:00, Jann Horn jannh@google.com wrote:
On Mon, Mar 2, 2020 at 6:01 PM Bernd Edlinger bernd.edlinger@hotmail.de wrote:
On 3/2/20 5:43 PM, Jann Horn wrote:
On Mon, Mar 2, 2020 at 5:19 PM Eric W. Biederman
ebiederm@xmission.com wrote:
[...]
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
the new process, past the point of no return"?
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.
SELinux normally doesn't do the execution-degrading thing, it just blocks the execution completely - see their
selinux_bprm_set_creds()
hook. So I think they'd still need to set some state on the task
that
says "we're currently in the middle of an execution where the
target
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,
then PTRACE_ATTACH could take the guard_mutex, and look at
current->in_execve,
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.