linux-kernel - Re: [PATCH v3] fs: generalize anon_inode_make_secure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67c40ef1-8d90-44c5-b071-b130a960ecc4@amd.com>
Date: Fri, 4 Jul 2025 16:11:16 +0530
From: Shivank Garg <shivankg@....com>
To: Paul Moore <paul@...l-moore.com>, david@...hat.com,
 akpm@...ux-foundation.org, brauner@...nel.org, rppt@...nel.org,
 viro@...iv.linux.org.uk
Cc: seanjc@...gle.com, vbabka@...e.cz, willy@...radead.org,
 pbonzini@...hat.com, tabba@...gle.com, afranji@...gle.com,
 ackerleytng@...gle.com, jack@...e.cz, hch@...radead.org,
 cgzones@...glemail.com, ira.weiny@...el.com, roypat@...zon.co.uk,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3] fs: generalize anon_inode_make_secure_inode() and fix
 secretmem LSM bypass



On 7/3/2025 7:43 AM, Paul Moore wrote:
> On Jun 26, 2025 Shivank Garg <shivankg@....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