[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ilu6utm3.fsf@email.froward.int.ebiederm.org>
Date: Wed, 26 Jan 2022 14:31:16 -0600
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Kees Cook <keescook@...omium.org>
Cc: Matthew Wilcox <willy@...radead.org>, Jann Horn <jannh@...gle.com>,
Ariadne Conill <ariadne@...eferenced.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Christian Brauner <brauner@...nel.org>,
Rich Felker <dalias@...c.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] fs/binfmt_elf: Add padding NULL when argc == 0
Kees Cook <keescook@...omium.org> writes:
> On Wed, Jan 26, 2022 at 08:08:14PM +0000, Matthew Wilcox wrote:
>> On Wed, Jan 26, 2022 at 11:58:39AM -0800, Kees Cook wrote:
>> > We can't mutate argc; it'll turn at least some userspace into an
>> > infinite loop:
>> > https://sources.debian.org/src/valgrind/1:3.18.1-1/none/tests/execve.c/?hl=22#L22
>>
>> How does that become an infinite loop? We obviously wouldn't mutate
>> argc in the caller, just the callee.
>
> Oh, sorry, I misread. It's using /bin/true, not argv[0] (another bit of
> code I found was using argv[0]). Yeah, {"", NULL} could work.
>
>> Also, there's a version of this where we only mutate argc if we're
>> executing a setuid program, which would remove the privilege
>> escalation part of things.
>
> True; though I'd like to keep the logic as non-specialized as possible.
> I don't like making stuff conditional on privilege boundaries if we can
> make it always happen.
Which I think means turning the argc == 0 case into { "", NULL }.
I think we can always do that, and it is already valid in userspace.
The only case I can imagine breaking would be an explicitly testing
for argc == 0 and behaving completely differently if that is passed
to the program.
Eric
Powered by blists - more mailing lists