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 B27C8C433DF for ; Fri, 15 May 2020 14:37:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B2D320671 for ; Fri, 15 May 2020 14:37:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="i7phLR6o" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726724AbgEOOhV (ORCPT ); Fri, 15 May 2020 10:37:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726719AbgEOOhT (ORCPT ); Fri, 15 May 2020 10:37:19 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D04EC05BD09 for ; Fri, 15 May 2020 07:37:19 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id n11so1032352pgl.9 for ; Fri, 15 May 2020 07:37:19 -0700 (PDT) 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=JMsG8OUAp1p//PuZCAGVkYdZwk6hUG0iFQbbtnLsEDrP1x4Alcxo+QmqmhKT06GaXS bqYwRrRWAJsiGz9YrpziYwXqyodYRJnRjKUB2F5aiEpr5RW193ga1JjoiB3R/N0IZ6qv dRiwC+8oZ/qXiXUh6AuAB8iAt1WsvzrHx4DI9yDaRd3fG7jHHDfQQgeatnSp7onMRi4t k93Ux4t3nFeLWm6g2/SI++7gmNk+Q5/ttCCoBQbqPfW7y5wc1yv9XpIwCFBDVskw7EbD CD6WcySWOxD4muRueiP1JchmgPi/HPtuKsn5MVBn7Wi1UOlgfFGjTP5eJWV9cvLksTTj KIYw== X-Gm-Message-State: AOAM531+CwOY5/IX0UnugV9XnM9GevcRsd2rLn+l09+HwdFJo2qJmwrw lkMHT3YqZBM2B5ejN2t/GTIsNw== 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) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id q134sm2132257pfc.143.2020.05.15.07.37.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2020 07:37:17 -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> Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org 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