[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875ze9ycwh.fsf@x220.int.ebiederm.org>
Date: Wed, 08 Apr 2020 14:51:10 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Bernd Edlinger <bernd.edlinger@...mail.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Kees Cook <keescook@...omium.org>,
Jann Horn <jannh@...gle.com>,
Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH 1/3] binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Mon, Apr 6, 2020 at 6:34 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> In 2016 Linus moved install_exec_creds immediately after
>> setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
>> potential information leak.
>>
>> Perform the same cleanup for the other binary formats
>
> Can we not move it _into_ setup_new_exec() now if you've changed all
> the binfmt handlers?
>
> The fewer cases of "this gets called by the low-level handler at
> different points" that we have, the better off we'd be, I think. One
> of the complexities of our execve() code is that some of it gets
> called directly, and some of it gets called by the binfmt handler, and
> it's often very hard to see the logic when it jumps out to the binfmt
> code and then back to the generic fs/exec.c code..
Yes. I already have merging of setup_new_exec and install_exec_creds in
my working tree. I just posted the simplest set of patches to get the
idea across.
We can almost merge those two with flush_old_exec as well except for the
code that sets the personality between flush_old_exec and and
setup_new_exec. I am wondering if maybe setting the personality should
be a callback.
Eric
Powered by blists - more mailing lists