Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5973114ybe; Tue, 10 Sep 2019 11:33:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqziuDAm28WZMgtMpxdsfraKNJBcW+ZP6znm6VRXAeSflKtT1ciBAxNzW2VFaD3DpK+VLyKr X-Received: by 2002:aa7:d98b:: with SMTP id u11mr31067513eds.110.1568140415181; Tue, 10 Sep 2019 11:33:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568140415; cv=none; d=google.com; s=arc-20160816; b=pfmGUyt/XodPa8G8Va+paHPw1nl9BW4KurpCTFMLWh6vAkQQI5B8J6E6ZVR7Y938vA Esq0DHxlr270K2F0XHghwVVapv+MRFheaIyO9+Rz9o2cDmD4ygLhv6JOFX0Av1AGZZ5l YiRttbY/Sj5Z/8n52bDsyWK4+8LFkRXGFzoEIKpPDqpbeNCTk3tV8mU1Z4IqkwlPuWfG YiRDvOK+JejtyuWZR5dEu8C7BCUACeVug4uuFA/DjOQyvhnDAOhOs1ozZhHmY3ieboic mQpcqK99LrSsbgyskHFFem7P39+JGf60F/ui2nQr+VL1eIx49Yz4stKhBN4u0WZiKLmL Z1sw== 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=TcpVRxPvSCJBDeMrd2YTMRp8Rl8PbIZu3n0i+gvGrs0=; b=jx79Taj+AfyqKB66KGcQSeM+ryVJS9yI18/HQXaS0SLFeOthIL0F2b8FqR4rc8nRd1 w+JfkZOGTqEFjjkFFLpzPxmydCcajD2N3shDRdAYlLQzYdG7i8ReA82xP49yKu049/T4 yoPUPpwfGv6Q3/pSmEZA4Wn/Pkjtmb//gI4OSb31kDskx755cR3C9HiYzcDdQAepEaHO yhBCenrtvTUZr8KgKeeZE5qwO8h1MP3UO19EB7BzhuQ7cW2RT3oJasVOsXghe7sQ0Rdg qGmt1KpsF8VS/1qUmFjuw2I2wrH7Dz34A7zH9fgCPyApTeWBX1uqMT423wQ1YpY1BFnG 5AKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=pyj6eZzO; 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 g50si9466198edb.47.2019.09.10.11.33.03; Tue, 10 Sep 2019 11:33:35 -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=pyj6eZzO; 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 S2388962AbfIIPti (ORCPT + 99 others); Mon, 9 Sep 2019 11:49:38 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:45938 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729792AbfIIPth (ORCPT ); Mon, 9 Sep 2019 11:49:37 -0400 Received: by mail-pg1-f195.google.com with SMTP id 4so8038901pgm.12 for ; Mon, 09 Sep 2019 08:49:37 -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=TcpVRxPvSCJBDeMrd2YTMRp8Rl8PbIZu3n0i+gvGrs0=; b=pyj6eZzOMQKgCMAnu5hk7YcUQt/XRn56h4r0IMODI0hyM9G9CYPIi2I36Xh8bWAswe HQ69epbn6Uf9ynM4L80OZwNVT7+NKwhsVjbbBOdgZ3Sno+ciFri39Kli05LwVBVwXMO4 WPQPuPR8PH4DNpoQm9XN6dklzcVFGdNXqpu0a1NtCG6oZM5UZY52+iEmc5U+69aWMSDD TtFXWImbrKRvBbStNAPXOn384l3qdIeXuF90JziftEWHMPomjRynDL5FJz+grsE1Ojux M7UMm0N5iJ2ogZ3iHxqnGcVPcNf5bXqHXW4l+fPAohZq2BPjtEtmzX37Gd63Ig1oZN85 4jrA== 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=TcpVRxPvSCJBDeMrd2YTMRp8Rl8PbIZu3n0i+gvGrs0=; b=XO7Y+h5WWINGDDEUDmPfHnI48kz9LSia3/d/LFUUlEqQpOf4YaF3zK+ShwbekiL6au RUxIqbaH1HbxtOmQEzxabISaAIrHWIx7TY+/PS2Fxg6HTh8VmyJ3EtzThtnfYb7i9Die Dzst3a5L6sjLsbprM0SpmyoHnKTvGO8IPzK6rXQGxlVYLWF8rhlpvrhOHUIS374gCd02 YeWfO4JfPnpWjAuPg6WFshW/RImCYIEU8AvZpFxg8Z4luXYcJnjryDMFUIk8UaEiRU4o Hy/F/RVDG4Vu1DXgL4eodZHALJL2r3NngO/WZgVfM48gx92m8jvdnO41SwH1titG0bJ2 DEgg== X-Gm-Message-State: APjAAAXw5HwMA2qlXQocNEwpfGbWJXHkILpht3YS7efClYqrKE/XP9h9 ymdTnQ5oMZoWqDXEfZGxDq3B2g== X-Received: by 2002:a63:df06:: with SMTP id u6mr21484642pgg.96.1568044176881; Mon, 09 Sep 2019 08:49:36 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:75ae:6074:df59:7e95? ([2601:646:c200:1ef2:75ae:6074:df59:7e95]) by smtp.gmail.com with ESMTPSA id d15sm15407841pfo.118.2019.09.09.08.49.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Sep 2019 08:49:33 -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: <9e43ca3f-04c0-adba-1ab4-bbc8ed487934@ssi.gouv.fr> Date: Mon, 9 Sep 2019 08:49:32 -0700 Cc: Jeff Layton , Florian Weimer , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-kernel@vger.kernel.org, Aleksa Sarai , 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> <1fbf54f6-7597-3633-a76c-11c4b2481add@ssi.gouv.fr> <5a59b309f9d0603d8481a483e16b5d12ecb77540.camel@kernel.org> <9e43ca3f-04c0-adba-1ab4-bbc8ed487934@ssi.gouv.fr> To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sep 9, 2019, at 2:18 AM, Micka=C3=ABl Sala=C3=BCn wrote: >=20 >=20 >> On 06/09/2019 20:41, Andy Lutomirski wrote: >>=20 >>=20 >>>> On Sep 6, 2019, at 11:38 AM, Jeff Layton wrote: >>>>=20 >>>>> On Fri, 2019-09-06 at 19:14 +0200, Micka=C3=ABl Sala=C3=BCn wrote: >>>>>> On 06/09/2019 18:48, 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 loa= der, >>>>>>> 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 f= ails >>>>>>> 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 t= o >>>>> circumvent the protections this gives. >>>>=20 >>>> Well, I don't think we should nor could care about bogus programs that >>>> do not conform to the Linux ABI. >>>>=20 >>>=20 >>> But they do conform. The ABI is just undefined here. Unknown flags are >>> ignored so we never really know if $random_program may be setting them. >>>=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 y= ou >>>>> went that route too. >>>>=20 >>>> Here is a thread about a new syscall: >>>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/ >>>>=20 >>>> I don't think it fit well with auditing nor integrity. Moreover using >>>> the current open(2) behavior of ignoring unknown flags fit well with th= e >>>> usage of O_MAYEXEC (because it is only a hint to the kernel about the >>>> use of the *opened* file). >>>>=20 >>>=20 >>> The fact that open and openat didn't vet unknown flags is really a bug. >>>=20 >>> Too late to fix it now, of course, and as Aleksa points out, we've >>> worked around that in the past. Now though, we have a new openat2 >>> syscall on the horizon. There's little need to continue these sorts of >>> hacks. >>>=20 >>> New open flags really have no place in the old syscalls, IMO. >>>=20 >>>>> Anyone that wants to use this will have to recompile anyway. If the >>>>> kernel doesn't support openat2 or if the flag is rejected then you kno= w >>>>> that you have no O_MAYEXEC support and can decide what to do. >>>>=20 >>>> If we want to enforce a security policy, we need to either be the syste= m >>>> administrator or the distro developer. If a distro ship interpreters >>>> using this flag, we don't need to recompile anything, but we need to be= >>>> able to control the enforcement according to the mount point >>>> configuration (or an advanced MAC, or an IMA config). I don't see why a= n >>>> userspace process should check if this flag is supported or not, it >>>> should simply use it, and the sysadmin will enable an enforcement if it= >>>> makes sense for the whole system. >>>>=20 >>>=20 >>> A userland program may need to do other risk mitigation if it sets >>> O_MAYEXEC and the kernel doesn't recognize it. >>>=20 >>> Personally, here's what I'd suggest: >>>=20 >>> - Base this on top of the openat2 set >>> - Change it that so that openat2() files are non-executable by default. A= nyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow. >>> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and= openat continue ignoring the new flag. >>>=20 >>> That works around a whole pile of potential ABI headaches. Note that >>> we'd need to make that decision before the openat2 patches are merged. >>>=20 >>> Even better would be to declare the new flag in some openat2-only flag >>> space, so there's no confusion about it being supported by legacy open >>> calls. >>>=20 >>> If glibc wants to implement an open -> openat2 wrapper in userland >>> later, it can set that flag in the wrapper implicitly to emulate the old= >>> behavior. >>>=20 >>> Given that you're going to have to recompile software to take advantage >>> of this anyway, what's the benefit to changing legacy syscalls? >>>=20 >>>>>>> Or do I risk disabling this security feature if I do that? >>>>>>=20 >>>>>> It is only a security feature if the kernel support it, otherwise it i= s >>>>>> a no-op. >>>>>>=20 >>>>>=20 >>>>> With a security feature, I think we really want userland to aware of >>>>> whether it works. >>>>=20 >>>> If userland would like to enforce something, it can already do it >>>> without any kernel modification. The goal of the O_MAYEXEC flag is to >>>> enable the kernel, hence sysadmins or system designers, to enforce a >>>> global security policy that makes sense. >>>>=20 >>>=20 >>> I don't see how this helps anything if you can't tell whether the kernel= >>> recognizes the damned thing. Also, our track record with global sysctl >>> switches like this is pretty poor. They're an administrative headache as= >>> well as a potential attack vector. >>=20 >> I tend to agree. The sysctl seems like it=E2=80=99s asking for trouble. I= can see an ld.so.conf option to turn this thing off making sense. >=20 > The sysctl is required to enable the adoption of this flag without > breaking existing systems. Current systems may have "noexec" on mount > points containing scripts. Without giving the ability to the sysadmin to > control that behavior, updating to a newer version of an interpreter > using O_MAYEXEC may break such systems. >=20 > How would you do this with ld.so.conf ? >=20 By telling user code not to use O_MAYEXEC? Alternatively, you could allow O_MAYEXEC even on a noexec mount and have a s= trong_noexec option that blocks it.=