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 17621C83030 for ; Mon, 7 Jul 2025 20:01:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 853F96B03F8; Mon, 7 Jul 2025 16:01:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 805496B03F9; Mon, 7 Jul 2025 16:01:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F3986B03FA; Mon, 7 Jul 2025 16:01:45 -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 5C8FE6B03F8 for ; Mon, 7 Jul 2025 16:01:45 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E179810AC55 for ; Mon, 7 Jul 2025 20:01:44 +0000 (UTC) X-FDA: 83638538928.19.A24FA0C Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf12.hostedemail.com (Postfix) with ESMTP id C87F34001E for ; Mon, 7 Jul 2025 20:01:41 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b="HI0hq/UM"; spf=pass (imf12.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751918502; 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=rKLu5W4g48bt+4yviXuICuogMC7NETqzFrH52NDnWkc=; b=HIZOLgelGJTro2ZdR4iEBwM8Jpkglgp8Dj+yh6pa9+9MhsQ5J/JLleRA7n9lyBChMY0fmg +jkjrYtaamm4thYpvYqj3U/kicpbC7ZPfRCJp590bbGWQNRv7i74Ib0wU3ay0BRkhbTSC8 mKQgT10Ft4Ad5fN2Y2Pe707uLJHss2M= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b="HI0hq/UM"; spf=pass (imf12.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751918502; a=rsa-sha256; cv=none; b=snrar1XCeLWwpi7McXrIEwK1y4FhHlyAoKGtaDmUZogXds89AoTLaKu6fcOz++2Qxf9MtC JInlfZQPz4oXgmimtVkF6wxv94LAnP9Q6RnyIMO4MiRZt5iBphsv39dVu62LGPHUiGpQrz LiKf7okGVgOneeawUTTR72KYz6ZpB74= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e8600a33792so2363650276.0 for ; Mon, 07 Jul 2025 13:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1751918501; x=1752523301; darn=kvack.org; 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=rKLu5W4g48bt+4yviXuICuogMC7NETqzFrH52NDnWkc=; b=HI0hq/UMH90jEoUchJu1SEW7fxwWhZdAJCrdmiO0fItXa9r78NmbOP086nxgo3F13V BIUN40aVvOhXITxaCqbuTcfZW1rp2GeSb29okeDQP0W2F0aUYZy7ooK0TvRaN1NuMtCZ Q+mK0dxjrtsAm+SOzGneAwgtj62sCiwaEm/oONX1z1GoTaupXvTPT4LKVAuQ3yEdHUWS 1Dzh3RkPlvcsxMBhRlz06BUnyIFnlo50YTEx6fT7prCTvFHZ9bXolUWuVsnkPIVBTmH0 g7XJgvZJWTxotKzutIYNyrMwgewxK/bAdRKbNwGIl/XB7MpwTxC+graWMhy79FZg/KjG bmRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751918501; x=1752523301; 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=rKLu5W4g48bt+4yviXuICuogMC7NETqzFrH52NDnWkc=; b=H+XIqHtXd3sWSdsfRGvK7w7QxNht18HmoiY3+2SPrt/uUrRSEHaS/D0AiCQzbJJ2gC LEhrl3D2iAF+duSNM+HxNwhRbqFGooJ57pxgLa14SszioUa3zB9VfM8HonF/btHK/S5g xoQreYcNL8OgPvoTkwE9u+WHoXXdEh2q6JCYPcOELXb5US5bUQxn5mnyBWhvIkz2VAhK zVWX1wvTGxwJ5FMipZN4cmoi5hqV9/HZi1lopg3abIJkHJiXEx+jsdL0jDCdIvkDqT1e O5C79ZAnQER6HgBdfvVg5xkwDtUPhfmkfPeXe40oUN9p5LqRMNgmazEEWrPyfMLcwGLF wbqw== X-Forwarded-Encrypted: i=1; AJvYcCWVRWeM3gGMJQTjwVHT5iN3tEdRplj+/GeRpTeUXOhtTIq87TMdWNc9PW/X955u9Xbw9IwDWOLjJA==@kvack.org X-Gm-Message-State: AOJu0Yx+lyoLfmQDXucyX8fxjQHfnKaYxy1z3EzgMBbNKqTVPh6/ksrA NchpeZNt2/9cupnf9MRhgB9yqky9lIdvgYcSv/nj+n1O5IejSD1NLtaG6R9yvLTPmd8PXD/8/lg 7tEqMYF+faLodrcZXavWMkgm32FROTfjM/V6LrUjR X-Gm-Gg: ASbGncujh6qfirETms3eaEypg0I2BF4yeCl7O0wqIktZ+/wLuPPdrVaOH+KaV52kjsQ g2ISHKbyts5P+MjVwYQx+yjogxNEaCnAcD9wC9NBDkk0L7ZdzN0bkR2ktDiRmP/DYWuFFEYNAsj Q6+Y7pYwIUKq1aO7xWapU1cSviUZSCpyxHS/YRpF7r65Y= X-Google-Smtp-Source: AGHT+IHLYTU4kBITzhD3jz6dc9Ywq+TkUQw8uddLaok7bGe3BDRvXBsFsPv9J8pTF74kHSNW6YoQwtEeQTNvu7SccGQ= X-Received: by 2002:a05:690c:4507:b0:70e:2ba2:659d with SMTP id 00721157ae682-71668ded751mr165544117b3.23.1751918500803; Mon, 07 Jul 2025 13:01:40 -0700 (PDT) MIME-Version: 1.0 References: <20250626191425.9645-5-shivankg@amd.com> <67c40ef1-8d90-44c5-b071-b130a960ecc4@amd.com> In-Reply-To: <67c40ef1-8d90-44c5-b071-b130a960ecc4@amd.com> From: Paul Moore Date: Mon, 7 Jul 2025 16:01:29 -0400 X-Gm-Features: Ac12FXweLS9FMTeg88WL40gFmqBUb7ZnlDziG-m_E-Jv5rzfO0-ilcmo0yLCqmI Message-ID: Subject: Re: [PATCH v3] fs: generalize anon_inode_make_secure_inode() and fix secretmem LSM bypass To: Shivank Garg Cc: david@redhat.com, akpm@linux-foundation.org, brauner@kernel.org, rppt@kernel.org, viro@zeniv.linux.org.uk, seanjc@google.com, vbabka@suse.cz, willy@infradead.org, pbonzini@redhat.com, tabba@google.com, afranji@google.com, ackerleytng@google.com, jack@suse.cz, hch@infradead.org, cgzones@googlemail.com, ira.weiny@intel.com, roypat@amazon.co.uk, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, selinux-refpolicy@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: kcg9j5e4giq1w3nggckam1ohpawqtpyg X-Rspamd-Queue-Id: C87F34001E X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751918501-370835 X-HE-Meta: U2FsdGVkX18huOHp9TS3eb9D+mFbZThO/v98ih1X5V3OfO7HJ7KY3PRWcB2s3aTjuE7bEagsBjyUrML4EpnY+g9Mls7mYp66+fPEs6Z2V1gNKvd+O3Yg75SWTVnzjcqC5b+ofEDp4PkhGyE1aJ6D78/qjnbIqXpkZ63NMGziSjJPlGrWHMSkngXMRpZOtKj10tvcVA/B6n0V9eec7pULug/0koSJ38sI2arEPlwBYhpuBQbBD9vOOowyxnmWNyzuWmxOamK6G/xKtgJXKboOoy5vPIcZ/Qiq7eO+Zvd8fhU179sSgXUAVuOFEUM0AiI4BWNNigvQRO+e784SSu4EnpkLpbJR6WZHZl09oSV1k5TQ5SvxNIyM9q+1u2RE/hACtpv7bIBGj78ISS/Y0zszD0p+6V8t71UuRNT0486ubwWn/Sc3P8YEXOANXqQJChtqvPCFCDIX4zZ73bBN8+EBp7bK3+ew2Vejw0y7F6loJMBLZ41PyCY+1R2PvWmbSyxvDVQyeRaOf0Q6hpT8KseB8yNAa2P+ONVvqmMyDn99sUjPQNPFDqfE5lrC44bOMsP3ClI39YL6Dh77kPdQ7e4IgF8ArNfalOf2EbG7BvTunhUV/EeWbnjKmUIURwqv32cqunqjzW6UNE/qfsNuS5vkJe+T998yoAIuAshkYZ/HD+8y6/o0h0ykZFk4vgxQauAYSrW7T4ECv4s3dibF/fOi00WNs5UPHid3hgLXdkt8/XJRcoKvyMIFYCtMtys3gsRm19X6+fNCq/6IBcgJ5tyU5LZRBP/kfW/KfjvS2T6s2pTXO1g5V+JHRMsixatoGrvpyG4te1HIe4YRyuLskMbsrDH0GPsLRPfDurg0NVkCBFW/Q1DyOzTYWT1YZyiwWxsp6v8lTwhc/EEk8ui9v8Dx1nQDJPJu+SHZZqa3UCZPWDuG9gNgb7MpCJh0pqz0vWIR1Yg6mYAFTssm8YUILbS y9ST+Rhq I4u9DjsIM6oQxnCIsX+kRa5V7ULhhxGInJrrfDTmApao1Kr0WhSlU1lhwW/x3wDlfRlHQgTFqhtmwvZO2DbN+XSZnk4WAvRlKZJshr/ltfwa/b3DxpXSMkA6dY0Vd4+xFuDrZZgGTj83MLcpsgTw1jNpXd+5XnQMHhS2s7hL8btFG3uMCBGQJcIws4PhVSnj4SQfq8rjn2go6LDc36pP6ZlK70l9YfjRRqvIvLlDyZ4bzUE7suUFdwzwwFyM7EZRYVJUjjZjek9sGFjhD0S+/58Z/WVIJvU8qsHGqfawSIRmDmflOCK2QXgBERSBrN7MXGf/9CBOZ3KISvxOrzGgqLsC8M3DBk6/nwdWE 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: List-Subscribe: List-Unsubscribe: On Fri, Jul 4, 2025 at 6:41=E2=80=AFAM Shivank Garg wrot= e: > On 7/3/2025 7:43 AM, Paul Moore wrote: > > On Jun 26, 2025 Shivank Garg wrote: > > ... > > > Thanks again for your continued work on this! I think the patch looks > > pretty reasonable, but it would be good to hear a bit about how you've > > tested this before ACK'ing the patch. For example, have you tested thi= s > > against any of the LSMs which provide anonymous inode support? > > > > At the very least, the selinux-testsuite has a basic secretmem test, it > > would be good to know if the test passes with this patch or if any > > additional work is needed to ensure compatibility. > > > > https://github.com/SELinuxProject/selinux-testsuite > > Hi Paul, > > Thank you for pointing me to the selinux-testsuite. I wasn't sure how to = properly > test this patch, so your guidance was very helpful. > > With the current test policy (test_secretmem.te), I initially encountered= the following failures: > > ~/selinux-testsuite/tests/secretmem# ./test > memfd_secret() failed: Permission denied > 1..6 > memfd_secret() failed: Permission denied > ok 1 > ftruncate failed: Permission denied > unable to mmap secret memory: Permission denied > not ok 2 ... > To resolve this, I updated test_secretmem.te to add additional required > permissions {create, read, write, map} > With this change, all tests now pass successfully: > > diff --git a/policy/test_secretmem.te b/policy/test_secretmem.te > index 357f41d..4cce076 100644 > --- a/policy/test_secretmem.te > +++ b/policy/test_secretmem.te > @@ -13,12 +13,12 @@ testsuite_domain_type_minimal(test_nocreate_secretmem= _t) > # Domain allowed to create secret memory with the own domain type > type test_create_secretmem_t; > testsuite_domain_type_minimal(test_create_secretmem_t) > -allow test_create_secretmem_t self:anon_inode create; > +allow test_create_secretmem_t self:anon_inode { create read write map }; > > # Domain allowed to create secret memory with the own domain type and al= lowed to map WX > type test_create_wx_secretmem_t; > testsuite_domain_type_minimal(test_create_wx_secretmem_t) > -allow test_create_wx_secretmem_t self:anon_inode create; > +allow test_create_wx_secretmem_t self:anon_inode { create read write map= }; I believe this domain also needs the anon_inode/execute permission. > allow test_create_wx_secretmem_t self:process execmem; > > # Domain not allowed to create secret memory via a type transition to a = private type > @@ -30,4 +30,4 @@ type_transition test_nocreate_transition_secretmem_t te= st_nocreate_transition_se > type test_create_transition_secretmem_t; > testsuite_domain_type_minimal(test_create_transition_secretmem_t) > type_transition test_create_transition_secretmem_t test_create_transitio= n_secretmem_t:anon_inode test_secretmem_inode_t "[secretmem]"; > -allow test_create_transition_secretmem_t test_secretmem_inode_t:anon_ino= de create; > +allow test_create_transition_secretmem_t test_secretmem_inode_t:anon_ino= de { create read write map }; > > Does this approach look correct to you? Please let me know if my understa= nding > makes sense and what should be my next step for patch. [NOTE: added selinux@vger and selinux-refpolicy@vger to the To/CC line] Hi Shivank, My apologies for not responding earlier, Friday was a holiday and I was away over the weekend. Getting back at it this morning I ran into the same failures as you described, and had to make similar changes to the selinux-testsuite policy (see the anon_inode/execute comment above, I also added the capability/ipc_lock permission as needed). Strictly speaking this is a regression in the kernel, even if the new behavior is correct. I'm CC'ing the SELinux and Reference Policy lists so that the policy devs can take a look and see what impacts there might be to the various public SELinux policies. If this looks like it may be a significant issue, we'll need to work around this with a SELinux "policy capability" or some other compatibility solution. --=20 paul-moore.com