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 65AE0C4332F for ; Thu, 17 Feb 2022 22:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 870E96B0073; Thu, 17 Feb 2022 17:32:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81F7A6B0074; Thu, 17 Feb 2022 17:32:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BF396B0075; Thu, 17 Feb 2022 17:32:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 5AAD46B0073 for ; Thu, 17 Feb 2022 17:32:53 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0F425181AC9C6 for ; Thu, 17 Feb 2022 22:32:53 +0000 (UTC) X-FDA: 79153723026.24.01E4BEC Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf01.hostedemail.com (Postfix) with ESMTP id 6A52E40003 for ; Thu, 17 Feb 2022 22:32:52 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id h18so12224993edb.7 for ; Thu, 17 Feb 2022 14:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bzVS3GxQBLj2+ZoHNymWmW7fgxIcXLRqtnHSkBFdVIo=; b=fYu1z8wdXTgQuGm083cZUw7N/B0Y+YjzhkPbVyYrvjpCB7OG1Jlwq4irqtPlNwlxF5 oupo5/AMfqd0Y9DTn8VtlJj7ivOTw91JToHP0pSrnIfUp14Dm5+qB8PxSha0Jx8h1vrm 76ZdMJcWbPU78mJS6ATFwleKjMn9WMswJA/XfJOTkyOvfmqshMJHPW/jIR0mvzDAllfU uqpuHEniPhzvXYZ3iaiaInLz1By6gNH9ESuWUQL8QtW6VwxVA1DldtvbmcE26FkKlh8y eDYYGlBGZ6twfpS1bzfI01e6YJ7OywisgT/QBPrr2z8pS6E5TXCS/urpRw0FghoqKak0 gsaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bzVS3GxQBLj2+ZoHNymWmW7fgxIcXLRqtnHSkBFdVIo=; b=te6aeuU4SMWsfEm2nU8xNY5ibVRL5Jhnchr0T1HerGaYx6kxDQGnMx5Zv2gnuXMpDk dodd37W19iK4BwVJNSiYzM7gHast94FG3z5OWe54K45Vkp9gJ+MzTOnX3g5UhR8dcL13 +MWiqjneyxlbkjrNS9YsxttQdafc704oLDrSj6gTxTdyMel9VvxiMc1RBvF77Xm7awzS BlxoTG0i1AfaxfPHT18NxhoWE5PbGQpFyu9pRHzymuqAREALIKSEHExw3nkOF+e9/k0e +fraN7NjzfkTIRUHJcZTVXIQR6opSlN8Iw7MAPJviVQzWn23cmUG7OusFDSF16TuawG4 0LGg== X-Gm-Message-State: AOAM533uslfWez5ER4YkngMGVM5hthOZG/OCXIjaw/GVaJ1tiTYjtb2U F3HokNoksm3iAEcsuAXmCBF+vBz8U1EAIp+4bp/s X-Google-Smtp-Source: ABdhPJzLADUccqBS7dHbAPwRxfeqZ9RsiV5nDqMSQfE7BDBfCv8Bo+Bd9MOqqWhYWUFl4mZ2cFv4XO0HaaAHRb5VYtw= X-Received: by 2002:a05:6402:3487:b0:40f:fa53:956c with SMTP id v7-20020a056402348700b0040ffa53956cmr5034224edc.22.1645137170677; Thu, 17 Feb 2022 14:32:50 -0800 (PST) MIME-Version: 1.0 References: <20220125143304.34628-1-cgzones@googlemail.com> In-Reply-To: From: Paul Moore Date: Thu, 17 Feb 2022 17:32:39 -0500 Message-ID: Subject: Re: [RFC PATCH] mm: create security context for memfd_secret inodes To: =?UTF-8?Q?Christian_G=C3=B6ttsche?= Cc: SElinux list , James Morris , "Serge E. Hallyn" , linux-security-module@vger.kernel.org, Stephen Smalley , Eric Paris , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=fYu1z8wd; spf=none (imf01.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.208.43) smtp.mailfrom=paul@paul-moore.com; dmarc=none X-Rspamd-Server: rspam07 X-Rspam-User: X-Rspamd-Queue-Id: 6A52E40003 X-Stat-Signature: sgggnxhkcw6obcfjsn3qdtusfogpsgwq X-HE-Tag: 1645137172-858589 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 Thu, Feb 17, 2022 at 9:24 AM Christian G=C3=B6ttsche wrote: > On Thu, 27 Jan 2022 at 00:01, Paul Moore wrote: > > On Tue, Jan 25, 2022 at 9:33 AM Christian G=C3=B6ttsche > > wrote: > > > > > > Create a security context for the inodes created by memfd_secret(2) v= ia > > > the LSM hook inode_init_security_anon to allow a fine grained control= . > > > As secret memory areas can affect hibernation and have a global share= d > > > limit access control might be desirable. > > > > > > Signed-off-by: Christian G=C3=B6ttsche > > > --- > > > An alternative way of checking memfd_secret(2) is to create a new LSM > > > hook and e.g. for SELinux check via a new process class permission. > > > --- > > > mm/secretmem.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > This seems reasonable to me, and I like the idea of labeling the anon > > inode as opposed to creating a new set of LSM hooks. If we want to > > apply access control policy to the memfd_secret() fds we are going to > > need to attach some sort of LSM state to the inode, we might as well > > use the mechanism we already have instead of inventing another one. > > Any further comments (on design or implementation)? > > Should I resend a non-rfc? I personally would really like to see a selinux-testsuite for this so that we can verify it works not just now but in the future too. I think having a test would also help demonstrate the usefulness of the additional LSM controls. > One naming question: > Should the anonymous inode class be named "[secretmem]", like > "[userfaultfd]", or "[secret_mem]" similar to "[io_uring]"? The pr_fmt() string in mm/secretmem.c uses "secretmem" so I would suggest sticking with "[secretmem]", although that is question best answered by the secretmem maintainer. --=20 paul-moore.com