Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp412184ybk; Fri, 15 May 2020 04:08:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcA1beYssPSxkIB4z0i71H9wlISfJZE26dExsJGsgdB4WqWnMOjM63dv6mrOKfKSHjqg6u X-Received: by 2002:a05:6402:1586:: with SMTP id c6mr1820983edv.54.1589540912966; Fri, 15 May 2020 04:08:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589540912; cv=none; d=google.com; s=arc-20160816; b=u3WaVNYxaC7WyBm0ndqBf8fSd4LfcezQyLfncJQf6myLGoKlVAfRJmO+rRX6JnbiVE kctx8ma/l6N8OfDX3y4o1C4lAO0/NctQnTxFLdK9IeEkeH09CNH2mMNj469JWIJU5qD1 scHeVWZ1fsoL7A6V9yMfRtI7FqgTrIz+kaR/DupewKhK+T7bhCLWRXLCZ/Og4QnvOxVu Kmpgnj23eqAuYhH3x6J4Y8S1LYen9LTjWihTNS+bJgGAcm5YCU4+qrs3/rY/Q/eG/LdL ry8RPJQm3gM9Gz8DCbawD//sRCkmaUwG6m/aj7COcjZW8ljQBDCOPBvPlPP+ejbHESMS R0OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=9L6n4o8GKUNZdpAtkdbADqDYw1OaInm3VKqq1t0wyX8=; b=DFzhk9Nw9D2APyVYF4/AsAY58BdWMa0YUwwRl1xcLp431LSroHEAUxPdyC75WDkNOf SJu+8ijeK3gRKgqSELN9qUEH5LliekbshOJDY3BL5y8RZzzlJP5sE9TR9GErWFj0CRkZ Ri788avW0KrX8LiUyl5bHwxri+NVojMXiR3T2+Li+sDXyy/ZaYbxhgZxbI8xNDJCWM8G 8BSxKDjwLpdjEBbxiiWI5cptvI9Z0sTj/BOHkB4H+RIWqCPm/i9KKrEAFz4M3XwtA9lN ++xUL4udpK+zegnVTdzI0JU6cALzIpM7ct9A0bUDl9e/gw4OYb+QWRXQdLt3QRiqK9MJ LwsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si923500edv.248.2020.05.15.04.08.07; Fri, 15 May 2020 04:08:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726221AbgEOLEa (ORCPT + 99 others); Fri, 15 May 2020 07:04:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbgEOLE1 (ORCPT ); Fri, 15 May 2020 07:04:27 -0400 Received: from smtp-190d.mail.infomaniak.ch (smtp-190d.mail.infomaniak.ch [IPv6:2001:1600:3:17::190d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73795C05BD09 for ; Fri, 15 May 2020 04:04:27 -0700 (PDT) Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 49NlsY28SlzlhFhV; Fri, 15 May 2020 13:04:17 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 49NlsP256CzlhFvm; Fri, 15 May 2020 13:04:09 +0200 (CEST) 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) To: Kees Cook Cc: 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 , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , =?UTF-8?Q?Philippe_Tr=c3=a9buchet?= , 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 , Rich Felker References: <20200505153156.925111-1-mic@digikod.net> <20200505153156.925111-4-mic@digikod.net> <202005131525.D08BFB3@keescook> <202005132002.91B8B63@keescook> <202005140830.2475344F86@keescook> <202005142343.D580850@keescook> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <1e2f6913-42f2-3578-28ed-567f6a4bdda1@digikod.net> Date: Fri, 15 May 2020 13:04:08 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <202005142343.D580850@keescook> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/05/2020 10:01, Kees Cook wrote: > On Thu, May 14, 2020 at 09:16:13PM +0200, Mickaël Salaün wrote: >> On 14/05/2020 18:10, Stephen Smalley wrote: >>> On Thu, May 14, 2020 at 11:45 AM Kees Cook wrote: >>>> So, it looks like adding FMODE_EXEC into f_flags in do_open() is needed in >>>> addition to injecting MAY_EXEC into acc_mode in do_open()? Hmmm >>> >>> Just do both in build_open_flags() and be done with it? Looks like he >>> was already setting FMODE_EXEC in patch 1 so we just need to teach >>> AppArmor/TOMOYO to check for it and perform file execute checking in >>> that case if !current->in_execve? >> >> I can postpone the file permission check for another series to make this >> one simpler (i.e. mount noexec only). Because it depends on the sysctl >> setting, it is OK to add this check later, if needed. In the meantime, >> AppArmor and Tomoyo could be getting ready for this. > > So, after playing around with this series, investigating Stephen's > comments, digging through the existing FMODE_EXEC uses, and spending a > bit more time thinking about Lev and Aleksa's dislike of the sysctls, I've > got a much more radically simplified solution that I think could work. Not having a sysctl would mean that distros will probably have to patch script interpreters to remove the use of O_MAYEXEC. Or distros would have to exclude newer version of script interpreters because they implement O_MAYEXEC. Or distros would have to patch their kernel to implement themselves the sysctl knob I'm already providing. Sysadmins may not control the kernel build nor the user space build, they control the system configuration (some mount point options and some file execution permissions) but I guess that a distro update breaking a running system is not acceptable. Either way, unfortunately, I think it doesn't help anyone to not have a controlling sysctl. The same apply for access-control LSMs relying on a security policy which can be defined by sysadmins. Your commits enforce file exec checks, which is a good thing from a security point of view, but unfortunately that would requires distros to update all the packages providing shared objects once the dynamic linker uses O_MAYEXEC. > > 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 look forward to flames! ;) > Like Florian said, O_EXEC is for execute-only (which obviously doesn't work for scripts): https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html On the other hand, the semantic of O_MAYEXEC is complementary to other O_* flags. It is inspired by the VM_MAYEXEC flag. The O_EXEC flag is specified for open(2). openat2(2) is Linux-specific and it is highly unlikely that new flags will be added to open(2) or openat(2) because of compatibility issues. FYI, musl implements O_EXEC on Linux with O_PATH: https://www.openwall.com/lists/musl/2013/02/22/1 https://git.musl-libc.org/cgit/musl/commit/?id=6d05d862975188039e648273ceab350d9ab5b69e However, the O_EXEC flag/semantic could be useful for the dynamic linkers, i.e. to only be able to map files in an executable (and read-only) way. If this is OK, then we may want to rename O_MAYEXEC to something like O_INTERPRET. This way we could have two new flags for sightly (but important) different use cases. The sysctl bitfield could be extended to manage both of these flags. Other than that, the other commits are interesting. I'm a bit worried about the implication of the f_flags/f_mode change though. From a practical point of view, I'm also wondering how you intent to submit this series on LKML without conflicting with the current O_MAYEXEC series (versions, changes…). I would like you to keep the warnings from my patches about other ways to execute/interpret code and the threat model (patch 1/6 and 5/6).