Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1163821imj; Thu, 14 Feb 2019 02:14:06 -0800 (PST) X-Google-Smtp-Source: AHgI3IZy6u5wHwssGla6jZGOCmU1OgeM2y1DH5KTEiyhEa+s+jvA7AKFtW3AkDYAqShMYiwLWpKP X-Received: by 2002:a65:514c:: with SMTP id g12mr2954725pgq.169.1550139246284; Thu, 14 Feb 2019 02:14:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550139246; cv=none; d=google.com; s=arc-20160816; b=WeiGnsMAqc19rHEpZxthFHrvHxxid6OoTr3eqtbtn8z/qsYOylnH2sBbbS279DG8gf a5SApv4sNSoRmKrTsGJOGLDe9InNjBXJvES1dIexWohMqikrmfJPd9GpyqXv/HBtX93p RQmBPvA6UdAFnhxc9G9XxhLWytexa82vUkXmoH+FMF5s1q3iLGQ395GON62ggoDZiAcB b9xCycIdERHBpIeRtggUKooDYU1oNpnuXg1gW9zV+8XzonP07Q6N+Q695jr6AQlWFaxB u4eu2g+lD1GVqIg/QDHsblKs168Vre+sSLZu/3lgnans8Lxqmvmqy80vX/6Xs+ivhMDH B4YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature; bh=PKnCJsZO+ue1MoqXGh784Vd0v0SSwQVS95AFfPY1odQ=; b=hc7iIYqqcDVcjukZvQj4nSxOszQzwL3f7gbBsBqiWNgKtOxYK+g8y63Oc4QeyOxy1y 4VEjYu7gR3h29Kng++wCGo+liqWtbUTp/VuIkUsPh4JzetNQYB4rP1+1aMXMbLCa/b0n 7TIx2LY9cjSvKydlo2gEKc0wDvduDVnIp4PeyRDIxQtqBM2pT+WDGEri5hP6F3wJFQKM h6C3qQW+p107Fnv1kIYGDk1JHUUKWWYmTy5xjRJpr0kOMB+2I2ZcdCMPOZgxHNX2MUV4 WKzwP42KjobCH3yaKhdaZNYdZWQWY5nFWcAtWEVTkmwBtkWtOKRqikbjLnQqQLiKgDaj YUGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dionne-riel-com.20150623.gappssmtp.com header.s=20150623 header.b=RBjqNvJe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d188si1960244pgc.97.2019.02.14.02.13.50; Thu, 14 Feb 2019 02:14:06 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@dionne-riel-com.20150623.gappssmtp.com header.s=20150623 header.b=RBjqNvJe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730072AbfBNB1r (ORCPT + 99 others); Wed, 13 Feb 2019 20:27:47 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:46506 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726811AbfBNB1r (ORCPT ); Wed, 13 Feb 2019 20:27:47 -0500 Received: by mail-lj1-f194.google.com with SMTP id v16so3717990ljg.13 for ; Wed, 13 Feb 2019 17:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dionne-riel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PKnCJsZO+ue1MoqXGh784Vd0v0SSwQVS95AFfPY1odQ=; b=RBjqNvJeuSDefI2CBdtS3SCJlV0P1+3F7xT18s37ThBTahD50MUHqwoh3FQaqPxpFh SFmudKQPSoF/un6zld39U37cbiPeHqXvq5gqzqDPIEEDaOn3ZJz43i66mDuuQk6gHmTn tb06Np38jdEYrbQec41x08HLypIKStzAYVltLVsIG/JIWPO4yTmdW2bcp77GKQdkUVCO npQFGIuGRL+EiVPD2oK0Bjj8qkTzmhRcRclev+4a2UjSh1fycNCp/FkkgHQkfwUQJGJo R1W4xgwphN5C4weh789hWXiPGVk+RDN+WlVjazWhZZpz0g4uTKGST86MJ4brapwxnGBF Pkzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PKnCJsZO+ue1MoqXGh784Vd0v0SSwQVS95AFfPY1odQ=; b=b9TWfbY/qoE6lQ00Ad5qog2ij1ii2BQ3pkJP5FKEYLLwfVNkpOcA/MLrZdWNtJxehl 236dic1nVJ7EcgzINw4K1TPaKj0nHHzgbqpNUALQqlyzFOF9coZeUutteFDiKErtmlnH MSuq8Kl4OUk4fpVW2ZDNLVG3VLD78YMCnyR9LXmmtw24EA70xfQ/Iwxc2p3P/Zbf9gl0 CK3NQVgcPQcQ4z0b9dN66d0BRSHEpxzCcL34kTo2tkcXIq57e+QsuXj98NeZw74a1ww9 J64e31RGjLBubDJI+BfV6INWWXGyxOeSB9ynKTQYmqC6nJrhgHSO/+jysxPIGFs1Eph6 T3/g== X-Gm-Message-State: AHQUAubzQ0U64Nx3iJqdehN3uUz9tw018wQU2URgH5seYzR8BYn7boBD 646+Gk//HP3O262Pe9ZniBOszT+87piEf+pjAxpLj0rztlo= X-Received: by 2002:a2e:9105:: with SMTP id m5mr655838ljg.100.1550107664778; Wed, 13 Feb 2019 17:27:44 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab3:5612:0:0:0:0:0 with HTTP; Wed, 13 Feb 2019 17:27:43 -0800 (PST) In-Reply-To: References: From: Samuel Dionne-Riel Date: Wed, 13 Feb 2019 20:27:43 -0500 Message-ID: Subject: Re: Userspace regression in LTS and stable kernels To: Kees Cook Cc: Richard Weinberger , LKML , Linus Torvalds , Graham Christensen , Oleg Nesterov , Michal Hocko , Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/02/2019, Kees Cook wrote: > On Wed, Feb 13, 2019 at 4:41 PM Samuel Dionne-Riel > 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