From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3D6FC43331 for ; Fri, 6 Sep 2019 18:28:04 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 4B48A2082C for ; Fri, 6 Sep 2019 18:28:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B48A2082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-16850-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 20345 invoked by uid 550); 6 Sep 2019 18:27:56 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 20319 invoked from network); 6 Sep 2019 18:27:55 -0000 From: Florian Weimer To: Tycho Andersen Cc: Christian Brauner , Aleksa Sarai , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , =?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 , Philippe =?utf-8?Q?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 Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() 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> <20190906170739.kk3opr2phidb7ilb@yavin.dot.cyphar.com> <20190906172050.v44f43psd6qc6awi@wittgenstein> <20190906174041.GH7627@cisco> Date: Fri, 06 Sep 2019 20:27:31 +0200 In-Reply-To: <20190906174041.GH7627@cisco> (Tycho Andersen's message of "Fri, 6 Sep 2019 11:40:41 -0600") Message-ID: <87v9u5cmb0.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 06 Sep 2019 18:27:43 +0000 (UTC) * Tycho Andersen: > On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote: >> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote: >> > On 2019-09-06, Micka=C3=ABl Sala=C3=BCn w= rote: >> > >=20 >> > > On 06/09/2019 17:56, Florian Weimer wrote: >> > > > Let's assume I want to add support for this to the glibc dynamic l= oader, >> > > > while still being able to run on older kernels. >> > > > >> > > > Is it safe to try the open call first, with O_MAYEXEC, and if that= fails >> > > > 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 >> > Depends on your definition of "safe" -- a security feature that you wi= ll >> > silently not enable on older kernels doesn't sound super safe to me. >> > Unfortunately this is a limitation of open(2) that we cannot change -- >> > which is why the openat2(2) proposal I've been posting gives -EINVAL f= or >> > unknown O_* flags. >> >=20 >> > There is a way to probe for support (though unpleasant), by creating a >> > test O_MAYEXEC fd and then checking if the flag is present in >> > /proc/self/fdinfo/$n. >>=20 >> Which Florian said they can't do for various reasons. >>=20 >> It is a major painpoint if there's no easy way for userspace to probe >> for support. Especially if it's security related which usually means >> that you want to know whether this feature works or not. > > What about just trying to violate the policy via fexecve() instead of > looking around in /proc? Still ugly, though. How would we do this? This is about opening the main executable as part of an explicit loader invocation. Typically, an fexecve will succeed and try to run the program, but with the wrong dynamic loader. Thanks, Florian