On Tue, Apr 28, 2020 at 11:37 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 28, 2020 at 2:06 PM Jann Horn <ja...@google.com> wrote: > > In execve: > > > > - After the point of no return, but before we start waiting for the > > other threads to go away, finish calculating our post-execve creds > > and stash them somewhere in the task_struct or so. > > - Drop the cred_guard_mutex. > > - Wait for the other threads to die. > > - Take the cred_guard_mutex again. > > - Clear out the pointer in the task_struct. > > - Finish execve and install the new creds. > > - Drop the cred_guard_mutex again. > > > > Then in ptrace_may_access, after taking the cred_guard_mutex, we'd > > know that the target task is either outside execve or in the middle of > > execve, with old and new credentials known; and then we could say "you > > only get to access that task if you're capable relative to *both* its > > old and new credentials, since the task currently has both state from > > the old executable and from the new one". > > That doesn't solve the problem with "check_unsafe_exec()" - you might > miss setting LSM_UNSAFE_PTRACE.
You don't need LSM_UNSAFE_PTRACE if the tracer has already passed a ptrace_may_access() check against the post-execve creds of the target - that's no different from having done PTRACE_ATTACH after execve is over.