[PATCH v3] fs: generalize anon_inode_make_secure_inode() and fix secretmem LSM bypass
Shivank Garg
shivankg at amd.com
Fri Jul 4 10:41:16 UTC 2025
On 7/3/2025 7:43 AM, Paul Moore wrote:
> On Jun 26, 2025 Shivank Garg <shivankg at 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
More information about the Linux-security-module-archive
mailing list