Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAGXu5jJoqnX54JnHZDVxO4NRCsT6sLH4+-TPk8GqCSVp0mFNLw@mail.gmail.com>
References: <CAN1fySViLgrLAHHfTHMef-Bkh73kUHKP-ava6TbgALeSE4LfFw@mail.gmail.com>
 <CAFLxGvwpuxKF4UWdsULwQWo7kgVLMNHC=77dN+w-A0a6avrAXA@mail.gmail.com>
 <CAN1fySXjLUYFw2JGQQ5xxqjX+6kygzqgUc6Oj-sbtq=ZjgfLTA@mail.gmail.com> <CAGXu5jJoqnX54JnHZDVxO4NRCsT6sLH4+-TPk8GqCSVp0mFNLw@mail.gmail.com>
From:   Samuel Dionne-Riel <samuel@dionne-riel.com>
Date:   Wed, 13 Feb 2019 20:27:43 -0500
Message-ID: <CAN1fySW2mTaHmj7_uon_xZBVgPeEuYCD8e+JGOSKNwokmgZ7yg@mail.gmail.com>
Subject: Re: Userspace regression in LTS and stable kernels
To:     Kees Cook <keescook@chromium.org>
Cc:     Richard Weinberger <richard.weinberger@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Graham Christensen <graham@grahamc.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Michal Hocko <mhocko@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 13/02/2019, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Feb 13, 2019 at 4:41 PM Samuel Dionne-Riel
> <samuel@dionne-riel.com> wrote:
>> Before, the interpreter was still used (assuming it wasn't cut by the
>> length), and the interpreter was free to re-read the shebang if
>> desired.
>
> So, to address the "wrong binary" problem, how about we ENOEXEC only
> if no newline or spaces are found in the string?
>

If I understand right, you're asking whether it should return NOEXEC
if, of the first 128 bytes of the shebang, there are no spaces, but a
too long shebang? I wouldn't know for sure. The behaviour would
change. Instead failing due to trying to execute a shortened path, it
would fall back to the shell interpreter interpreting the file, which,
due to the inclusion of a specific shebang, might be a wrong
assumption still. Here I believe it's still in the "undefined
behaviour" territory, but one where it fails early for the userspace.

I don't have a strong opinion, but having a special case depending on
whitespace or not (well, possibility of the interpreter being
truncated or not) feels off. As an end-user, I would rather it
truncates, and show the truncated interpreter it tried to use
(behaviour before regression), rather than fail in a way where the
libc will continue executing using another unexpected interpreter.

Thinking in the principle of least astonishment, I would be less
surprised to see a truncated path on exec() than seeing exec() use an
unexpected interpreter.

--=20
=E2=80=94 Samuel Dionne-Riel