From: Shivank Garg <shivankg@amd.com>
To: Paul Moore <paul@paul-moore.com>,
david@redhat.com, akpm@linux-foundation.org, brauner@kernel.org,
rppt@kernel.org, viro@zeniv.linux.org.uk
Cc: 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
Subject: Re: [PATCH v3] fs: generalize anon_inode_make_secure_inode() and fix secretmem LSM bypass
Date: Fri, 4 Jul 2025 16:11:16 +0530 [thread overview]
Message-ID: <67c40ef1-8d90-44c5-b071-b130a960ecc4@amd.com> (raw)
In-Reply-To: <a888364d0562815ca7e848b4d4f5b629@paul-moore.com>
On 7/3/2025 7:43 AM, Paul Moore wrote:
> On Jun 26, 2025 Shivank Garg <shivankg@amd.com> 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 this
> 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
# Failed test at ./test line 23.
ftruncate failed: Permission denied
unable to mmap secret memory: Permission denied
ok 3
ftruncate failed: Permission denied
unable to mmap secret memory: Permission denied
ok 4
memfd_secret() failed: Permission denied
ok 5
ftruncate failed: Permission denied
unable to mmap secret memory: Permission denied
not ok 6
# Failed test at ./test line 37.
# Looks like you failed 2 tests of 6.
Using ausearch -m avc, I found denials for create, write, map. For instance:
avc: denied { create } for pid=11956 comm="secretmem" anonclass=[secretmem]
...
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 allowed 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 };
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 test_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_transition_secretmem_t:anon_inode test_secretmem_inode_t "[secretmem]";
-allow test_create_transition_secretmem_t test_secretmem_inode_t:anon_inode create;
+allow test_create_transition_secretmem_t test_secretmem_inode_t:anon_inode { create read write map };
Does this approach look correct to you? Please let me know if my understanding
makes sense and what should be my next step for patch.
Thanks,
Shivank
next prev parent reply other threads:[~2025-07-04 10:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 19:14 [PATCH V3] " Shivank Garg
2025-06-27 8:27 ` Gupta, Pankaj
2025-06-27 18:21 ` Ira Weiny
2025-07-01 8:33 ` Christian Brauner
2025-07-07 5:23 ` Shivank Garg
2025-07-03 2:13 ` [PATCH v3] " Paul Moore
2025-07-04 10:41 ` Shivank Garg [this message]
2025-07-07 20:01 ` Paul Moore
2025-07-07 20:38 ` Chris PeBenito
2025-07-08 2:45 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67c40ef1-8d90-44c5-b071-b130a960ecc4@amd.com \
--to=shivankg@amd.com \
--cc=ackerleytng@google.com \
--cc=afranji@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=cgzones@googlemail.com \
--cc=david@redhat.com \
--cc=hch@infradead.org \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=pbonzini@redhat.com \
--cc=roypat@amazon.co.uk \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=tabba@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox