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 C9929C10F1B for ; Tue, 13 Dec 2022 23:06:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 096328E0003; Tue, 13 Dec 2022 18:06:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 046FF8E0002; Tue, 13 Dec 2022 18:06:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E51128E0003; Tue, 13 Dec 2022 18:06:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D52CB8E0002 for ; Tue, 13 Dec 2022 18:06:07 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A0FEE80CEA for ; Tue, 13 Dec 2022 23:06:07 +0000 (UTC) X-FDA: 80238817974.25.EC3F5B1 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf07.hostedemail.com (Postfix) with ESMTP id 0A12E40011 for ; Tue, 13 Dec 2022 23:06:05 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=q+jiqGbU; spf=pass (imf07.hostedemail.com: domain of jeffxu@google.com designates 209.85.216.44 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=1670972766; a=rsa-sha256; cv=none; b=ya5ei6b0g0faivNaMGzPI6neMUEQy7OlJQZpV2v+DZdqKvL7c7tGdyGeBql7QxUpf7Eiap 1NjM4o7vl7/XAT9j+Rta21NMFV5AhiA2nqTm79B2x3xqR5c9m0ceC+Ho1hKyK6jOqZOSpk PMSYh5I3+b/+gUGsXENWqWTuiRmKDjA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=q+jiqGbU; spf=pass (imf07.hostedemail.com: domain of jeffxu@google.com designates 209.85.216.44 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=1670972766; 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=gfY9SoTee3EZfG+2GksijgMhXy5soJud6c/PL62EovE=; b=H47ZnoTVKSKSmVdJ/0DUWRJxu7hTN1sObTTV1YwI0Jy9J2giC9y70vzWWLicxglek+4kKw bNFR5mZpi8XcWIWqPP9mpQeiHsHRHSgas3dFnonnkh8R2ch5OpDFF6RgE3KriItghfh+Ac 8KGJSydzKGqpxEGBICZQjloch5ljIs4= Received: by mail-pj1-f44.google.com with SMTP id o1-20020a17090a678100b00219cf69e5f0so5232382pjj.2 for ; Tue, 13 Dec 2022 15:06:05 -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=gfY9SoTee3EZfG+2GksijgMhXy5soJud6c/PL62EovE=; b=q+jiqGbU2B/BB8WwCZG+WNfd8+StTAJUM8yeY8lrPAZVnU3+xBG9L/NwIHYotkdVlU iLyF378FtFxO5qF9FFS3lSZfo8YcOUUDL06uGMXgxT/NaFR3VdPLbjz8dkk4mWi8oRXO CS8+/KiW16y1XpaAlHTMPzpNGX21XTyui5wLf30t12VJHlJGZj7vZ+I+VdkuIJPhBJ+c O8DbRyOT2QTULNTMtD3La1yLMM/uq0pKFsQB4AloZQ8RPN8jiYiII/0UW34/CtHb/1HL PdKs7N/sVcr+hChQIGzVQ1hdkiUBVAnUdrrGlSukBnjg1vdVnANPtzIWnnbgMqyJ9Xbm 4N4w== 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=gfY9SoTee3EZfG+2GksijgMhXy5soJud6c/PL62EovE=; b=ZkOrcU1M/SiNCCleN6bNsW7x2xZNpf1Iv3YKf2WcLuroNADSXHTvmSbZlDOAGpnMUS VwVcn/t44BowEADaMS2BbTVrZM2f2pVSYmS3Q4iaNyj3TZm7H1PaQwzBJPh0gnKoCb2u AYXhINDD6vTey0XSsHO35BEC7XmDeYMjlS4/GTzXlnnHwVR3iMVggTRlJck0HGrMGLx+ 68EfKtVfIDuGGRn2SCQ7yLwOD66iwJTk7kTukz+WepBRK12YwWp6HfzrPhVQCGh1vewd 1DMpUhHvBp5nmR0lRZdBCQqNLc88aWQPyDo9H8BGzPxgikiEkI6G2rIUkD4BfTlhtSHJ tAEQ== X-Gm-Message-State: ANoB5pkrEPhM1JTcIWtY/X3ID/hlgb8EaSlMk3AFfqyQR5Y5Mx3KV6+T 1rDRro6YXWm+9Z0PXCwuh8yEW5Zn32AXZEPkbCzH3Q== X-Google-Smtp-Source: AA0mqf4fP2Z14LlLZRDbviMdNfqOrCLOgYzTISeAkWFLEBVOZgWI6FEWIPQvWDoJWGDdm493oPcC2PPuU1Ufcjxa8xE= X-Received: by 2002:a17:902:ec04:b0:189:894c:6b58 with SMTP id l4-20020a170902ec0400b00189894c6b58mr54167047pld.172.1670972764571; Tue, 13 Dec 2022 15:06:04 -0800 (PST) MIME-Version: 1.0 References: <20221209160453.3246150-1-jeffxu@google.com> <20221209160453.3246150-7-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Tue, 13 Dec 2022 15:05:28 -0800 Message-ID: Subject: Re: [PATCH v7 6/6] mm/memfd: security hook for memfd_create To: Paul Moore Cc: jeffxu@chromium.org, skhan@linuxfoundation.org, keescook@chromium.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, jannh@google.com, linux-hardening@vger.kernel.org, linux-security-module@vger.kernel.org, kernel test robot Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0A12E40011 X-Stat-Signature: hk8keht9sib9uy1dhc1j7wir59pi8tza X-HE-Tag: 1670972765-771743 X-HE-Meta: U2FsdGVkX1+3sqb+Hh/Kfk6qAKJkT5CUnECcoUBfMRKBtxc/x1my6pVDDbX+ygguRlJhJs3n7rhLwIUuZ5pq2HUHqZsWgfpg8sz0W+3PKY8K5IM0GWr3SnlI2EsrrTH9RePi0Utr8TItFc03Q8k65g8CcCgAHjbHq3719YSfQr2QQEVg6S2RaAEJdUkjfOiGk7tVhmIREV2jE3uPYHlkWLujmO0kGWDb9dxb+qTwSZ2GmNBIxMJaPlzk7a5rX7JUNHB4P/JDYAIS7aHdkAwm16CvIRGKkyeLCUsIsxouEM8OcedUSvfyLzlXH+d/9Fgm4ts+jGzveTJDMpmiC35E8bvcoSPe+c/a5fFpuJ/CpRKhKDAITu2GhfHMUPi+7B2JG5UvhROiHZTYG1BU0EPnZL9uS8v5eyQXUDVrPOVP6Hmnq/JC1S0JxfzJXF/CytasoZzX5Uc/Evbh0HwXl98cl0mH2+/L0EgTXS/KbyFMVbbF1+rA1q4eB5ppbpOJ55AIcydkzh0BDf8X7lTIfuXeigN61CJFaIr9mllN1VIJSP4t8FQvrcIMZZKGzpxXByRle5ffUe6xSSjnPYO8gfyzAa9CnoXsTjkHowfEVpz1zCm/weFNXGVstH8JOOpCgkQzVfkprYfwt/RroGWA+KJcanSSTUBD1pKks+tll4ZEl4d1v3NejrMzyDskgo7PBeYMFWXbPWf1HDoBcMxAdeWARsvxPGVNA03dYryZ3ycOq0CInfgI0d1oPA7vGLOJtxo1H4dSxfJhAqIvJkamxyMni0vrMe/tE27Kh0IZMFpZjFdIWKsk+EHhGH0h2RkrXRojbjMYhC49MoMXMJoRxyyPI1UGEjKPe+Rt4rYXcnGRwd3IG12rKiSLPrO/zKXUUqp0ilS2b6boutOMNSfMxNrd8vq8xyYVCjy2NV3TCMK/NADDhBMu4sGlkWINacr5lAFQjShxMfGkmoYjBv6/wmq UAMZCbhT j7svgfNqNvwmfgA2M8upu12It2W6cj5UJYvOW59XgLdqJIUAe7wI3raNDxm8pXgmzLBlQeSnu+5sF2UvDosPK1y2wbpbBOeFi4pXnV8yCP4opkj2avErCz6IOS6N2iJmK/uzF 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: On Tue, Dec 13, 2022 at 11:22 AM Paul Moore wrote: > > On Tue, Dec 13, 2022 at 10:00 AM Jeff Xu wrote: > > On Fri, Dec 9, 2022 at 10:29 AM Paul Moore wrote: > > > On Fri, Dec 9, 2022 at 11:05 AM wrote: > > > > > > > > From: Jeff Xu > > > > > > > > The new security_memfd_create allows lsm to check flags of > > > > memfd_create. > > > > > > > > The security by default system (such as chromeos) can use this > > > > to implement system wide lsm to allow only non-executable memfd > > > > being created. > > > > > > > > Signed-off-by: Jeff Xu > > > > Reported-by: kernel test robot > > > > --- > > > > include/linux/lsm_hook_defs.h | 1 + > > > > include/linux/lsm_hooks.h | 4 ++++ > > > > include/linux/security.h | 6 ++++++ > > > > mm/memfd.c | 5 +++++ > > > > security/security.c | 5 +++++ > > > > 5 files changed, 21 insertions(+) > > > > > > We typically require at least one in-tree LSM implementation to > > > accompany a new LSM hook. Beyond simply providing proof that the hook > > > has value, it helps provide a functional example both for reviewers as > > > well as future LSM implementations. Also, while the BPF LSM is > > > definitely "in-tree", its nature is such that the actual > > > implementation lives out-of-tree; something like SELinux, AppArmor, > > > Smack, etc. are much more desirable from an in-tree example > > > perspective. > > > > Thanks for the comments. > > Would that be OK if I add a new LSM in the kernel to block executable > > memfd creation ? > > If you would be proposing the LSM only to meet the requirement of > providing an in-tree LSM example, no that would definitely *not* be > okay. > > Proposing a new LSM involves documenting a meaningful security model, > implementing it, developing tests, going through a (likely multi-step) > review process, and finally accepting the long term maintenance > responsibilities of this new LSM. If you are proposing a new LSM > because you feel the current LSMs do not provide a security model > which meets your needs, then yes, proposing a new LSM might be a good > idea. However, if you are proposing a new LSM because you don't want > to learn how to add a new hook to an existing LSM, then I suspect you > are misguided/misinformed with the amount of work involved in > submitting a new LSM. > > > Alternatively, it might be possible to add this into SELinux or > > landlock, it will be a larger change. > > It will be a much smaller change than submitting a new LSM, and it > would have infinitely more value to the community than a throw-away > LSM where the only use-case is getting your code merged upstream. > Thanks, my original thought is this LSM will be used by ChromeOS, since all of its memfd shall be non-executable. That said, I see the community will benefit more with this in SELinux. I will work to add this in SELinux, appreciate help while I'm learning to add this. Jeff > -- > paul-moore.com