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 D96F0C4321E for ; Sat, 3 Dec 2022 02:30:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F3C26B0073; Fri, 2 Dec 2022 21:30:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 77D1A6B0078; Fri, 2 Dec 2022 21:30:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F7866B007B; Fri, 2 Dec 2022 21:30:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4B4E16B0073 for ; Fri, 2 Dec 2022 21:30:11 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1EC881A0BA1 for ; Sat, 3 Dec 2022 02:30:11 +0000 (UTC) X-FDA: 80199415422.13.F752A31 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf19.hostedemail.com (Postfix) with ESMTP id AFF591A000B for ; Sat, 3 Dec 2022 02:30:10 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ibJN+4wu; spf=pass (imf19.hostedemail.com: domain of jeffxu@google.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670034610; 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=CWt07COLqhM0wZS8+aSuBFX0K5MaXOD5vm4AlkQK9u8=; b=BA1EbGFQfQUirHfjrH63YF7oSFnqZqImurulqScMwN9TodQtG9O0DOEnTVXTr9376aQozn Ws3fw7sSGW+dyDBjnY4SObugBPrSOk4K3zdSFVj4rAXFO9q3PfPmgIJuVOoyDm/m0by7IQ jv2W4p1tlRVQy1ocV7HBzQbixCVAVT0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ibJN+4wu; spf=pass (imf19.hostedemail.com: domain of jeffxu@google.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670034610; a=rsa-sha256; cv=none; b=ZXSrbwlZSA7snyOSykp8prhbCT7UxyujkLWlIR3MKQJZvbjs9PQr/mveAyCS7rkVF2fxPr +YECWZtwocxU8wojIa9IgRN9s7rOIgBZTTjmAICTBmPwVw1hzveMtw/bVhR3Xo5AWBA+XD 3CquALSZOw3Fx3xrxvVyDZoCCyFgVfk= Received: by mail-pj1-f43.google.com with SMTP id q17-20020a17090aa01100b002194cba32e9so9958302pjp.1 for ; Fri, 02 Dec 2022 18:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CWt07COLqhM0wZS8+aSuBFX0K5MaXOD5vm4AlkQK9u8=; b=ibJN+4wupMeFZ8AsO0XiaFGivYyW2MY8j9syFwSujyzsv8WIvvQldHP0Mw+8z+BtGq +UM8iq8dyM8sYwdY14XNad29HiFmWd6Qav74FWK5Ij3GLXj+9mUdrsoQ9Op6Brm9boVS qA69QuShWk84L3KGUcVi8zcoNcRtMcDwru8WtwsOUxBX4PCzQq2yi4ArmDlhntkN4FuY SrkCGavYXx5dNpTWKxnmz4RLfgfohN8Uebag3wtDA4QffX+MVkAr/CjWUbotqfxo0Sd5 5eGUlsoWU0/Vd2EXp3Oorpz8Dx0a0o6CyY8W3M5Bfyo98mfI74cnheSly1UbCCx0hDzj 46qg== 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=CWt07COLqhM0wZS8+aSuBFX0K5MaXOD5vm4AlkQK9u8=; b=y+719XdpY9CtCA3PaDGpZLUYxe4/bvgNTbp4ptz+qCrOCc+UgA8ObT0X1gsfnZua8K WziLyUXtg4woq0c6teZ7EKv6o7miK36/R0AEfv+Bpl7eRLneXTDq9UFGNbMuw8zh6/B2 jFflVWHnJ0BosAzyC/cjMthkcX0zJFhMiB0vRGmdVooqEzD9vx/s6iYIQUlW61FuWm/f TkHnKNKgfXefnBcdTDC4KWvnvSsCWOMJwvLTBv0/ekOcHi4Q0YcAsO/ClYq08wK5QGpY 5Q1GFJtZUluM4ihZm3TVlPinegH7kCLZJvvb9WnI7QJXADwWJR90YgyplUUvQM2LpbZq GkbA== X-Gm-Message-State: ANoB5plYmF0Aq8VdTGOCncPjQc07nLVo0eYHGDLJ/inlY4LgRI/Emfge g5W48GIO0Xt2skbH6JK+dTxXFKcRbodXdzs8Jo2NdA== X-Google-Smtp-Source: AA0mqf4+7wHUUYy7iS3SBS3k5hhK+zqhcW2r6ExsGfYHliv7BR/cjYNM/HINU3xucnxLrSzdQD0p4/Gr+j/OQbHxh0I= X-Received: by 2002:a17:90a:5317:b0:213:34f7:fb14 with SMTP id x23-20020a17090a531700b0021334f7fb14mr82075775pjh.25.1670034609492; Fri, 02 Dec 2022 18:30:09 -0800 (PST) MIME-Version: 1.0 References: <20221202013404.163143-1-jeffxu@google.com> <20221202013404.163143-7-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Fri, 2 Dec 2022 18:29:32 -0800 Message-ID: Subject: Re: [PATCH v3] mm/memfd: Add write seals when apply SEAL_EXEC to executable memfd To: Daniel Verkamp Cc: jeffxu@chromium.org, skhan@linuxfoundation.org, keescook@chromium.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: nuqxfa66qdxbng4s94ors738zrrmr99o X-Rspam-User: X-Spamd-Result: default: False [-0.40 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SORBS_IRL_BL(3.00)[209.85.216.43:from]; SUSPICIOUS_RECIPS(1.50)[]; SUBJECT_HAS_UNDERSCORES(1.00)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_ALLOW(0.00)[google.com:s=20210112]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_TWELVE(0.00)[14]; DKIM_TRACE(0.00)[google.com:+]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; DMARC_POLICY_ALLOW(0.00)[google.com,reject]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: AFF591A000B X-Rspamd-Server: rspam06 X-HE-Tag: 1670034610-116974 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 Daniel Thanks for your review. On Fri, Dec 2, 2022 at 3:24 PM Daniel Verkamp wrote: > > On Thu, Dec 1, 2022 at 5:36 PM wrote: > > > > From: Jeff Xu > > > > When apply F_SEAL_EXEC to an executable memfd, add write seals also to > > prevent modification of memfd. > > > > Signed-off-by: Jeff Xu > > --- > > mm/memfd.c | 3 +++ > > tools/testing/selftests/memfd/memfd_test.c | 25 ++++++++++++++++++++++ > > 2 files changed, 28 insertions(+) > > > > diff --git a/mm/memfd.c b/mm/memfd.c > > index 96dcfbfed09e..3a04c0698957 100644 > > --- a/mm/memfd.c > > +++ b/mm/memfd.c > > @@ -222,6 +222,9 @@ static int memfd_add_seals(struct file *file, unsigned int seals) > > } > > } > > > > + if (seals & F_SEAL_EXEC && inode->i_mode & 0111) > > + seals |= F_ALL_SEALS; > > + > > *file_seals |= seals; > > error = 0; > > > > Hi Jeff, > > (Following up on some discussion on the original review, sorry for any > duplicate comments.) > > Making F_SEAL_EXEC imply all seals (including F_SEAL_SEAL) seems a bit > confusing. This at least needs documentation to make it clear. > > Rather than silently adding other seals, perhaps we could return an > error if the caller requests F_SEAL_EXEC but not the write seals, so > the other seals would have to be explicitly listed in the application > code. This would have the same net effect without making the > F_SEAL_EXEC operation too magical. > If we take error out approach, application need to add F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE|F_SEAL_FUTURE_WRITE when F_SEAL_EXEC is used. Personally I think it is a bit long. From an API point of view, we can think of this as sealing the whole executable instead of just "X" bit. If there is a new type of write SEAL in future, all applications need to be updated, that is much harder, and updating the kernel is easier. Maybe I should remove F_SEAL_SEAL, so this code is still correct if a new type of "Non-Write" seal is added in future. > Additionally, if the goal is to enforce W^X, I don't think this > completely closes the gap. There will always be a period where it is > both writable and executable with this API: > > 1. memfd_create(MFD_EXEC). Can't use MFD_NOEXEC since that would seal > chmod(+x), so the memfd is W + X here. > 2. write() code to the memfd. > 3. fcntl(F_ADD_SEALS, F_SEAL_EXEC) to convert the memfd to !W + X. > > I think one of the attack vectors involved the attacker waiting for > another process to create a memfd, pausing/delaying the victim > process, overwriting the memfd with their own code, and calling exec() > on it, which is still possible in the window between steps 1 and 3 > with this design. > There are also step 4. 4. call exec on the memfd, In confused deputy attack, attacker wants to inject content into memfd before step 4, because step 4 is by a privilege process, attackers can gain root escalation this way. Ideally step 2 rewrites the whole memfd, (injecting content between 1 and 2 won't work), and step 3 is the next line after 2, making the process to stop exactly between 2 and 3 is not easy. So enforcing W^X can reduce the attack surface. It also defines the most secure way for dev, or else, dev might: - forget to apply the W seal. - choose to apply X and W seal in multiple calls, thus adding a gap. > Thanks, > -- Daniel Thanks Jeff