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] [day] [month] [year] [list]

Message-ID: <CAHC9VhRUkKWDc39BAz6uzjRBt47wDCNkzfV=z6+Tb-RznfycsQ@mail.gmail.com>
Date: Mon, 7 Jul 2025 22:45:23 -0400
From: Paul Moore <paul@...l-moore.com>
To: Chris PeBenito <pebenito@...e.org>
Cc: Shivank Garg <shivankg@....com>, david@...hat.com, akpm@...ux-foundation.org, 
	brauner@...nel.org, rppt@...nel.org, viro@...iv.linux.org.uk, 
	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, 
	selinux@...r.kernel.org, selinux-refpolicy@...r.kernel.org
Subject: Re: [PATCH v3] fs: generalize anon_inode_make_secure_inode() and fix
 secretmem LSM bypass

On Mon, Jul 7, 2025 at 4:38 PM Chris PeBenito <pebenito@...e.org> wrote:
> On 7/7/2025 4:01 PM, Paul Moore wrote:
> >
> > 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.
>
> In refpolicy, there are 34 rules for anon_inode and they all have {
> create read write map } -- none of them have the execute permission.  Of
> these, only 4 are explict and could potentially be broken.  The
> remaining get it due to being unconfined, thus can be immediately fixed,
> since it's unconfined.
>
> IMO, this is very low impact.

Thanks Chris, I think it's worth leaving the kernel code as-is and
just patching the selinux-testsuite.  I'll send out a patch for that
tomorrow.

-- 
paul-moore.com