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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54F2FC4332F for ; Tue, 1 Nov 2022 23:14:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F0C16B0071; Tue, 1 Nov 2022 19:14:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 578A56B0072; Tue, 1 Nov 2022 19:14:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F22C6B0073; Tue, 1 Nov 2022 19:14:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 24D6C6B0071 for ; Tue, 1 Nov 2022 19:14:53 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DD9011405B4 for ; Tue, 1 Nov 2022 23:14:52 +0000 (UTC) X-FDA: 80086430424.12.A4A4266 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 50EB540003 for ; Tue, 1 Nov 2022 23:14:52 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id d6so25545256lfs.10 for ; Tue, 01 Nov 2022 16:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8yiTQsX1YddIHupT9Jn8m/7K2SjlfUqQTaa+OxHAwfA=; b=D7txH0CL0E3ZJdaEoJ9ZXSBklXaCASoY33ql0hzqTNyBOE99q8QLzgnmY1DVnp20+e cn9VXIMwJG9XQt+EbAQGf+zog8jiEDMKvNZns8ImNcN3HsRbQ05pR3IkfjOWCyskv4+/ whSgLG8fvhjiMLJ0FuBmbe8zl7sLg1hq1lGSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8yiTQsX1YddIHupT9Jn8m/7K2SjlfUqQTaa+OxHAwfA=; b=j2An1YCjuovd2kVQeHS3UXGlnubIsXauSQmDuP9vwcL7tQ8SzGFIDTaN3ylexBMdOt o1wUrwOYBSJplAEI33zuyaf5ZHtT7b8JMXLJLOz1tNmu/P+wR2cMU0Kbh7Rbzh9l6yz+ 8F2dKygAxezaWc2QYPWeniLEVfXFWb1sbB5oJMJ1BwLJmVKcIU0GhAG+SniXIpW7xUES /Ww9en5Fdt6kwGvbGHGak6FdnZ6ac+PbYYE7caor5UEweVsYuPOrLyMx8pIwvyJ+lfJO UvG3heUscUQDFL60zzEILtNM1GQMcu7pmUlNX9x8ZmnfoALVd+KUKx/2Kjg523C0dHrE O/Tw== X-Gm-Message-State: ACrzQf2ERaRRCvK0HXe6bNlxdzEP+axdhUT8DEucijjZUbC/V3u9Eh1g pVHqa4a871l2J6zohCouhWAk0OgG1c9YpbqPrdDdOg== X-Google-Smtp-Source: AMsMyM6yfVH5g/8K53w1J5qprFRCuXJ+DD6q91X7fVV4O1Nu9EC7J0q+sXRzpoJ2QZB26O4NzdElDUKnyHddCyFEc4g= X-Received: by 2002:ac2:5088:0:b0:4a2:2e18:c4c9 with SMTP id f8-20020ac25088000000b004a22e18c4c9mr7814819lfm.5.1667344490528; Tue, 01 Nov 2022 16:14:50 -0700 (PDT) MIME-Version: 1.0 References: <20220805222126.142525-1-jeffxu@google.com> <202208081018.9C782F184C@keescook> In-Reply-To: <202208081018.9C782F184C@keescook> From: Jeff Xu Date: Tue, 1 Nov 2022 16:14:39 -0700 Message-ID: Subject: Re: [PATCH v2 0/5] mm/memfd: MFD_NOEXEC for memfd_create To: Kees Cook Cc: jeffxu@google.com, skhan@linuxfoundation.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, mnissler@chromium.org, jannh@google.com, linux-hardening@vger.kernel.org, Aleksa Sarai , dev@opencontainers.org, Christian Brauner Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667344492; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8yiTQsX1YddIHupT9Jn8m/7K2SjlfUqQTaa+OxHAwfA=; b=leu1zrSuzGClyOPpSiIimIa2CAi8INeU28EPbkLPc0ioOCfu4QBbjkVeHNocuL0UZjsFnA LZ7ZnSeh9xzoIbYFQl5QMyADvqjwsd9FcYIIMJVbjci/DHf2jpX3/5TTnYQ0VY5F4G/p7P qFzKWmP8aGO6lFK6lLgOhwGMhsfeikQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=D7txH0CL; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf07.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667344492; a=rsa-sha256; cv=none; b=gNKQ+jTFD5ZO7t2I8TjfCDVCrGSZdNUXFTpOg6J6wTyiC1N4LmKoLypkVM7AhPxu/x54fQ kJIH1SkTERbPni0DZgDRl99NqZBwDUZLUIWASIMDoTApNAOuJRnKwGVBVrbf/i/2mPCkNz 1P/8HYVjD91SADD8Sjn3dtgA2ccUO+8= Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=D7txH0CL; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf07.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 50EB540003 X-Stat-Signature: 4bbbdwjqh5qtnf7c8axw5fe9bb4dbtcb X-HE-Tag: 1667344492-33981 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Kees Sorry for the long overdue reply. Those questions are really helpful to understand the usage of memfd_create, I will try to answer them, please see below inline. On Mon, Aug 8, 2022 at 10:46 AM Kees Cook wrote: > > On Fri, Aug 05, 2022 at 10:21:21PM +0000, jeffxu@google.com wrote: > > This v2 series MFD_NOEXEC, this series includes: > > 1> address comments in V1 > > 2> add sysctl (vm.mfd_noexec) to change the default file permissions > > of memfd_create to be non-executable. > > > > Below are cover-level for v1: > > > > The default file permissions on a memfd include execute bits, which > > means that such a memfd can be filled with a executable and passed to > > the exec() family of functions. This is undesirable on systems where all > > code is verified and all filesystems are intended to be mounted noexec, > > since an attacker may be able to use a memfd to load unverified code and > > execute it. > > I would absolutely like to see some kind of protection here. However, > I'd like a more specific threat model. What are the cases where the X > bit has been abused (e.g.[1])? What are the cases where the X bit is > needed (e.g.[2])? With those in mind, it should be possible to draw > a clear line between the two cases. (e.g. we need to avoid a confused > deputy attack where an "unprivileged" user can pass an executable memfd > to a "privileged" user. How those privileges are defined may matter a > lot based on how memfds are being used. For example, can runc's use of > executable memfds be distinguished from an attacker's?) > runc needs memfd to be executable, so the host with runc need to be able to create both non-executable memfd and executable memfd. memfd_create API itself can't enforce the security of how it is being used. > > Additionally, execution via memfd is a common way to avoid scrutiny for > > malicious code, since it allows execution of a program without a file > > ever appearing on disk. This attack vector is not totally mitigated with > > this new flag, since the default memfd file permissions must remain > > executable to avoid breaking existing legitimate uses, but it should be > > possible to use other security mechanisms to prevent memfd_create calls > > without MFD_NOEXEC on systems where it is known that executable memfds > > are not necessary. > > This reminds me of dealing with non-executable stacks. There ended up > being three states: > > - requested to be executable (PT_GNU_STACK X) > - requested to be non-executable (PT_GNU_STACK NX) > - undefined (no PT_GNU_STACK) > > The first two are clearly defined, but the third needed a lot of special > handling. For a "safe by default" world, the third should be "NX", but > old stuff depended on it being "X". > > Here, we have a bit being present or not, so we only have a binary > state. I'd much rather the default be NX (no bit set) instead of making > every future (safe) user of memfd have to specify MFD_NOEXEC. > > It's also easier on a filtering side to say "disallow memfd_create with > MFD_EXEC", but how do we deal with the older software? > > If the default perms of memfd_create()'s exec bit is controlled by a > sysctl and the sysctl is set to "leave it executable", how does a user > create an NX memfd? (i.e. setting MFD_EXEC means "exec" and not setting > it means "exec" also.) Are two bits needed? Seems wasteful. > MFD_I_KNOW_HOW_TO_SET_EXEC | MFD_EXEC, etc... > Great points, with those questions and usages in mind, I m thinking below: 1> memfd_create: Add two flags: #define MFD_EXEC 0x0008 #define MFD_NOEXEC _SEAL 0x0010 This lets application to set executable bit explicitly. (If application set both, it will be rejected) 2> For old application that doesn't set executable bit: Add a pid name-spaced sysctl.kernel.pid_mfd_noexec, with: value = 0: Default_EXEC Honor MFD_EXEC and MFD_NOEXEC_SEAL When none is set, will fall back to original behavior (EXEC) value = 1: Default_NOEXEC_SEAL Honor MFD_EXEC and MFD_NOEXEC_SEAL When none is set, will default to MFD_NOEXEC_SEAL 3> Add a pid name-spaced sysctl kernel.pid_mfd_noexec_enforced: with: value = 0: default, not enforced. value = 1: enforce NOEXEC_SEAL (overwrite everything) Then we can use and secure memfd at host and container as below: At host level: Case A> In secure by default system where doesn't allow executable memfd: sysctl.kernel.pid_mfd_noexec_enforced = 1 LSM to block creation of executable memfd system wide. This requires a new hook: secure_memfd_create Case B> In system that need both (runc case), use sysctl kernel.pid_mfd_noexec = 0/1 during converting application to new API. SELINUX or landlock to sandbox the process.(requires work). At container level: It would be nice for container to control creation of executable memfd too. This is through sysctl kernel.pid_mfd_noexec_enforced This lets runc to create two type of contains: one with ability to create executable memfd, one without. The sysctl.kernel.pid_mfd_noexec sets the default value, it is helpful during applications are being migrated to set the executable bit. Alternatively, we can have a new syscall: memfd_create2, where it is mandatary to set executable bit (or default to NOEXEC_SEAL), then sysctl.kernel.pid_mfd_noexec is not needed. > For F_SEAL_EXEC, it seems this should imply F_SEAL_WRITE if forced > executable to avoid WX mappings (i.e. provide W^X from the start). > Yes. I agree. Thanks! Best regards, Jeff Xu > -Kees > > [1] https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20memfd%20escalation&can=1 > [2] https://lwn.net/Articles/781013/ > > -- > Kees Cook