On Fri, Jul 4, 2025 at 6:41 AM Shivank Garg <shivankg@xxxxxxx> wrote: > On 7/3/2025 7:43 AM, Paul Moore wrote: > > On Jun 26, 2025 Shivank Garg <shivankg@xxxxxxx> 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 ... > 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 }; 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 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. [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. -- paul-moore.com
