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 F3F27C77B7F for ; Mon, 8 May 2023 12:12:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A3D06B007D; Mon, 8 May 2023 08:12:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 504306B007E; Mon, 8 May 2023 08:12:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CCFF6B0080; Mon, 8 May 2023 08:12:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2D7E46B007D for ; Mon, 8 May 2023 08:12:36 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F0CECC0317 for ; Mon, 8 May 2023 12:12:35 +0000 (UTC) X-FDA: 80766975870.13.9414326 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf03.hostedemail.com (Postfix) with ESMTP id D350D20011 for ; Mon, 8 May 2023 12:12:33 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=amudl00a; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of revest@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=revest@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683547953; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qhm2iuMs798BH3BBr1kXDWeqcKP/EaEB0LeOD1fdOvc=; b=dDORPmDIYx4XLmfM6dxUkfBgF94lP4qTIAo9GZhSuD9TCeUoIHaxjrNrsV/7leeEG83MIC ukwQ4rcU/MrzACcOLTU5OOdjMSGzGTCWGvjG8L11EduV/aJWPPpYBnAA6NLHU6UC51uIIv +ZMJYgr6jltRphPWoTT1JwsmSung0Rs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=amudl00a; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of revest@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=revest@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683547953; a=rsa-sha256; cv=none; b=nzRLMs1Yr7ckJvpvPqgVx0P0cnAOZx/BfoDxI/yEOnSWHSWQcmcT9lw2EpHnJKEjGREARu RRx5BfpvdzjfJIEWk9hU9z1HLAri33fDANtuwzP04bvC10FM9E/M0ouSLdOZzRbiPddxXW zs/6rto0ZSONvAUOfXIn0ydjICnxv2k= Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-6434e263962so3280199b3a.2 for ; Mon, 08 May 2023 05:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1683547952; x=1686139952; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qhm2iuMs798BH3BBr1kXDWeqcKP/EaEB0LeOD1fdOvc=; b=amudl00aclp5eVgRfCiZdj8vsvdACj4/gj3CnKBYa29Pwuw+SXLwygXXgEgfdw4zMT DV0TW4D72p5zOdy0qrYqGlVpE4TfyPtp+eVj7/tmqWlbTV9cW0QB7NA1cfVz62mcDp9q RtjgMDkkYyNlF+7SHfPysmV81QqaFcwieNj0Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683547952; x=1686139952; h=content-transfer-encoding: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=qhm2iuMs798BH3BBr1kXDWeqcKP/EaEB0LeOD1fdOvc=; b=Aqe1IL9wZvRh03Sej6/sacFCtFbqq0GNnmBjA3bL0c1xkKFc+tAmdWHTz/XhmvTohp jlUHklxDYoXqW9/QinL7USAqaKrz7bK68l9r076jlu/9fQ//kB0lOCE+dxxJuOb/Ctle 6IPxCcys+zwu7bAiZxZ0K0P5S3WfP0t7+Dy/QKvNm/1NpsauU9ehDxM9hn665+CsOeb+ gS4wLH5WuQKgRwNuqURnBSMhLXMOvu8zafxUaGP3j8fwcNIpDglztLTDNtBjoFysFnu8 sjR0G8dBHrRyQtmf6ph3H9kQN9sKjM2srOBPJL2SgNQAXhFYfqPTsZOjxkFJVWL1WSxa Bo7w== X-Gm-Message-State: AC+VfDysH1jD445M+MrBWXF1L65gP99sBJhkHxa2tFLKjEtNGa0OqTKY 2FkAxck22pO+JQcFBlAV0ILM2DgE5J8VCzlclsB9uw== X-Google-Smtp-Source: ACHHUZ6sn/H7nwrvtvCQBr4N81UPVX2I/AOYS5pTvgCjVgFzFXf6yiHJvrICK6ftzlpNBCP8c4YsesJplr4re7S9KZ4= X-Received: by 2002:a05:6a20:6a15:b0:fa:3347:6e1 with SMTP id p21-20020a056a206a1500b000fa334706e1mr13169747pzk.51.1683547952595; Mon, 08 May 2023 05:12:32 -0700 (PDT) MIME-Version: 1.0 References: <20230504170942.822147-1-revest@chromium.org> In-Reply-To: From: Florent Revest Date: Mon, 8 May 2023 14:12:21 +0200 Message-ID: Subject: Re: [PATCH 0/4] MDWE without inheritance To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, catalin.marinas@arm.com, anshuman.khandual@arm.com, joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org, david@redhat.com, izbyshev@ispras.ru, nd@arm.com, broonie@kernel.org, szabolcs.nagy@arm.com, toiwoton@gmail.com, lennart@poettering.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: aeqd7ryb7yifcdarp6k5yixcqiqjpohh X-Rspam-User: X-Rspamd-Queue-Id: D350D20011 X-Rspamd-Server: rspam07 X-HE-Tag: 1683547953-931961 X-HE-Meta: U2FsdGVkX1858uIOp9p7pacgVfDLi5lsFmXZLkxtPnQygI0clXkbw7b+3/vNh3bPCQ639IfIwqFuTBKRR89EjyzHXQGV2Yfrw3b6kMKsq6ZX8fWnb09I6WvaDg2k+5Z6vFSBKb8qLwTLtWBYf1r4E/9vpCK9AI53sur27VLDXOewKsyLLpaO1yKhcTC3cQTbazJj6E3ks/tCuwRDnzWB556gyi8+DRz6BONvFDvmG4EuxlYohBe9nuFjJTqkSmJgbz/LJHHXTxwy64A/EAjhY50CMgg2dr6z6FY2BKZ+s+kgxWgEaba2J9mm3e37lfKVXxQH3K/HkardSTQeFEDLAWdAhbWV6rE2u7iewXhUXCiTVK1m7GR/qlJnNdbHvd5gr8+ny6jwfAS9jin6IGE/nGqLingtf6J/XY9N0OZ5WNCh/YU+EEr5PW34Mw1JvU4p8ngMm4ZCs/iBxAFv39gnGUYn4GmG8ABKtHdBh7ncEqbLYMrvu9YBPSZv8Gc4d8jocNYkCWcJIWEAvazX59GL6u5LW30DY8w6qyh/CtLkxbWT3b5polIQ6b0ExSyYB6wNKFGbqXojKidXiUeQBVVKFP72Um6E6uvOX945k8qTnFJFLtSwPDEkPcvSaZoSAUQLnbcmY6td3oecBLq/1NqCtrlGdtE7t4RfpwhEMPQOhFCaUP33QLxxKhElOIvRBf03D+ENfbdO+qpqWlutgyir+Bk/uXKzxuAXhF285CVjY6KoH/bT1qPrxf0+83OQ+iS25QV+Sx7U3ONa1f0mt6NR768W3iACiZhNnqgi5A+/TC1p/yBe9+qr7EXP4ua/ShxMhZS6NTUa1j/YFco11KJBnDHQps/wL9RmujEvrCNGdC0qDC6FYEoAb//TxgAlEYxGNK1gdG/eXdGnv+y7xsSpS/Xs2sDbRxhn/NCISuWXnL2smW//1HbEAjb9F5b98aSyh3L1cGi0Y1CAuDqCEYc 5/+7szHk t7DmGXuYPJDBpePLVZ7suUYNrfFqXHTU6ZjcJWDwRW8i0/z8bD0LA4lJWj0aLNxmgANnNiQFp6LLspyi9UWBmfuXxjxsIMC5os7GTaR6FxH+0Fpy1Wh1zU3OdHD2BG/9eOKBleF6/FFMpdM96DoMaQj4izYqR1D12k4bdrADiCCBC+TeQo72PPYVIgbK3ykaQpTm6+BGwatIi3/PiAqegtbQFpy7iM7xSAVQjQ0IL5cgLns8rwDxs1KOYX5iAfJ07JK/F X-Bogosity: Ham, tests=bogofilter, spamicity=0.018110, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 8, 2023 at 3:29=E2=80=AFAM Peter Xu wrote: > > On Fri, May 05, 2023 at 06:42:08PM +0200, Florent Revest wrote: > > On Thu, May 4, 2023 at 10:06=E2=80=AFPM Peter Xu wr= ote: > > > > > > On Thu, May 04, 2023 at 07:09:38PM +0200, Florent Revest wrote: > > > > Joey recently introduced a Memory-Deny-Write-Executable (MDWE) prct= l which tags > > > > current with a flag that prevents pages that were previously not ex= ecutable from > > > > becoming executable. > > > > This tag always gets inherited by children tasks. (it's in MMF_INIT= _MASK) > > > > > > > > At Google, we've been using a somewhat similar downstream patch for= a few years > > > > now. To make the adoption of this feature easier, we've had it supp= ort a mode in > > > > which the W^X flag does not propagate to children. For example, thi= s is handy if > > > > a C process which wants W^X protection suspects it could start chil= dren > > > > processes that would use a JIT. > > > > > > > > I'd like to align our features with the upstream prctl. This series= proposes a > > > > new NO_INHERIT flag to the MDWE prctl to make this kind of adoption= easier. It > > > > sets a different flag in current that is not in MMF_INIT_MASK and w= hich does not > > > > propagate. > > > > > > I don't think I have enough context, so sorry if I'm going to ask a n= aive > > > question.. > > > > Not at all! :) You're absolutely right, it's important to address these= points. > > > > > I can understand how current MDWE helps on not allowing any modifi-ab= le > > > content from becoming executable. How could NO_INHERIT help if it wo= n't > > > inherit and not in MMF_INIT_MASK? > > > > The way I see it, enabling MDWE is just a small step towards hardening > > a binary anyway. It can possibly make exploitation a bit harder in the > > case where the attacker has _just_: a write primitive they can use to > > write a shellcode somewhere and a primitive to make that page > > executable later. It's a fairly narrow protection already and I think > > it only really helps as part of a broader "defense in depth" strategy. > > > > > IIUC it means the restriction will only apply to the current process.= Then > > > I assume the process can escape from this rule simply by a fork(). I= f so, > > > what's the point to protect at all? > > > > If we assume enough control from the attacker, then MDWE is already > > useless since it can be bypassed by writing to a file and then > > mmapping that file with PROT_EXEC. I think that's a good example of > > how "perfect can be the enemy of good" in security hardening. MDWE > > isn't a silver-bullet but it's a cheap trick and it makes a small dent > > in reducing the attack surface so it seems worth having anyway ? > > > > But indeed, to address your question, if you choose to use this > > NO_INHERIT flag: you're no longer protected if the attacker can fork() > > as part of their exploitation. I think it's been a useful trade-off > > for our internal users since, on the other hand, it also makes > > adoption a lot easier: our C++ services developers can trivially opt > > into a potpourri of hardening features without having to think too > > much about how they work under-the-hood. The default behavior has been > > to use a NO_INHERIT strategy so users don't get bad surprises the day > > when they try to spawn a JITted subcommand. In the meantime, their C++ > > service still gets a little bit of extra protection. > > > > > And, what's the difference of this comparing to disabling MDWE after = being > > > enabled (which seems to be forbidden for now, but it seems fork() can= play > > > a similar role of disabling it)? > > > > That would be functionally somewhat similar, yes. I think it mostly > > comes down to ease of adoption. I imagine that users who would opt > > into NO_INHERIT are those who are interested in MDWE for the binary > > they are writing but aren't 100% confident in what subprocesses they > > will run and so they don't have to think about disabling it after > > every fork. > > Okay, that makes sense to me. Thanks. > > Since the original MDWE was for systemd, I'm wondering what will happen i= f > some program like what you said is invoked by systemd and with MDWE enabl= ed > already. Good question > Currently in your patch IIUC MDWE_NO_INHERIT will fail directly on MDWE > enabled process, Yes, I tried to stay close to the spirit of the existing logic (which doesn't allow any sort of privilege gains) but this is not particularly a requirement on our side so I'm quite flexible here. Maybe Joey has an input here ? > but then it makes me think whether it makes more sense to > allow converting MDWE->MDWE_NO_INHERIT in this case. It seems to provide= a > most broad coverage on system daemons using MDWE starting from systemd > initial process, meanwhile allows specific daemons to fork into anything > like a JIT process so it can make itself NO_INHERIT. Attackers won't > leverage this because MDWE_NO_INHERIT also means MDWE enabled. I should have cc-ed systemd folks who could have opinions on this. I will for v2. + cc Topi & Lennart