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 C8702C433E0 for ; Fri, 15 May 2020 15:50:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A4F2D20709 for ; Fri, 15 May 2020 15:50:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="XbNk7MuQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726374AbgEOPuU (ORCPT ); Fri, 15 May 2020 11:50:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726255AbgEOPuT (ORCPT ); Fri, 15 May 2020 11:50:19 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48E90C05BD0B for ; Fri, 15 May 2020 08:50:19 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id q24so1087308pjd.1 for ; Fri, 15 May 2020 08:50: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:content-transfer-encoding:in-reply-to; bh=maNQlt0vCXUutQdGjL8vBhpeTRE+KVofJhs1eAnXh6g=; b=XbNk7MuQ57Rts4Z0qNTKjgNqv1OpA6t+Nc11jH0CcE5DjXS7oVuq2I56+d2MDC75jJ nDjDvlSzADQw/PQCIl8/DxXmgfrveGmE6Hw9eY461U1BxfLAfoewmC1zHAQ7NjHaBVwq 48yzco9HijnVPOEH6uI2cCSke9LuzsUIGaAQQ= 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:content-transfer-encoding :in-reply-to; bh=maNQlt0vCXUutQdGjL8vBhpeTRE+KVofJhs1eAnXh6g=; b=C5jY8xVeA/kN7Hq+vBl6Y71lnE219QwhBWjcYfy6NfePkdi7VcSIsJ3iALGf9rV8gh Chck2y9JPBm9f+1mumka1L7AdWmD1Rl5XGJOQEEmzKxEIn5M/61ESYLu3RDdMX3f4l2W cE0OXdoxHBa0s4qXEXqNyVGw0I6FsYWY3IpbS6y0ocmUyCIws4TUcpoWX/ebcitfz71R Un4qXT5iZEE1TZiDE2x/mBOCvYww1YIWNv4kFkGwsK5/brFDF7moUxCGB8hL/5k+zbHZ N14Rig/ZETyxg/aAIzFljlIhEbPR3Ifm/qz+e4M4uEsAGm1Z1X/ICcU/LbEtZI4KhuZY yLtg== X-Gm-Message-State: AOAM533q7TK3oIoAoLTGWkQzbt9SA/xQkHnx68dK62tc60HM1tydbZou G9Cn1TGv46CzU5g2Wb+NIWgJtQ== X-Google-Smtp-Source: ABdhPJzV9V5xkT+PRgcjtkcfzF74hfXgdSbJTDs6Pij7aSIOh0B9fva/6CPrsQhWRfBllA/W9iJm5Q== X-Received: by 2002:a17:90a:5584:: with SMTP id c4mr459126pji.51.1589557818127; Fri, 15 May 2020 08:50:18 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b24sm2247218pfi.4.2020.05.15.08.50.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2020 08:50:17 -0700 (PDT) Date: Fri, 15 May 2020 08:50: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: <202005150847.2B1ED8F81@keescook> References: <202005131525.D08BFB3@keescook> <202005132002.91B8B63@keescook> <202005140830.2475344F86@keescook> <202005142343.D580850@keescook> <87a729wpu1.fsf@oldenburg2.str.redhat.com> <202005150732.17C5EE0@keescook> <87r1vluuli.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87r1vluuli.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 04:43:37PM +0200, Florian Weimer wrote: > * Kees Cook: > > > 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: > > That doesn't quite parse for me, sorry. > > The point is that the script interpreter actually needs to *read* those > files in order to execute them. I think I misunderstood what you meant (Mickaël got me sorted out now). If O_EXEC is already meant to be "EXEC and _not_ READ nor WRITE", then yes, this new flag can't be O_EXEC. I was reading the glibc documentation (which treats it as a permission bit flag, not POSIX, which treats it as a complete mode description). -- Kees Cook