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=-5.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 65BFBC433E7 for ; Fri, 15 May 2020 14:37:42 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id B26AD20758 for ; Fri, 15 May 2020 14:37:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="i7phLR6o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B26AD20758 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-18816-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 17940 invoked by uid 550); 15 May 2020 14:37:32 -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 17901 invoked from network); 15 May 2020 14:37:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GkgSQWYyEHrVohFFMSyphZgO4DDabSVNfncbmH3+PSA=; b=i7phLR6oslO+nKsuBoJMm/9bH/JqIgx0izgjVqNpzYrr5so+8tSWN9Yf5iu61KRlBK Udu9CbA+KyxU6EBm8+gDNGEL/mh1EmL9zpEH2ZzYj91LqaHO8SRqBPJ4m+Ti1YEJzzGA jofFicakkW+mtqfl3m559FLv+sFicL0eDLX0k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GkgSQWYyEHrVohFFMSyphZgO4DDabSVNfncbmH3+PSA=; b=anWw8Tm67dXy0I/xZyfkKlji9EZC8OrxzfkKedc1uVx58drqyTjdgr5mBZBLqH5+Xk 5snPMh1F6sjdYOx6sCyTAN4lxqRdagGT0jiJrYdXG8C7MfVaeuRcYYY4S+Ebyyk8D2Km u6CO9b3oNlWBXcVZM2327w92jiNz7il1iIEocQzfyG5ttXHmPtbP/W00DCc2pEqU+vcZ FWCC4sHBZ71dgc/LYDJANq5egBwNCVA6KVkNy1P7Z3B9JCl94aZq2F53V8Aei3ujMn6r Jvz0LDnMbSoUL1+Lszjo/OFKV9mdywZ874tuHALiii2HwI+TCE0LGOdIj1acdtwpwyGP AxBA== X-Gm-Message-State: AOAM531D8XyfIRcLIuC0ogTSUa81a9tF6JTiZbDL4oTRknfrFxKkoc/c CymFjR2nPM3RWXodGUpf8fNJDg== X-Google-Smtp-Source: ABdhPJwe+mQWxHy+Y8MG1su17GDYNjf0sGvC5GumLd2b2yGuoh3drABp261K8+gyS8kDmn+Bp9fFfw== X-Received: by 2002:a62:18c1:: with SMTP id 184mr3649253pfy.277.1589553438673; Fri, 15 May 2020 07:37:18 -0700 (PDT) Date: Fri, 15 May 2020 07:37:16 -0700 From: Kees Cook To: Florian Weimer Cc: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Al Viro , Aleksa Sarai , Andy Lutomirski , Mimi Zohar , Stephen Smalley , Christian Heimes , Deven Bowers , Tetsuo Handa , John Johansen , Kentaro Takeda , "Lev R. Oshvang ." , Alexei Starovoitov , Daniel Borkmann , Eric Chiang , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Philippe =?iso-8859-1?Q?Tr=E9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , linux-kernel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, LSM List , Linux FS Devel Subject: Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC) Message-ID: <202005150732.17C5EE0@keescook> References: <20200505153156.925111-4-mic@digikod.net> <202005131525.D08BFB3@keescook> <202005132002.91B8B63@keescook> <202005140830.2475344F86@keescook> <202005142343.D580850@keescook> <87a729wpu1.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a729wpu1.fsf@oldenburg2.str.redhat.com> On Fri, May 15, 2020 at 10:43:34AM +0200, Florian Weimer wrote: > * Kees Cook: > > > Maybe I've missed some earlier discussion that ruled this out, but I > > couldn't find it: let's just add O_EXEC and be done with it. It actually > > makes the execve() path more like openat2() and is much cleaner after > > a little refactoring. Here are the results, though I haven't emailed it > > yet since I still want to do some more testing: > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1 > > I think POSIX specifies O_EXEC in such a way that it does not confer > read permissions. This seems incompatible with what we are trying to > achieve here. I was trying to retain this behavior, since we already make this distinction between execve() and uselib() with the MAY_* flags: execve(): struct open_flags open_exec_flags = { .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_EXEC, uselib(): static const struct open_flags uselib_flags = { .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_READ | MAY_EXEC, I tried to retain this in my proposal, in the O_EXEC does not imply MAY_READ: + /* Should execution permissions be checked on open? */ + if (flags & O_EXEC) { + flags |= __FMODE_EXEC; + acc_mode |= MAY_EXEC; + } -- Kees Cook