Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2202767ybe; Sat, 7 Sep 2019 10:48:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwd6qzY5HO81QJwrhHk4KojK6xT7kMD6lck+pMMfHsyQ3HAIcFqdU0255za+hCrPTf3fu4o X-Received: by 2002:aa7:80ca:: with SMTP id a10mr326406pfn.96.1567878510701; Sat, 07 Sep 2019 10:48:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567878510; cv=none; d=google.com; s=arc-20160816; b=Eo5/lL7TnUD242uiNnIcHrZ4C/WzAfNkZlViJ84LWt1dFtvsC2FDwe5Ltvi/7GRNGW B7o/jUs0bCx5fGQWORtgQcSpvlC85NRD6QpWO2YZ5ogpWjpAVdOc2Fs8QdCrVfnEsLja UeU2TGfXDxgZ7kYPrlsrboKqugQMPExdkoGQ20yg0zj3hv03UZ2xICocIn2fSe5Mcmik WMdIdxbfrcfznbbvnnurVdcZLHtkEXs5LMnbyoebvBJUWEuPn72oSTXLP+jP8cYttLWi tMH7OOiWbtsO/MPr6xDEm0EXBg9U7kU6V2u3mV8/t/lnXN5J7m4v8P3C4G62lATnAu/7 S/Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=fA56nmfsZsnUsEfBRX6jWIQZ7RippmvM12LMrLjjbeM=; b=aifzPjPkw+dvfD4HdQ8JDLed9BWNPL4zEgytcgO56UdDk/hGi46i2rSJUmIIrP6UMQ wSBvSHq52wfaCPDRO1vo2yi9J8TlCI8jfyQ+pmz89IweIdRCeA2loKwskucAr1ZCAHxf St+ZLahDmm4UNMBkZniWnXMsu+GQ4O7THG2WF9kcOK+g0ay5W7cQDRnrkv7lruhBo1X7 Y4mRPR28+4SIYEL1jhx/BOUwhzCx81oWBCR7SfJqtQfdxzxfD8wa+MJCkFv/Me4sOWkX M8o1at2V17cLKhdKGCM4qLQfSWHao17D08z4edF6QFgWkUNRAbiqxKEQ0n0iGE0kFklJ og5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=E0bpCavZ; 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 m19si7894479pls.146.2019.09.07.10.48.15; Sat, 07 Sep 2019 10:48:30 -0700 (PDT) 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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=E0bpCavZ; 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 S2394189AbfIFUGE (ORCPT + 99 others); Fri, 6 Sep 2019 16:06:04 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:42882 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfIFUGE (ORCPT ); Fri, 6 Sep 2019 16:06:04 -0400 Received: by mail-pg1-f196.google.com with SMTP id p3so4103244pgb.9 for ; Fri, 06 Sep 2019 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fA56nmfsZsnUsEfBRX6jWIQZ7RippmvM12LMrLjjbeM=; b=E0bpCavZc9w7bg3ldootyHw632dMvkQjPiTDyyD9E4nvHHA/R4hfUqQe7JLvWLoVI1 ZzdmjRUZn1I/3UFIId9wru0Cc8NhUgmlZoWyxM/ETmiRdFCnjHslhNciqqND5mXeB2ql n2FNStFMy81oIyvmFuPfhqeBNzaKyrGa2txp4Fp60Why8ReO3XzcGfC7Iqb3t9OIfHFS hkuXHMI1y873af/967NcJKza/15DICLILQudnnZaxDY3hkSvNaemTLwpsFes4bFnAeGl yrMqylb/J5NUitzWqPaJmoR/oVtP6BgW0XPr9/NxQgR7ofco0GzSUDnNYnFHisgIXVU8 A/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fA56nmfsZsnUsEfBRX6jWIQZ7RippmvM12LMrLjjbeM=; b=Q//jUDzySoLjLmUIWQMCYXf1apwcpRK5GymZ+3sZn52fJHrAjpk5pLF9bdq0e0VRLN N/9XzFHw4syms4/2vR3d19KCXJleakfZrt6ANuhpfodV3cE0PKp6Dcq3ez36I5mkJzdA sVuehpVGkgV4fzbOqj4110KQhqjPu26nClWEbmy6uxN/1aZv9aqYepMEzAekUT7OQx0O 9hstZBIqmcHjqeBxpgbAOz8sxhZIr3Ifkkx6WZvecEdI7IwNPzutV6V5jZViFgZjY6WC ft9o8kOEnry3IkLYt2Itu4Qs2t2gC+WgaxFXMK8wTptk29tPHFAV+7hz8jWU6hJCu4eB GKdA== X-Gm-Message-State: APjAAAXBYjvmFw/R9nka5kvtkr9qpZQwlqflyTd3YgmxgksA81LUhSp7 wlt67oOvwfVg2YDhTzvP0qBGbg== X-Received: by 2002:a62:3083:: with SMTP id w125mr12963792pfw.102.1567800362967; Fri, 06 Sep 2019 13:06:02 -0700 (PDT) Received: from ?IPv6:2600:100f:b121:da37:bc66:d4de:83c7:e0cd? ([2600:100f:b121:da37:bc66:d4de:83c7:e0cd]) by smtp.gmail.com with ESMTPSA id k8sm5007663pgm.14.2019.09.06.13.06.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Sep 2019 13:06:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() From: Andy Lutomirski X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Fri, 6 Sep 2019 13:06:00 -0700 Cc: Aleksa Sarai , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Florian Weimer , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-kernel@vger.kernel.org, Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , Daniel Borkmann , Eric Chiang , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , Mimi Zohar , =?utf-8?Q?Philippe_Tr=C3=A9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Song Liu , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , Yves-Alexis Perez , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190906152455.22757-1-mic@digikod.net> <20190906152455.22757-2-mic@digikod.net> <87ef0te7v3.fsf@oldenburg2.str.redhat.com> <75442f3b-a3d8-12db-579a-2c5983426b4d@ssi.gouv.fr> <20190906171335.d7mc3no5tdrcn6r5@yavin.dot.cyphar.com> To: Jeff Layton Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote: >=20 >> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote: >>> On 2019-09-06, Jeff Layton wrote: >>>> On Fri, 2019-09-06 at 18:06 +0200, Micka=C3=ABl Sala=C3=BCn wrote: >>>>> On 06/09/2019 17:56, Florian Weimer wrote: >>>>> Let's assume I want to add support for this to the glibc dynamic loade= r, >>>>> while still being able to run on older kernels. >>>>>=20 >>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fai= ls >>>>> with EINVAL, try again without O_MAYEXEC? >>>>=20 >>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for >>>> older kernel to use O_MAYEXEC. >>>>=20 >>>=20 >>> Well...maybe. What about existing programs that are sending down bogus >>> open flags? Once you turn this on, they may break...or provide a way to >>> circumvent the protections this gives. >>=20 >> It should be noted that this has been a valid concern for every new O_* >> flag introduced (and yet we still introduced new flags, despite the >> concern) -- though to be fair, O_TMPFILE actually does have a >> work-around with the O_DIRECTORY mask setup. >>=20 >> The openat2() set adds O_EMPTYPATH -- though in fairness it's also >> backwards compatible because empty path strings have always given ENOENT >> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings. >>=20 >>> Maybe this should be a new flag that is only usable in the new openat2()= >>> syscall that's still under discussion? That syscall will enforce that >>> all flags are recognized. You presumably wouldn't need the sysctl if you= >>> went that route too. >>=20 >> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to >> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for >> it, since I'd heard about this work through the grape-vine). >>=20 >=20 > I rather like the idea of having openat2 fds be non-executable by > default, and having userland request it specifically via O_MAYEXEC (or > some similar openat2 flag) if it's needed. Then you could add an > UPGRADE_EXEC flag instead? >=20 > That seems like something reasonable to do with a brand new API, and > might be very helpful for preventing certain classes of attacks. >=20 >=20 There are at least four concepts of executability here: - Just check the file mode and any other relevant permissions. Return a norm= al fd. Makes sense for script interpreters, perhaps. - Make the fd fexecve-able. - Make the resulting fd mappable PROT_EXEC. - Make the resulting fd upgradable. I=E2=80=99m not at all convinced that the kernel needs to distinguish all th= ese, but at least upgradability should be its own thing IMO.=