Message-ID:
 <GV2PPF74270EBEE3CE93E97610E2A869654E43FA@GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM>
Date: Mon, 25 Aug 2025 00:28:55 +0200
From: Bernd Edlinger <bernd.edlinger@...mail.de>
To: Jann Horn <jannh@...gle.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Oleg Nesterov <oleg@...hat.com>, "Eric W. Biederman"
 <ebiederm@...ssion.com>, Waiman Long <longman@...hat.com>,
 Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Alexey Gladkov <gladkov.alexey@...il.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

Hi Jann,

On 4/28/20 23:06, Jann Horn wrote:
> On Tue, Apr 28, 2020 at 10:36 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> On Tue, Apr 28, 2020 at 12:08 PM Oleg Nesterov <oleg@...hat.com> wrote:
>>>
>>> Oops. I can update that old patch but somehow I thought there is a better
>>> plan which I don't yet understand...
>>
>> I don't think any plan survived reality.
>>
>> Unless we want to do something *really* hacky.. The attached patch is
>> not meant to be serious.
>>
>>> And, IIRC, Jan had some ideas how to rework the new creds calculation in
>>> execve paths to avoid the cred_guard_mutex deadlock?
>>
>> I'm not sure how you'd do that.
>>
>> Execve() fundamentally needs to serialize with PTRACE_ATTACH somehow,
>> since the whole point is that "tsk->ptrace" changes how the
>> credentials are interpreted.
>>
>> So PTRACE_ATTACH doesn't really _change_ the credentials, but it very
>> much changes what execve() will do with them.
>>
>> But I guess we could do a "if somebody attached to us while we did the
>> execve(), just repeat the whole thing"
>>
>> Jann, what was your clever idea? Maybe it got lost in the long thread..
> 
> My clever/horrible/overly-complex idea was basically:
> 
> 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". (Other users that expect to
> use cred_guard_mutex to synchronize with execve would also have to be
> changed appropriately; e.g. seccomp tsync would have to bail out if
> the task turns out to be in execve after the mutex has been acquired.)
> 
> So I think we can conceptually fix the deadlock, but it requires a bit
> of refactoring. (I have an old branch somewhere in which I tried to
> implement this, and where I did a bunch of refactoring around
> ptrace_may_access() so that e.g. the LSM hooks for ptrace can be
> invoked twice when the target task is in execve, and so that they take
> the target's cred* as an argument.)

Hmm, funny while I totally missed your message at the time, thia sounds
exactly like what my latest patch does.

You may have a look, I would be curious what you think about it:

https://lore.kernel.org/lkml/GV2PPF74270EBEE9EF78827D73D3D7212F7E432A@GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM/


Thanks
Bernd.

Powered by blists - more mailing lists